研究一个路由器行为的问题

[owenliang]

流量路径：macbook —-> 旁路由 —-> 主路由，去程包源 IP 是 macbook 源 mac 是旁路由的，抓包发现主路由侧主动丢包了。仅在 wifi 下存在这个行为，有线客户端没事，看起来很像一种 wifi 的一种安全策略，会拒掉 wifi 终端 ip 与 mac 不一致的包。

之前某讯主路由没事，现在换了小米和 tplink 的都存在这个行为，谁了解 wifi 这块行为，求指点。

[AngryK]

我不是开发，这个应该是 WiFi 的策略我转给技术同事看下吧

[paradislover]

WiFi 是 mac 层的，不 care ip

[Donahue]

会不会是因为小米跟 tp 防止 arp 攻击导致的？

[owenliang]

@AngryK 谢谢

[owenliang]

@Donahue 我也有类似的怀疑，只是不方便登录 tplink 做分析

[futuregaget]

卧槽卧槽，我遇到这个问题了
一个包先在主路由二层转发到旁路由，旁路由三层转发回来
导致一个包在主路由出现两次
client mac->旁路由 mac
变成了
旁路由 mac->主路由 mac

更牛逼的是，必须是无线进来的流量才有这个问题，有线进来的流量没这个坑，也就是说，如果一个流量从无线进来一次，在看到从其他地方过来的，就会扔掉。。。

[futuregaget]

这个问题我进一步研究了下，倒不是安全策略
ax3600 现在可以进 shell 。
以通过路由转发同子网流量为例，可以看到流量第一次进路由的时候，就有 conntrack 记录。虽然是二层转发（也确实是二层转发，不会给你解包到 3 层，对端看到的 srcmac 也是真实的 scrmac ），但是使用 iptables -i br-lan 能看见 wifi 进来的流量。这个是不正常的，可以试试，是看不见网线过来的二层转发流量的。
旁路由场景，等流量正式的以 3 层转发的形式从旁路由过来的时候，因为之前存在 conntrack ，流量无法进入 nat 表，nat 表只处理没有 conntrack 记录的包，有 conntrack 记录需要通过 cstate 模块进行转发，对于现在的流量来讲它是有 conntrack 记录的，但是没有回包，第二次进来的流量被认为是同一个 contrack 的同方向新包，直接丢弃

[futuregaget]

以为的 case 为例，我比较倾向于 wifi 的网卡桥接 br-lan 这个地方，linux 和高通有一方没搞对

[futuregaget]

@paradislover
是的，但是我验证出来，虽然确实不 careIP ，但是只要是 wifi 进来的流量，就算是二层 forward ，conntrack 表也有记录