> AFAICT, receiving the FCS is totally useless. After all, it must be > correct, otherwise the MAC would drop the frame.
I don’t know the context of this argument, but what I can say for a fact is that this is not not a true statement. A NIC is free to decide to filter out the CRC if it wants, or to forward it if it wants. There are lots of good reasons to do both. There’s no part of the Linux TCP/IP stack that either explicitly requires or denies a NIC from doing this. And the Linux TCP/IP stack works correctly in either case. Again I don’t know the context. But If PTP4L is making some assumption that a raw Ethernet does not include a CRC, that’s a broken assumption. Furthermore, some switches (Eg Arista and and Cisco) use the CRC to convey timestamps in packets. It would be absolutely necessary to be able to see the “CRC” for this this use case, on the same interface that PTP traffic traverses, even if PTP traffic itself is unaffected. ----------- Sent from my phone, sorry about the typos. > On 28 Oct 2020, at 03:58, Richard Cochran <richardcoch...@gmail.com> wrote: > > > AFAICT, receiving the FCS is totally useless. After all, it must be > correct, otherwise the MAC would drop the frame. _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
