On Sun, 11 Jun 2023 15:42:23 -0700, Richard Cochran wrote:
> NAK. Please consult the mailing list archives.
Oops, I can see that this has already been discussed extensively! It
makes sense that this change isn't necessary. I had to do some reading
to convince myself, so I'll include what I found.
Given the following excerpts, I was originally thinking that the
messageLength field would be the reliable way to know the length of the
user client data in a padded layer 2 packet.
802.3-2022 section 3.2.6:
It is the responsibility of the MAC client to ensure that the MAC
client operates properly when the MAC sublayer pads the supplied MAC
Client data
802.3-2022 section 4.2.3.3:
The number of extra bits shall be sufficient to ensure that the
frame, from the DA field through the FCS field inclusive, is at
least minFrameSize bits.
Given the "at least" phrasing, at first I was unclear about whether or
not padding beyond minFrameSize bits could be legally transmitted.
However, after some research, I see that such additional padding is
considered improper by 802.3, but some groups recommend allowing
reception anyway.
The interoperability lab at UNH actually discusses this situation in the
following document:
https://www.iol.unh.edu/sites/default/files/testsuites/ethernet/MAC/
MAC_Test_Suite_v4.6.pdf
MAC Test Suite v4.6 Test #4.1.5 - Receive Frames with Excess Pad:
The IEEE std 802.3-2005 is ambiguous on how a frame with excess
padding should be handled, thus this test part is performed on an
informative basis only. As the frames with excess padding used in
this test are valid in all other respects, the UNH-IOL recommends
that the DUT accept each test frame and reply with a frame that does
not contain padding. This ensures that the valid data is not
discarded.
This referenced interpretation is interesting as well:
https://www.ieee802.org/3/interp/interp-3-1104.pdf
Interpretation Number: 03-11/04:
Note however that the example frame in the request should not exist.
This is due to the requirement in subclause 3.2.7 that states that:
The length of PAD field required for MAC client data that is n
octets long is:
max [0, minFrameSize - (8 × n + 2 × addressSize + 48)] bits.
A frame in excess of minFrameSize should always have a PAD field of
size 0.
So it seems clear that frames with additional padding should not be
transmitted in the first place, but it sounds like implementations
are free to receive or drop such frames due to the ambiguity in the
standard.
In a few places you mentioned that all transports provide the packet
length.
On Fri, Feb 01, 2019 at 08:16:41AM -0800, Richard Cochran wrote:
> The rule in communication is to be strict when sending, but generous
> when receiving. This code generously allows incorrect messageLength.
> That field is redundant, because all of the transports already provide
> the packet length. Thus there is no need to check it.
This is definitely true (or at least should be true) for layer 2 packets
in excess of minFrameSize bits, however, the raw transport does have a
small quirk in that when you send a 44 byte sync message (with no TLV),
layer 2 receivers will receive a 46 byte message as a result of the
transmitter's MAC sublayer appending 2 extra octets to meet the
minFrameSize requirement in 802.3. 802.3 does not provide a way to
determine the user client data length when packets use the etherType
field as a type field like PTP does.
The code currently works with such sync Ethernet messages because when
parsing the suffix, the TLV header is 4 bytes and padding happens to be
2 bytes. This means that the while loop in the suffix_post_recv function
is bypassed (since len < sizeof(struct TLV)) and the subsequent
messageLength sanity check also passes because suffix_length ends up
being 0.
It kind of feels like this situation is only working because the
required padding added by the MAC sublayer happens to be smaller than
size of a TLV header. However, based on the above information it sounds
like it is safe to rely on this "coincidence". I don't love that some of
these transport details (padding bytes) leak into the transport
independent message handlers, but it does work.
As I think you have mentioned before, if we wanted to be pedantic about
the user client data length during raw frame reception, the raw
transport layer probably should use the messageLength field when a 60
byte frame (without FCS) arrives at the socket. That said, since we know
the size of PTP packets, when a minFrameSize packet is delivered we can
implicitly know that it contains 2 bytes of padding. Finally, it sounds
like it is generally valid to trust the length in the case of larger
packets.
-Dylan
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
