Hi Grant,
On Sun, 4 May 2014, Grant wrote:
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.
Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chris+sig@xxxxxxxxx> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
