接收UDP数据包

发布于 2025-01-18 04:47:32 字数 595 浏览 0 评论 0 原文

我目前正在使用FPGA和Ubuntu 20主机PC(防火墙关闭,经过不同的NICS测试)之间的UDP连接。对于发送UDP数据包,FPGA上实现了自定义以太网程序。在接收器侧,有一个简单的UDP服务器接收这些数据包。

问题是,我无法收到任何数据包。对简单的UDP服务器进行了测试,当我向另一台PC发送消息时,它可以工作。为了对FPGA进行故障排除,Wireshark用于监视流量。在Wireshark中,每个数据包都可以看到其数据,这意味着1-4层不负责()。甚至终端命令“ ip -s链接”也表明没有数据包被删除(

我如何找出数据包被丢弃的位置?

工作与“ FPGA” UDP-packet之间的差异:差异

I am currently working on a UDP connection between an FPGA and an Ubuntu 20 host pc (firewall turned off, different NICs tested). For sending UDP packets, a custom Ethernet program is implemented on the FPGA. On the receiver side, there is a simple UDP-server receiving these packets.

The problem is, that I can not receive any packets. The simple UDP-server was tested, and it works when I am sending messages from another pc to it. To troubleshoot the FPGA, Wireshark is used to monitor the traffic. In Wireshark, every packet with its data can be seen, which means that the layers 1-4 are not responsible (wireshark record). Even the terminal command "ip -s link" showed that no packets are dropped (terminal output).

How can I find out where the packet is dropped?

Difference between working and "FPGA" UDP-packet: difference

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

青春如此纠结 2025-01-25 04:47:32
  • 239.255.255.250不是有效的源地址,因为它是多播地址。多播地址的第一部分在224至239范围内(预留240-255供将来的扩展)。多播源地址没有意义,因此内核可能正在丢弃数据包。
  • 它也与接收器不同。我认为这没有区别,但是也许对于169.254子网(如果没有路由器,默认情况下)。尝试从169.254开始的源地址。
  • 它也太短了。 有效以太网数据包的最小尺寸为64个字节包括以太网CRC。您不必将所有字节用于UDP数据 - UDP长度可能比数据包短,并且额外的字节未使用。
  • 请验证IPv4标头校验和。我不确定为什么Wireshark不为您验证它。它必须是正确的,否则内核将删除数据包。
  • 239.255.255.250 is not a valid source address, because it's a multicast address. Multicast addresses have the first part in the range 224 to 239 (and 240-255 is reserved for future expansion). Multicast source address makes no sense and the kernel is probably discarding the packets for this reason.
  • It's also on a different subnet than the receiver. I don't think this makes a difference, but maybe it does for 169.254 subnet in particular (the one you get by default if there's no router). Try a source address starting with 169.254.
  • It's also too short. The minimum size of a valid Ethernet packet is 64 bytes including the Ethernet CRC. You don't have to use all the bytes for UDP data - the UDP length can be shorter than the packet, and the extra bytes are unused.
  • Do verify the IPv4 header checksum. I'm not sure why Wireshark isn't verifying it for you. It must be correct or the kernel will drop the packet.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文