背景与痛点
在常规路由器模式下，一台华硕 TUF-6500 (Qualcomm BE6500方案) 路由器接入房东的物理局域网。由于整栋楼使用的是不具备隔离功能的傻瓜交换机，网络中充斥着海量的 ARP 广播和非法的 DHCP 服务（如多个 DHCP 冲突干扰）。
严重症状：
- 路由器 WAN 口物理链路频繁闪断（系统日志疯狂提示：
PHY Link is down->PHY Link up speed: 100/speed: 10循环交替）。 - 接口崩溃后，华硕网络守护进程反复重新协商上网凭证，导致网络几乎处于彻底瘫痪状态。
- 严重时，非法报文直接导致系统核心域名解析进程（
dnsmasq）发生内存越界，系统内核彻底崩溃（Kernel Panic / Oops）并引发硬重启。
经过PC机直接接入网络抓包，局域内有大量ARP报文泛洪，且有多个DHCP服务运行。
严重时导致网络接口不断协商，陷入连接、断开循环。
回到路由器处理也是一波三折，从 port counter get 2 的统计结果来看， WAN 口（Port 2）接收了大数据，并且由于缓冲区爆满，芯片已经在硬件层发生了严重的被动丢包（rx_drop_pkt_cnt 达 11054个），这充分证实了大量的垃圾广播流量已经逼近了交换芯片的物理极限，导致物理层链路（PHY）不断断开重连。
而且路由器为阉割版（虽然700多买的），部分实用命令不存在，风暴控制功能保留命令菜单，但在当前固件的硬件抽象层（HAL）中并没有实现这个功能（返回了 This request is not support），说明硬件风暴控制被固件锁死或裁减了。
同样，ACL可以创建列表、绑定接口，创建规则，但无法激活规则，并未实装此功能：
设置二层ebtables规则由于作用不到WAN口eth0，也是无用：
ebtables -A INPUT -p ARP –arp-mac-src 3c:46:d8:3d:fb:6e -j ACCEPT
ebtables -A INPUT -p ARP –arp-mac-dst 10:7c:61:df:0e:e8 -j ACCEPT
ebtables -A INPUT -p ARP -j DROP
ebtables -A INPUT -p ARP –arp-mac-dst 10:7c:61:df:0e:e8 -j ACCEPT
ebtables -A INPUT -p ARP -j DROP
虽然三层iptables无法拦截 ARP 欺骗，可以用来阻止其它 DHCP NAK，但INPUT 链捕获不到流量。
根本原因深度剖析
1. 为什么 ebtables / iptables 默认规则无效？
高通这颗工业级 IPQ5332 芯片 拥有 NSS 硬件网络加速引擎。从 WAN 口（
eth0）进来的绝大多数二层/三层流量，在网卡驱动层面直接走硬件级的高速转发（Fast Path），完全绕过了 Linux 传统的 Netfilter 防火墙。这就导致在 filter 表 INPUT 链上写的规则直接沦为摆设，计数器卡在 0。2. 为什么物理网卡会高频闪断？
当几万个无用 ARP 广播和非法数据流灌进 WAN 口时，即使上层系统不处理，高通网卡芯片（PHY）在硬件层面依然要全盘接收电气信号并进行高速流分类。当流量超越极限，芯片内部的硬件缓冲区（Buffer）瞬间溢出，触发硬件过载保护机制，导致 PHY 接口假死断开。
页码： 1 2