>>> The first thing that comes to mind is you're over-taxing Linux's >>> selective ack's. Try disabling with: >>> >>> # echo 0 > /proc/sys/net/ipv4/tcp_sack >> >> >> That didn't do it but switching to MTU 576 seems to have fixed it. I >> suspect the root of the problem is that I'm using an AT&T modem/router with >> the server. I've had trouble using a proxy server there before and I >> discovered that the attached modem/router doesn't send ICMP responses. The >> solution proposed by AT&T was to put the modem/router into bridged mode but >> it's remote so I haven't been able to do that. >> >> Could this MTU discovery also point to the modem/router and could putting >> it into bridged mode solve the problem? What can I do in the meantime? >> >> Is it strange that netcat works with MTU 1500 and openssh doesn't? > > > I don't know what model of modem/router you're using, but I have this > problem with my home Technicolor TG582n. If I try to upload large amounts of > data to a system with MTU < 1500 (e.g. my office on PPPoE), it stalls > immediately, not after 52 MB. > > It seems like a bug in the router: it doesn't forward ICMP MTU-exceeded > errors received from the Internet, or does it wrongly so they're ignored by > the receiving host on my LAN (which is trying to upload the data). If I > replace it with an older ST516 then the problem goes away, but that router > doesn't have wireless so it's less convenient. There appears to be no way to > contact Technicolor to report this issue to them. > > I have seen problems with corruption of packets based on certain patterns > appearing in them, which are more likely to hit encrypted streams randomly, > while an unencrypted stream that doesn't contain the trigger sequence will > almost never hit the problem. > > If you put it into bridged mode, it may help you for two reasons: > > * It may reduce your MTU (if you're bridging PPPoA to PPPoE) so that the MTU > discovery problem can't happen. > > * It may take the modem's (suspected faulty) NAT code out of the network > path. > > However, it might make no difference, and without isolating the problem to a > corrupt ICMP message or something that's worked around by reducing the MTU > to 1492, I wouldn't bet on it. Since setting the MTU to 576 fixes the problem, what do I lose by leaving it there? Does that reduce bandwidth significantly? - Grant _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
