这是一个创建于 1412 天前的主题，其中的信息可能已经有所发展或是发生改变。
流量路径：macbook —-> 旁路由 —-> 主路由，去程包源 IP 是 macbook 源 mac 是旁路由的，抓包发现主路由侧主动丢包了。仅在 wifi 下存在这个行为，有线客户端没事，看起来很像一种 wifi 的一种安全策略，会拒掉 wifi 终端 ip 与 mac 不一致的包。
之前某讯主路由没事，现在换了小米和 tplink 的都存在这个行为，谁了解 wifi 这块行为，求指点。
 |
1
AngryK 2021-01-09 10:35:45 +08:00 via iPhone
我不是开发，这个应该是 WiFi 的策略我转给技术同事看下吧
|
 |
2
paradislover 2021-01-09 10:42:29 +08:00 via Android  1
WiFi 是 mac 层的，不 care ip
|
 |
3
Donahue 2021-01-09 11:48:30 +08:00
会不会是因为小米跟 tp 防止 arp 攻击导致的？
|
 |
6
futuregaget 2021-11-01 14:16:41 +08:00
卧槽卧槽，我遇到这个问题了
一个包先在主路由二层转发到旁路由，旁路由三层转发回来 导致一个包在主路由出现两次 client mac->旁路由 mac 变成了 旁路由 mac->主路由 mac 更牛逼的是，必须是无线进来的流量才有这个问题，有线进来的流量没这个坑，也就是说，如果一个流量从无线进来一次，在看到从其他地方过来的，就会扔掉。。。 |
|
7
futuregaget 2022-01-15 18:10:21 +08:00
这个问题我进一步研究了下，倒不是安全策略
ax3600 现在可以进 shell 。 以通过路由转发同子网流量为例，可以看到流量第一次进路由的时候，就有 conntrack 记录。虽然是二层转发（也确实是二层转发，不会给你解包到 3 层，对端看到的 srcmac 也是真实的 scrmac ），但是使用 iptables -i br-lan 能看见 wifi 进来的流量。这个是不正常的，可以试试，是看不见网线过来的二层转发流量的。 旁路由场景，等流量正式的以 3 层转发的形式从旁路由过来的时候，因为之前存在 conntrack ，流量无法进入 nat 表，nat 表只处理没有 conntrack 记录的包，有 conntrack 记录需要通过 cstate 模块进行转发，对于现在的流量来讲它是有 conntrack 记录的，但是没有回包，第二次进来的流量被认为是同一个 contrack 的同方向新包，直接丢弃 |
|
8
futuregaget 2022-01-15 18:11:22 +08:00
以为的 case 为例，我比较倾向于 wifi 的网卡桥接 br-lan 这个地方，linux 和高通有一方没搞对
|
|
9
futuregaget 2022-01-15 18:12:30 +08:00
@paradislover
是的，但是我验证出来，虽然确实不 careIP ，但是只要是 wifi 进来的流量，就算是二层 forward ，conntrack 表也有记录 |
Select Language