[Bridge] ssh connection not working when ssh server is behind a linux bridge

[Adrian Pascalau]

On Mon, Jan 29, 2018 at 9:51 AM, Adrian Pascalau
<adrian27oradea at gmail.com> 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.