On Mon, Jan 29, 2018 at 9:51 AM, Adrian Pascalau <adrian27oradea@xxxxxxxxx> wrote: > In this 54 bytes TCP ACK frame, the Ethernet II header is 14 bytes > long, the IP header is 20 bytes long, the TCP header is another 20 > bytes in length, and there is no TCP payload, so in total 54 bytes. > When this frame arrives in the client side, it is 60 bytes in length, > and it is interpreted by the Wireshark as a SSHv2 frame, because of > the 6 additional 0x00 padding bytes in the TCP payload. I find this > exact frame in a working ssh session, and those 6 additional 0x00 > padding bytes are correctly shows at the Ethernet II frame level. Ok, so I found a workaround for this, even if I do not know who caused this issue. Basically I noticed that I have this ssh connection issue only when the ssh client runs on a windows host. If the ssh client runs on a linux host, the ssh connection works without any problem. So I have compared the tcpdump for ssh connections initiated from both windows and linux, and what I have noticed is that on centos linux, by default the TCP stack uses timestamps in the TCP Options, and because of this, the Ethernet frames are never below 60 bytes, while in my windows the TCP Options timestamps are not used, and therefore some Ethernet frames are less than 60 bytes. So I enabled the TCP Options timestamps in windows as well, by running the command 'netsh int tcp set global timestamps=enabled', and just like that, the ssh started to work. Still, I do not know who is causing this issue, and who to blame for this behavior... Any suggestion how to identify which network element wrongly assigns the Ethernet padding to the TCP payload is more than welcome.
