网络工程 - 部分以太网 crc 出现在 tcpdump 中 - 吾爱随笔录

我正在我的 Digilent Nexus4 DDR FPGA 上测试以太网传输。我创建了一个非常简单的数据包，其中包含广播目标地址和一些组成的以太网类型。这是在 tcpdump 中捕获的数据包。

05:58:22.148546 00:00:00:00:00:00 (oui Ethernet) > Broadcast, ethertype Unknown (0xebeb), length 66: 
    0x0000:  ffff ffff ffff 0000 0000 0000 ebeb 0000
    0x0010:  0000 dead beef 0000 0000 0000 0000 0000
    0x0020:  0000 0000 0000 0000 0000 0000 0000 0000
    0x0030:  0000 0000 0000 0000 0001 0203 0405 0607
    0x0040:  27ae

在我发送的数据包中0x01 0x02 0x03 0x04 0x05 0x06 0x07，我可以在数据包中清楚地看到最后几个字节。然而，捕获的数据包不是以 0x07 结束，而是包含 0x27ae，它恰好是我的 CRC 码的前两个字节。当我使用chipscope检查输出信号时，看起来我只是在传输0x07，然后按预期为crc传输另外4个字节。我将 fpga 中的以太网插入桌面上的 USB 以太网适配器，因为主板上的以太网端口用于通过路由器连接到互联网。USB 网卡是“AmazonBasics USB 3.0 到 10/100/1000 千兆以太网适配器”。

然后我想也许卡上的 phy 正在为我创建一个 crc，所以我故意翻转了 crc 的第一个字节中的位，我停止接收数据包。在 ifconfig 中，我可以看到错误数据包被丢弃。所以看起来虽然我电脑上的以太网适配器正在检查完整的 4 字节 crc，但它也在将它的前半部分传输到计算机。

我尝试的下一个实验不是将我的 FPGA 连接到 USB 以太网适配器，而是将它直接插入我的路由器。由于我使用的是广播以太网目的地，我认为数据包将通过其主板内置的 nic 路由回我的电脑，从而跳过 USB 以太网适配器。这有效，数据包中的最后一个字节实际上是 0x07，我在转储中没有看到任何我的 crc。然后，在保持 fpga 连接到路由器的同时，我断开了主板与路由器的连接，并将 USB 以太网适配器连接到路由器。现在，当我从 fpga -> router -> usb ethernet 收到数据包时，它再次包含了 crc 的一部分。所以看起来问题出在我的 USB 适配器而不是 FPGA 上。

我以为我的 USB 适配器可能有问题，但我可以毫无问题地浏览互联网。但是，我能想到的大多数协议（如 TCP 或 UDP）都有一个长度字段，因此它们可能无论如何都忽略了额外的两个字节数据。这是某些网卡的正常行为吗？我认为这可能与卡在意识到它在 crc 中之前仅传输部分 crc 的延迟有关。