Vincent,
We saw similar issue when co-work with Qulsar's PTP master clock. Qulsar master
clock added 4 extra bytes after the PTP payload in UDP payload. Bad message
error was reported by ptl4l which is running in slave mode. The difference is
that we are using UDP4 unicast rather than ether multicast.
In our case, ptp4l takes the UDP payload length rather than PTP messageLength
to process the messages. So any extra byte after PTP payload which length > 3
bytes will cause the "bad message" error.
I am not sure whether it's correct or not. Checked PTP and UDP specs but no
clear definition for this.
Thanks,
Steven
From: Vincent Li X <vincent.x...@ericsson.com>
Sent: Wednesday, January 30, 2019 12:48 AM
To: Linuxptp-devel@lists.sourceforge.net
Cc: Mats Bergman H <mats.h.berg...@ericsson.com>; Richard Jönsson
<richard.jons...@ericsson.com>
Subject: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
Hi,
We are running the old version 1.6.
1. This is a normal FOLLOW-UP received with one-zero padding of 6 octets.
[cid:image001.jpg@01D4B89E.CED276B0]
1. sk.c this line returns 64, including eth header size 14.
cnt = recvmsg(fd, &msg, flags);
1. msg.c, cnt is 50, pdulen 44.
m->tlv_count = suffix_post_recv(suffix, cnt - pdulen, &m->last_tlv);
1. msg.c, this func takes 0x80 from above padding as tlv->length and returns
below EBADMSG.
static int suffix_post_recv(uint8_t *ptr, int len, struct tlv_extra *last)
{
...
if (tlv->length > len) {
return -EBADMSG;
}
1. It seems that eth standard doesn't say "padding must be 0". So it could
be a bug of ptp4l? or has been fixed by later release?
Thanks,
Vincent
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
