Section 13.3 of the 1588 specification* discusses the common message header
format. In particular, the messageLength field is defined in 13.3.2.4 as
“The total number of octets that form the PTP message. The counted octets start
with the first octet of the header and include and terminate with the last octet
of any suffix or, if there are no suffix members with the last octet of the
message as defined in this clause. “
It is implicit in this definition that the messageLength field can be used to
determine if a suffix is present with a PTP message. That is, by checking if the
messageLength count terminates at the last the last octet of the PTP message
(given by the messageType value), or is larger, indicating at least one suffix
(TLV) is present.
Rather than using the messageLength field to determine if a suffix is present,
the msg_post_recv() function currently relies on the transport layer’s reporting
of the fame/packet size (cnt). The code is defensive in checking if the
frame/packet size is too small, but is not permissive of the frame size being
too big. However, there are situations in which this can arise, specifically in
the case of IEEE 802.3 /Ethernet based transport.
It is possible for 802.3 Ethernet adapters to be configured include the Ethernet
CRC value in the raw frame which will be returned by the PF_PACKET / SOCK_RAW
interface used by Linux PTP. This is configured on a per interface basis
(e.g. ethtool -K eth1 rx-fcs on) and is independent of using Linux PTP on that
interface (e.g. some other application may want or need this to be configured).
When the CRC is included in the frame, the fame length is 4 octets longer than
message it transports. The problem is that this is large enough to potentially
contain a TLV. So the suffix_post_recv() function will attempt to parse the CRC
as if it was a TLV, typically resulting in a -EBADMSG error.
I can’t find anywhere in the 1588 specification that disallows fames that are
larger than one message. The standard (Annex F) is silent on the topic of the
maximum Ethernet fame length. It only defines that “the first octet of the PTP
message shall occupy the first octet of the client data field”.
The fix for this is simple, which is to rely on the messageLength value from the
PTP general header to determine if there is a suffix. As the standard implies,
regardless of the transport used, this field will accurately indicate whether or
not a suffix exists to be parsed.
* I’m looking at the 2008 version, I can’t find any reference to which version
this project specially supports, but I don’t think this is something that has
changed recently or is contentious across versions.
Matthew Sanders (1):
msg: fix incorrect suffix detection for frames longer than
messageLength
msg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.25.1
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
