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 <[email protected]> Sent: Wednesday, January 30, 2019 12:48 AM To: [email protected] Cc: Mats Bergman H <[email protected]>; Richard Jönsson <[email protected]> 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:[email protected]] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
