LTE模块wwan0接口dhclient的select/epoll无法捕获DHCP应答

让我们一步步拆解你的问题：核心是无MAC、NOARP的点对点wwan0接口与dhclient的适配矛盾——tcpdump能抓到DHCP OFFER但用户态进程收不到，结合ftrace显示的ip_route_input_rcu()错误，问题基本锁定在网络层到用户态的数据包传递路径上，以下是具体分析和可落地的解决方向：

1. 先搞定ip_route_input_rcu()的路由错误 #

这个函数出错意味着IP层在处理DHCP应答时找不到匹配的路由规则，直接把包丢了。你可以这么排查：

• 先查内核日志（dmesg或/var/log/kern.log），找到该函数报错的具体信息（比如路由表匹配失败、无对应接收规则）。
• 临时添加一条广播路由试试：因为DHCP应答通常是广播包，而点对点接口默认可能没有接收广播的路由，执行这条命令后再跑dhclient测试：

  ip route add 255.255.255.255 dev wwan0
  

2. 检查dhclient的socket适配是否到位 #

你已经打了NOARP补丁，但可能还有socket配置没跟上wwan0的特殊属性：

• 确认dhclient是否把socket绑定到wwan0：用ss -udp -p | grep dhclient看socket状态，确保SO_BINDTODEVICE选项正确绑定到了wwan0接口。
• 开启广播接收权限：DHCP应答是广播包，需要给socket加SO_BROADCAST选项，你可以在补丁里补充setsockopt的代码，或者手动验证这个配置。
• 适配raw链路的协议类型：普通以太网用ETH_P_IP，但wwan0是无以太网头的raw帧，要确认dhclient的socket是否绑定了正确的链路层协议（比如直接处理IP包而不是以太网帧）。

3. 排查qmi-wwan驱动的rx处理逻辑 #

qmi_wwan_rx_fixup()是驱动里处理接收包的关键函数，tcpdump能抓到包说明链路层收到了，但驱动可能没把包修复成IP层能识别的格式：

• 查看这个函数的代码逻辑：它负责把usbnet收到的包转换成内核可处理的格式，对于无以太网头的raw帧，是否正确添加了伪头部？有没有误改包的源/目的IP？
• 加调试打印验证：在qmi_wwan_rx_fixup()里加代码，输出处理前后的数据包内容，和tcpdump抓到的包对比，确认驱动有没有完整传递DHCP应答包。

4. 验证DHCP应答包的合法性 #

虽然tcpdump抓到了包，但要确认包的内容是否符合dhclient的预期：

• 用tcpdump -i wwan0 -vvv udp port 67 or 68抓详细包，检查：
  • OFFER包的ciaddr字段是否为0（符合DHCP规范）。
  • 因为没有MAC，DHCP包的chaddr字段是否填充了模块的其他标识（比如IMEI、USB序列号）？dhclient能不能识别这个标识？
  • 应答包的目的IP是不是广播地址，有没有和wwan0的链路属性匹配？

5. 试试专门适配蜂窝模块的DHCP客户端 #

如果dhclient的补丁实在搞不定，可以换udhcpc（BusyBox自带的DHCP客户端）试试，它对特殊接口的兼容性更好，支持raw链路和NOARP模式：

udhcpc -i wwan0 -s /usr/share/udhcpc/default.script

如果udhcpc能成功拿IP，说明问题出在dhclient的适配逻辑上，你可以参考udhcpc的实现来完善你的补丁。

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