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

[Vincent Li X]

 

Hi Steven,

Do you run with latest release?  I think the problem is ptp4l takes the
length as recvmsg() - carrierHeaderLen, instead of m->header. messageLength.

Or is it the driver’s responsibility to remove padding before socket?

 

Thanks,

Vincent

 

From: Sun, Steven (NSB - CN/Qingdao) <steven....@nokia-sbell.com> 
Sent: Wednesday, January 30, 2019 6:34 AM
To: Vincent Li X <vincent.x...@ericsson.com>;
Linuxptp-devel@lists.sourceforge.net
Cc: Mats Bergman H <mats.h.berg...@ericsson.com>; Richard Jönsson
<richard.jons...@ericsson.com>
Subject: RE: ptp4l wrongly takes padding bytes as TLV?

 

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
<mailto:vincent.x...@ericsson.com> > 
Sent: Wednesday, January 30, 2019 12:48 AM
To: Linuxptp-devel@lists.sourceforge.net
<mailto:Linuxptp-devel@lists.sourceforge.net> 
Cc: Mats Bergman H <mats.h.berg...@ericsson.com
<mailto:mats.h.berg...@ericsson.com> >; Richard Jönsson
<richard.jons...@ericsson.com <mailto: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.



 

2.      sk.c this line returns 64, including eth header size 14.

cnt = recvmsg(fd, &msg, flags);

 

3.      msg.c, cnt is 50, pdulen 44.

            m->tlv_count = suffix_post_recv(suffix, cnt - pdulen,
&m->last_tlv);

 

4.      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;

                                      }                         

 

5.      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

 

 

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel