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
