Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?

[Vincent Li X <vin...@er...>]

Thanks Jiri, Miroslav and Richard!
Ok, we see this is our sending NIC messes with FCS and receiving NIC didn't
drop it but passed on to application. 
But we still think it's more safe to use header.messageLength instead of
socket count, 
Msg.c
	err = suffix_post_recv(m, cnt - pdulen);
==>
	err = suffix_post_recv(m, m->header.messageLength - pdulen);

we might also need to check again m->header.messageLength is bigger than
cnt.

Ps. @Miroslav Lichvar <mli...@re...> what spam in your mail? Why
always in junk box? :)

-----Original Message-----
From: Jiri Benc <jb...@re...> 
Sent: Thursday, January 31, 2019 5:04 PM
To: Richard Cochran <ric...@gm...>
Cc: Vincent Li X <vin...@er...>; Mats Bergman H
<mat...@er...>; Richard Jönsson
<ric...@er...>; Lin...@li...
Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?

On Thu, 31 Jan 2019 07:41:38 -0800, Richard Cochran wrote:
> FWIW, Wireshark shows "Bad FCS" for this frame.  Please fix it at the 
> sender.

To be fair, this is just an artifact of Wireshark guessing wrong on the
packet structure. AFAIK there's no indication of the frames having FCS or
not in pcap. Wireshark has to guess and when it sees the packet being
6 bytes longer than the payload and 64 bytes in total, it's natural to guess
it's 2 bytes padding and 4 bytes FCS to satisfy the Ethernet minimum length
requirements.

While in fact, I expect that the FCS got stripped and the frame was
68 bytes. The real FCS was most likely correct.

Seeing the padding bytes not being zero, I cannot resist wondering what part
of its memory is the sender leaking. Could the leak be used to gather some
interesting data? ;-)

In any case, this behavior is wrong on several levels. And with the likely
security issue present, I don't think it's worth the time to consider this
hardware seriously.

 Jiri