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