ls -al stalls in an ssh session

Question

I have a very strange problem when I log into a remote machine using ssh. Here's the scenario:

1. I log into a remote machine using ssh (this machine in not in the local lan)
2. I do ls (it works)
3. I do ls -a (it works)
4. I do ls -l (it works)
5. I do ls -al .bash_profile (it works)
6. I do ls -al (it fails after listing 2 directories... the third directory would have been .bash_profile)

When I log into this machine using ssh from another machine in their local network, everything works fine.

Can someone please help me debug this problem.

Update1: As Dan suggested, I tried playing around with the size. However just to eliminate any problem with ls I tried doing

$ls -al >> ls_op.txt (this worked)

Then I did

$ls >> ls.txt  

until the size of ls.txt was 1020 bytes, and then did
$cat lx.txt (this also worked)
I again did 'ls >> ls.txt' to tip the file size over 1024. The file size was now 1360 bytes. Now doing
$cat ls.txt (failed)

So there is definitely some problem related to packet sizes. Here's some more information. There are 2 physical locations, let's say A, and B.

When I am at a machine in A and log into a machine in B, I am able to cat a file larger than 1024 bytes.

However, when someone is sitting in B and they log into a machine at A, they can cat a file which is less than 1024 bytes, but cannot cat a file greater than 1024 bytes.

Can someone help me with the next step. Can I edit config files on any of the machines to get this working, or does this need some configuration at the network level?

Thanks again for your help.

Update2:

ifconfig eth0 mtu 512  

Changing the mtu of the machine in network A solved the problem.

--
Thanks
Parag

Answer 1

I would hazard at it being something MTU/fragment related with the workstation's local or upstream network. The quantity of data returned by ls -al could be just enough to tip the balance and cause it to stall. I imagine that you should be able to replicate the same behaviour with any large quantity of data, such as cat'ing or SCP'ing a large file.

---

Update:

From that information it is definitely MTU related. It's most likely that it will be an issue at the border of either network and you'll have to get your hands dirty. You could try tweaking external MTU/MSS of any routers. But leave the individual machine settings as standard as possible, unless the internal network dictates otherwise.

Are there any particular protocols involved that will knowingly eat into those last few bytes of the datagram, such as PPP (oA or oE) and VPN encapsulation? Are you aware of PMTU (ICMP Destination Unreachable) being blocked? Are you able to perform and observe packet captures at the network border?