Hi Erez, In that case, we take padding as TLV if I read code correctly. Now it's basically ok, only because the padding bytes can be maximum two bytes (64 - 14 - 4 FCS - 44 (smallest PTP PDU?)), we would not enter below while-loop as TLV struct is of size 4. But how about if future comes new smaller PTP PDU? And I don't know for UDP/IP/IPv6.
static int suffix_post_recv(struct ptp_message *msg, int len)
{
...
while (len >= sizeof(struct TLV)) {
Thanks,
Vincent
-----Original Message-----
From: Geva, Erez <erez.geva....@siemens.com>
Sent: Thursday, January 31, 2019 5:22 PM
To: Jiri Benc <jb...@redhat.com>
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
As you feel, I don't care on the Ethernet frame.
Nor do I think we should try to fix it or criticize it.
If the packet pass the Linux kernel and received by the PTP daemon, we
should not care.
For me, the only question is, if the Ethernet frame does have padding and
the PTP frame is proper.
Is there a problem?
Is the PTP messaged parsed in a correct manner?
Erez
________________________________________
From: Jiri Benc [jb...@redhat.com]
Sent: 31 January 2019 17:03
To: Richard Cochran
Cc: Mats Bergman H; Richard Jönsson; Linuxptp-devel@lists.sourceforge.net
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
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
