On Mon, 12 Jun 2023 at 20:04, Dylan Robinson <dylan_robin...@motu.com> wrote:
> 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. > > Dylan. just one note. The IEEE 802.3 standard actually follows an already existing Ethernet protocol (Ethernet II). It follows already existing hardware of different vendors and promises backward compatibility. The ambiguity is not a slip but by design! This is not the only standard that follows the market and existing products. It happens everywhere. I do not suggest to ignore standards, Only bear in mind that we can not rely on others to implement the standard to the letter. And that standards in many cases involve politics of many vendors, which lead to ambiguity by design and compromises. Erez > 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 >
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
