Re: Pulling stalls before 52MB (works via netcat)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



On 5/4/2014 9:08 AM, Grant wrote:
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.

You probably don't need to go that low. If the link is PPPoE, you lose a bit of the frame to PPP encapsulation.

MTU=1460 should be a safe and conservative setting that won't unduly contribute overheads. (Theoretically, MTU=1492 should be all that's required.) If you used a PPPoE client/gateway that clamped MSS through the PPPoE default route automatically, you could leave the rest of your LAN's MTU settings at their default, while payloads will be automatically constrained when routed through the gateway to a safe value without requiring Path MTU Discovery (PMTUD).

Look for ICMP firewalling settings on the AT&T Modem/Router. If you're blocking all ICMP out of the border, you've broken PMTUD. Of course, on the client node side, bad firewalling can break it there as well. Most (all?) operating systems support it by default these days.

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?

Broken path MTU discovery is usually a firewalling problem. If your server is overly restrictive on ICMP messages, this is usually the cause.

Bridging mode may simply allow you to duck the problem by placing firewalling decisions elsewhere in your network.

Is it strange that netcat works with MTU 1500 and openssh doesn't?

Depending on the TCP_CORK/TCP_NODELAY related settings used by both, that could account for some differences in operation. Without a packet log looking at the actual payloads + sizes, you might just be assuming that netcat's generating 1500 byte payloads over the wire.

=M=
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux