【问题标题】:Linux recvfrom() can't receive traffic that Wireshark can seeLinux recvfrom() 无法接收 Wireshark 可以看到的流量
【发布时间】:2021-12-18 09:22:59
【问题描述】:

我正在使用一个硬件来生成打包在 UDP 数据包中的数据流。这些通过专用的 40Gb 以太网链路发送到另一块接收器硬件。不涉及集线器或交换机,只有一个发送器和一个接收器。

我们最近断开了接收器硬件的连接,并将其插入商用 Linux 工作站,以便通过软件接收数据流。我可以启动发送器硬件并在接收工作站上运行 Wireshark,我可以准确地看到我应该看到的数据。但是,如果我在执行 UDP recvfrom() 的接收器上启动一个单独的应用程序,它就看不到 Wireshark 可以看到的 UDP 数据包,它只会得到 recvfrom() 超时。我绑定到 Wireshark 报告为数据包目标的完全相同的 IP 地址和端口。 IP 地址是 192.168 私有子网,端口在 4000 的,所以它是“保留”而不是“众所周知”。将 IP 地址设置为 INADDR_ANY 没有任何区别。当我尝试进行 UDP 接收时,是否运行 Wireshark 没有任何区别。

如果发送者是另一个软件应用程序(诚然发送到工作站上的某个其他 NIC),则尝试接收的软件可以工作。我检查每个调用(socket()、setsockopt()、bind()、recvfrom())的返回状态,它们都声称成功。

接收数据的 NIC 是一个设置为 40Gb 以太网模式的 Mellanox ConnectX-4(我相信)。 MTU 设置为 9000,尽管数据流中的数据包要小得多(100-200 字节)。

什么条件会使数据包流对 Wireshark 可见但对其他应用程序软件不可见?会不会是网卡设置不对?以太网/IP/UDP 标头中是否存在可疑且不构成堆栈的标志?接下来我应该看哪里?

【问题讨论】:

  • 在 Wireshark 中挖掘其中一个数据包上所有折叠的标头字段 - 如果有一些无效的东西,我希望在那里的某个地方看到这个指示。另一种可能性是 NIC 未配置与设备目标地址在同一范围内的地址/网络掩码 - 在这种情况下,绑定到该地址将选择不同的接口。
  • 打开所有标题并没有显示任何危险信号(但我不是专家)。我使用的 IP 地址是 ip addr 为 Wireshark 正在侦听的 NIC 显示的地址。然而,我注意到了一些我以前没想过的东西。发送方作为目标的 MAC 地址不是 NIC 的 MAC 地址。 Wireshark 仍然可以看到流量是否有意义?网络堆栈不接受数据包当然是有道理的。我猜发件人不是 ARPing,而是使用硬编码的 MAC 地址。
  • 是的,如果发送设备硬编码 MAC 地址而不是使用 ARP,那肯定可以解释问题 - 在这种情况下,可以通过 MAC 欺骗来修复。 (Wireshark 不在乎,如果它只能看到定向到您机器的流量,那么它的用途将相当有限。)
  • 错误的 MAC 地址是关键问题(尽管还有其他问题相对容易解决)。事实证明,可以为发送硬件提供不同的 MAC 地址以供使用。我会提交一个答案来总结一下。
  • 您是否将设备设置为混杂模式?这很可能是 Wireshark “看到”数据而您的进程没有看到的原因

标签: linux wireshark recvfrom


【解决方案1】:

如上面的 cmets 所述,根本问题是发送硬件使用的目标 MAC 地址不是接收 NIC 的地址。事实证明,它以及 IP 地址都被硬编码在发送硬件中。并且硬件无法使用 ARP 来解决。发现这涉及交叉检查“ip addr show”的输出与 Wireshark 报告的内容。幸运的是,可以编写一个新的 MAC 地址供发送者使用。如果有的话,这里的教训是什么都不做,检查一切。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-09-16
    • 2011-11-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-04-15
    相关资源
    最近更新 更多