Pulling stalls before 52MB (works via netcat)

[Grant]

>>> 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