On Sun, 19 Oct 2014, Paul Suh wrote:
> > If so, then the problem is more subtle. In the absence of further
> > information, I'd expect a MTU blackhole in one/both directions,
> > since the KEXINIT packet is likely to be the first bit of data sent
> > that is >1KB. You might be able to check this using ping's size
> > and don't-fragment options (make sure you test both the client->server
> > and server->client directions).
I was probably mistaken in my speculation - the connection isn't hanging
like you'd expect from a PMTU blackhole but both ends are getting TCP
reset ('connection reset by peer')
I'd check any packet filter logs and, if they are empty, watch a
connection with tcpdump to see where the resets are coming from.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
