On Sun, Jan 28, 2018 at 3:17 AM, Darren Tucker <dtucker@xxxxxxxxxxx> wrote: > On 27 January 2018 at 06:50, Adrian Pascalau <adrian27oradea@xxxxxxxxx> > wrote: >> >> So could this be because of windows? >> I cannot suspect Putty, since I tried this with another windows based >> ssh client (MobaXterm), and the same issue happens. > > > It's probably not Windows per se, but rather something different about how > it behaves in that situation that is standards compliant but tickles a > pre-existing path MTU/fragmentation issue in your network. (eg maybe its > ethernet device drivers use jumbo frames by default or something). > > You would be best served by finding that problem and fixing it, but you can > try working around it by reducing the MTU on either server or client. 1500 > is the typical value for ethernet, I'd try 1496 (typical 802.1Q overhead, > 1492 (typical PPPoE overhead) maybe 1400 and if all else fails 576 (the > minimum value the spec says an implementation should be able to handle). I have tested this one more time with all the hosts (ssh client and ssh server) in the same subnet, no routers/vpn in between. All hosts are connected to the same switch, same problem persist, so it is not an MTU issue. I took several tcpdump traces, and compared the working ssh sessions with the non working ones, and this is what I have found: when an Ethernet frame that is less then 60 bytes in size goes through the network, it is padded with 0x00 bytes until it has 60 bytes in length (64 with the frame check sequence). In my network I have a linux bridge that connects the centos VM to he external network. When this kind of padded frames goes through the linux bridge, somehow the IP and TCP headers in those frames wrongly consider the 0x00 padded bytes as part of the user data, therefore the upstream protocol (SSH in this case) tries to interpret them, and this is why Putty hangs. Those 0x00 padded bytes are at the layer2 Ethernet frame level, and should not be considered in the user data of the higher level protocols. I think I should take this to the linux bridge mailing lists. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
