Pulling stalls before 52MB (works via netcat)

[Chris Wilson]

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 at qwirx.com> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |