Here is a very simple test that can be done to demonstrate the issue with the current implementation.
1. Connect ethernet to a 802.1AS grandmaster that will win bcma. 2. Start ptp4l on interface <iface> with gPTP.cfg configuration file and stdout logging. 3. Notice everything working fine (no bad message logs). 4. Enable fcs reception using the following command. sudo ethtool -K <iface> rx-fcs on 5. Notice ptp4l start to experience issues (many bad message logs). 6. Try other networking protocols on that interface. 7. Notice no other networking protocols experience issues. When you open a raw layer 2 socket, in addition to the MAC sublayer appended padding being delivered, you may also be delivered the 4-byte fcs. Please note that the ability to pass fcs to MAC clients is defined in IEEE 802.3. IEEE 802.3 section 4.2.7.3: passReceiveFCSMode: Boolean; {Indicates the desired mode of operation, and enables passing of the frame check sequence field of all received frames from the MAC sublayer to the MAC client. passReceiveFCSMode is a static variable} On Tue, 13 Jun 2023 21:39:25 -0700, Richard Cochran wrote: > (Tacking on suffixes between PHY/MAC and device driver are > unproblematic, because the driver can remove the offending cruft.) I'm not actually sure this would be proper. Since these suffixes would have to change the FCS going to the MAC, and IEEE 802.3 mandates that all padding (basically what these suffixes are) be returned to the MAC client if FCS reception is enabled. IEEE 802.3 section 4.2.9 Frame Reception: When the MAC sublayer operates in the mode that enables passing of the frame check sequence field of all received MAC frames to the MAC client (passReceiveFCSMode variable is true), it shall not strip the padding and it shall leave the data field of the MAC frame intact. Also more corrections to my previous email: On Wed, 14 Jun 2023 11:48:11 -0400, Dylan Robinson wrote: > The relay devices that MOTU sells and I work on will accept frames > with trailing padding and transmit frames without it. This really should have said that it will accept frames with *excessive* trailing padding, and transmit frames without *exsessive* trailing padding. This is because all frames need to be padded to at least minFrameSize bits.
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel