基于MT7621平台的RAETH交换机收包异常致DHCP无法获IP求助

先梳理下你的核心问题：MT7621（RALINK）平台上，千兆以太网端口能正常上报链路Up/Down状态，但无法接收数据包，进而导致无法从br0桥接接口上的dnsmasq服务获取IP，且已确认硬件无故障。下面是我建议的逐步排查方案：

1. 确认桥接配置的正确性 #

首先要确保以太网端口确实被正确加入到br0桥接中：

brctl show br0

输出里应该能看到你的千兆以太网端口（比如eth0或lan0）和两个无线射频接口（比如wlan0、wlan1）都在br0的Interfaces列表里。如果没看到，手动添加端口到桥接：

brctl addif br0 <your-eth-port>

同时检查桥接接口和以太网端口的状态是否为Up：

ip link show br0
ip link show <your-eth-port>

确保两者的状态都是UP且LOWER_UP。

2. 验证DNSMASQ的配置与运行状态 #

既然DHCP服务由br0上的dnsmasq提供，先确认它是否正确监听了桥接接口：

• 查看dnsmasq配置文件（通常是/etc/dnsmasq.conf），确认存在以下配置之一：

  interface=br0  # 仅监听br0接口
  # 或者
  listen-address=<br0的IP地址>
  

• 检查dnsmasq是否正常运行：

  ps | grep dnsmasq
  

  确保进程存在，且没有异常启动参数。
• 查看dnsmasq的系统日志，排查是否有DHCP请求相关的记录或错误：

  logread | grep dnsmasq
  

  如果日志里完全看不到来自以太网端口的DHCP请求，说明数据包根本没到达dnsmasq服务。

3. 抓包定位数据包流向 #

这一步是关键，用来确认数据包是否真的没被以太网端口接收：

• 在以太网端口上抓取DHCP相关的数据包：

  tcpdump -i <your-eth-port> port 67 or port 68 -vvv
  

  连接测试设备后，如果看不到DHCP Discover包，说明端口确实没收到数据包；如果能看到，那问题出在桥接转发或dnsmasq的处理环节。
• 同时在br0桥接接口上抓包对比：

  tcpdump -i br0 port 67 or port 68 -vvv
  

  如果以太网端口能抓到包，但br0上没有，说明桥接转发存在问题。

4. 检查端口与桥接的高级配置 #

• 混杂模式：桥接的成员端口需要开启混杂模式才能接收非自身MAC的数据包，手动开启试试：

  ip link set <your-eth-port> promisc on
  

• VLAN过滤：如果以太网端口配置了VLAN规则，可能导致DHCP包被过滤，查看桥接的VLAN配置：

  bridge vlan show
  

  确保以太网端口和br0的VLAN配置一致（比如默认允许所有VLAN，或对应VLAN被放行）。
• 内核桥接过滤：检查内核是否开启了桥接的iptables过滤，如果开启的话，iptables规则可能会丢弃DHCP包：

  sysctl net.bridge.bridge-nf-call-iptables
  

  如果输出是1，查看iptables的FORWARD和INPUT链是否有DROP规则：

  iptables -L -n
  

  可以临时关闭桥接过滤进行测试：

  sysctl -w net.bridge.bridge-nf-call-iptables=0
  

5. 驱动与内核层面排查 #

虽然驱动能上报链路状态，但仍需排查收包路径的问题：

• 查看内核日志，找以太网端口相关的收包错误、中断异常：

  dmesg | grep <your-eth-port>
  

  比如有没有rx error、overflow之类的异常信息。
• 检查以太网端口的收发统计，是否有异常计数：

  ethtool -S <your-eth-port>
  

  查看rx_packets、rx_errors等统计值，如果错误数持续增加，可能驱动存在潜在问题。

最后建议 #

如果以上步骤都排查完还是没解决，可以尝试：

• 临时移除桥接，直接给以太网端口配置静态IP，测试是否能正常收发数据包，确认端口本身的收发功能是否正常。
• 替换dnsmasq为其他DHCP服务（比如udhcpd）进行测试，排除dnsmasq自身的问题。

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