Linux绑定eth1的UDP socket无法接收tcpdump可见广播包

你遇到的现象属于典型的“二层能抓包、三层协议栈丢包”场景：tcpdump通过PF_PACKET套接字在数据链路层捕获流量，时机早于IP层的地址匹配、路由校验、防火墙过滤逻辑，所以哪怕协议栈后续把包丢弃了，tcpdump也能正常显示。
具体到你的代码，收不到包的核心原因是Linux网络栈从未把捕获到的UDP广播包匹配到你创建的应用套接字上。

具体错误点 #

• 绑定地址不符合广播包匹配规则：代码中bind调用使用了存储eth1单播IP 192.168.253.10的rwhoBroadcastAddr结构体，最终套接字被绑定到192.168.253.10:7000。按照Linux内核的UDP套接字匹配逻辑，绑定到具体单播地址的套接字，只会接收目的地址恰好等于该单播IP的UDP包，根本无法匹配目的地址为子网广播地址192.168.253.255的广播包。这就是为什么tcpdump能抓到包，应用却一直阻塞的核心原因。
• 代码结构冗余无效：把套接字创建、配置、接收的整套逻辑放进while(true)循环，实际因为第一次recvfrom就会永久阻塞，根本不会触发第二次循环执行套接字重建逻辑，属于完全无用的代码结构。
• 输出格式错误：用C++的cout搭配C风格的%d占位符，后续哪怕成功收到数据，打印的输出也会不符合预期，不会显示实际的字节长度。
• 冗余定义未使用的变量：代码里定义了broadcastPermission变量但从未参与任何逻辑配置，要注意接收广播本身不需要开启SO_BROADCAST选项，这个选项仅在发送广播时是必须配置的。

1. 修正bind目标：把bind调用的参数从&rwhoBroadcastAddr换成提前初始化好的、绑定INADDR_ANY（0.0.0.0）地址的rwhoSrcBroadcastAddr结构体，也就是将套接字绑定到0.0.0.0:7000。这样内核在匹配时，会把所有目的为7000端口的单播、广播包匹配到这个套接字上；再配合你已经配置的SO_BINDTODEVICE绑定eth1的逻辑，套接字只会处理来自eth1接口的流量，不会被其他接口的同端口数据干扰。
2. 调整代码结构：把套接字创建、setsockopt配置、bind的逻辑全部移到while循环外面，仅在程序启动时执行一次；循环内部只做recvfrom接收和数据打印的逻辑，避免不必要的套接字重建开销。
3. 修正打印格式：把cout里的C风格占位符换成C++流式输出，比如将std::cout << "nBytes = %d \n" << nBytes << std::endl;修改为std::cout << "nBytes = " << nBytes << " \n" << std::endl;，同理修改接收内容的打印逻辑，保证输出正确。
4. 可选优化：从tcpdump输出看广播包是固定88字节，不需要使用MSG_WAITALL标志，直接去掉该参数即可，避免因为包长度偏差导致的不必要阻塞。

如果按上述修改后仍无法收到包，可以依次排查：

• 内核反向路径过滤规则：执行sysctl net.ipv4.conf.all.rp_filter，如果值为1（严格校验模式），可能会因为源地址路由校验异常丢弃广播包，可临时设置为0测试：sysctl -w net.ipv4.conf.all.rp_filter=0、sysctl -w net.ipv4.conf.eth1.rp_filter=0。
• 防火墙规则：检查iptables INPUT链是否有丢弃7000端口UDP广播的规则，可临时清空规则测试连通性。
• 从现有tcpdump输出看，广播包的UDP校验和是正常的，不需要额外检查二层校验问题。

内容的提问来源于stack exchange，提问作者Jagadish