MSS钳制(mtu)已勾选，但防火墙规则并未生效，造成大部分ipv4网站无法打开或打开缓慢，图片无法加载等问题

[resnou]

反馈bug/问题模板，提建议请删除

1.关于你要提交的问题

Q：是否搜索了issue (使用 "x" 选择)

• [x] 没有类似的issue

2. 详细叙述

(1) 具体问题

A： 编译最新的固件，第一次打开路由器时，MSS钳制正确设置了防火墙规则。（如下图）

在路由器界面设置pppoe拨号并重启路由器后，再次进入防火墙查看，发现该规则为空，也就是【表: Mangle】里面都为空。 尝试重启防火墙、重启路由器等操作，【表: Mangle】里面依旧为空。

执行以下命令： iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu 此时【表: Mangle】里面如下图 这个时候已经可以正常的上网了。

这时候再次重启防火墙，之前无论如何都出现不了的MSS钳制的防火墙规则就会出现了。 另外在Turbo ACC中设置全锥型 NAT为高性能模式的话，防火墙中也没规则，改成兼容模式就会出现规则。

(2) 路由器型号和固件版本

A：路由器为tp-link xdr6088，固件为最新版本

(3) 详细日志

未在系统日志中找到相关报错

[resnou]

感觉这几个人的情况可能与我的情况相似 https://github.com/coolsnowwolf/lede/issues/10731 https://github.com/coolsnowwolf/lede/issues/10726 尤其是这个https://github.com/coolsnowwolf/lede/issues/9390 ，当时的症状和他的一模一样。

[binge8]

确实有这个现象，部分网站或APP加载很慢，图片加载不出来，有些app还得换手机网才能正常使用

[WYC-2020]

等会瞧下

[resnou]

等会瞧下

在MSS钳制的防火墙规则出现后，再重启防火墙，之前我执行的那两条防火墙语句就会失效，但是MSS钳制的防火墙规则却不会失效，就会一直存在了。 这个情况还挺特殊，跟我同设备的人没遇到，但是我遇到了，我刷了他的固件还是存在这个问题，他却没有这个问题。 有人关闭了ipv6后就解决了这个问题。比如他：https://github.com/coolsnowwolf/lede/issues/10725#issuecomment-1374496050 不清楚他们遇到的问题是不是和我相同，但是症状非常像。

[WYC-2020]

我这边亲测不存在你那样的问题，不管是重启路由器还是防火墙 一直都有，无法复现出来，这个可能的你自己排查是否有什么插件冲突

[reimnm]

我这边亲测不存在你那样的问题，不管是重启路由器还是防火墙 一直都有，无法复现出来，这个可能的你自己排查是否有什么插件冲突

Firmware: firmware

Environment: KVM Nic model = virtio

lede: All default settings

Result: First boot:

Reboot:

Without TCP MSS settings for the pppoe-wan interface, the pppoe protocol will not work properly.

[WYC-2020]

我把我这边固件发给你们 你们用下看看会不会出现这个问题，建议是别保留配置升级，你们可以先全新建一个 然后用这个固件 看下 会不会出现你们那个问题，然后在还原到你们的使用环境 https://cloud.189.cn/t/bUfyeuA36Vbi （访问码：7mov）

[resnou]

我把我这边固件发给你们 你们用下看看会不会出现这个问题，建议是别保留配置升级，你们可以先全新建一个 然后用这个固件 看下 会不会出现你们那个问题，然后在还原到你们的使用环境 https://cloud.189.cn/t/bUfyeuA36Vbi （访问码：7mov）

我之前的设备是x86，xdr6088当ap。用起来没任何问题。 后来暗云在恩山发了xdr6088固件，我刷了他的固件后，移除了x86，直接用xdr6088当路由，就遇到这个问题，但是别人却没遇到。 然后尝试自己编译固件（固件中不包含mwan3、去广告等插件），也是这个问题。经过多次排查后，才定位到mtu的问题。

[WYC-2020]

我把我这边固件发给你们 你们用下看看会不会出现这个问题，建议是别保留配置升级，你们可以先全新建一个 然后用这个固件 看下 会不会出现你们那个问题，然后在还原到你们的使用环境 https://cloud.189.cn/t/bUfyeuA36Vbi （访问码：7mov）

我之前的设备是x86，xdr6088当ap。用起来没任何问题。 后来暗云在恩山发了xdr6088固件，我刷了他的固件后，移除了x86，直接用xdr6088当路由，就遇到这个问题，但是别人却没遇到。 然后尝试自己编译固件（固件中不包含mwan3、去广告等插件），也是这个问题。经过多次排查后，才定位到mtu的问题。

那就不清楚了，我只会用86当主路由，其他路由器当ap，要不然性能不够，成瓶颈

[AX200]

和我的情况非常相似，请问博主使用什么办法解决的呢？ 我的情况如下 ipv6.baidu.com正常访问 baidu.com打不开 https://test6.ustc.edu.cn/ 测速网站ipv6测速正常，ipv4无速度，甚至页面都打不开。 我的问题固件都是出现在添加passwall插件后出现的，如果不添加passwall改为使用ssrp则不会出现该问题。 之前采用了一些玄学方法，关闭防火墙的启用 SYN-flood 防御，就能够正常访问ipv4网页，但是重置后再使用该方法则无效了。

[resnou]

和我的情况非常相似，请问博主使用什么办法解决的呢？ 我的情况如下 ipv6.baidu.com正常访问 baidu.com打不开 https://test6.ustc.edu.cn/ 测速网站ipv6测速正常，ipv4无速度，甚至页面都打不开。 我的问题固件都是出现在添加passwall插件后出现的，如果不添加passwall改为使用ssrp则不会出现该问题。 之前采用了一些玄学方法，关闭防火墙的启用 SYN-flood 防御，就能够正常访问ipv4网页，但是重置后再使用该方法则无效了。

首先检查是否存在MSS钳制规则：

状态->防火墙，拉到最下面。找到【表: Mangle】。 查看里面是否存在【TCPMSS】。如果存在两条，那说明不是这个问题，不用进行后续操作。

如果不存在两条【TCPMSS】，进行如下操作：

网络->防火墙->自定义规则，在规则中加入如下 iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu

[ -n "$(command -v ip6tables)" ] && ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu

然后点击下方重启防火墙按钮（点击两次，点击第一次后等个10秒左右，再点击第二次）。 然后再去状态->防火墙，拉到最下面。找到【表: Mangle】

顺利的话，你会看到下图（一共三条规则）： 这时候，你再回到防火墙界面 在刚才你添加进防火墙的规则之前加入#（井号表示注释。相当于取消之前执行的规则）。 也就是如下规则： #iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu

#[ -n "$(command -v ip6tables)" ] && ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu 再次点击重启防火墙。

再次进入状态->防火墙，拉到最下面。找到【表: Mangle】。 查看是否存在两条【TCPMSS】，如果存在的话，说明你和我的情况一样，以后每次开机后就这么重复执行一次即可。

[AX200]

和我的情况非常相似，请问博主使用什么办法解决的呢？ 我的情况如下 ipv6.baidu.com正常访问 baidu.com打不开 https://test6.ustc.edu.cn/ 测速网站ipv6测速正常，ipv4无速度，甚至页面都打不开。 我的问题固件都是出现在添加passwall插件后出现的，如果不添加passwall改为使用ssrp则不会出现该问题。 之前采用了一些玄学方法，关闭防火墙的启用 SYN-flood 防御，就能够正常访问ipv4网页，但是重置后再使用该方法则无效了。

首先检查是否存在MSS钳制规则：

状态->防火墙，拉到最下面。找到【表: Mangle】。 查看里面是否存在【TCPMSS】。如果存在两条，那说明不是这个问题，不用进行后续操作。

如果不存在两条【TCPMSS】，进行如下操作：

网络->防火墙->自定义规则，在规则中加入如下 iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu

[ -n "$(command -v ip6tables)" ] && ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu

然后点击下方重启防火墙按钮（点击两次，点击第一次后等个10秒左右，再点击第二次）。 然后再去状态->防火墙，拉到最下面。找到【表: Mangle】

顺利的话，你会看到下图（一共三条规则）： 这时候，你再回到防火墙界面 在刚才你添加进防火墙的规则之前加入#（井号表示注释。相当于取消之前执行的规则）。 也就是如下规则： #iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu

#[ -n "$(command -v ip6tables)" ] && ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o pppoe-wan -j TCPMSS --clamp-mss-to-pmtu 再次点击重启防火墙。

再次进入状态->防火墙，拉到最下面。找到【表: Mangle】。 查看是否存在两条【TCPMSS】，如果存在的话，说明你和我的情况一样，以后每次开机后就这么重复执行一次即可。

我重置了系统，重新验证了你的几个步骤。 设置LAN口和WAN口后无法访问ipv4网页，但ipv6可以正常访问 此时查看【表: Mangle】，里面没有数据 输入两行代码并重启防火墙后出现三条规则 并且网络正常。 我的情况和你应该是一样的。

[resnou]

@AX200 记得注释掉你输入的两条防火墙命令，然后点击重启防火墙按钮，这样相当于你对防火墙没有做任何操作，然后激活了MSS钳制。 目前不清楚为什么会造成这种问题。希望后续能有人弄明白，或者linux内核升级后能解决这个问题吧。

[xsm1997]

遇到了同样的问题，经过排查问题是由commit https://github.com/coolsnowwolf/lede/commit/9364fa6e6ca3485767a70556d6f1fb09b3e09f4b 引入。

这个commit回滚了firewall (fw3)的版本，目的是解决lock的问题。在revert掉这个commit之后，mss钳制就好了。

如果我没理解错的话，这个lock问题应该指的是开了某些插件（比如luci-app-unblockmusic）之后，运行/etc/init.d/firewall restart会直接卡住，一直在等待锁的释放。这个问题是因为这些插件在firewall hook脚本里面重启了firewall，导致死锁。可以参考https://github.com/DHDAXCW/DoorNet_Series/blob/master/patches/001-fix-firewall.patch （初始来源未知）的做法，在firewall的init脚本里面强制释放掉锁。

@coolsnowwolf 可以参照patch来修改一下。

[ychongcn]

遇到了同样的问题，经过排查问题是由commit 9364fa6 引入。

这个commit回滚了firewall (fw3)的版本，目的是解决lock的问题。在revert掉这个commit之后，mss钳制就好了。

如果我没理解错的话，这个lock问题应该指的是开了某些插件（比如luci-app-unblockmusic）之后，运行/etc/init.d/firewall restart会直接卡住，一直在等待锁的释放。这个问题是因为这些插件在firewall hook脚本里面重启了firewall，导致死锁。可以参考https://github.com/DHDAXCW/DoorNet_Series/blob/master/patches/001-fix-firewall.patch （初始来源未知）的做法，在firewall的init脚本里面强制释放掉锁。

@coolsnowwolf 可以参照patch来修改一下。

请问怎么revert掉这个commit，新手不懂，还望赐教！谢谢你。

[xsm1997]

遇到了同样的问题，经过排查问题是由commit 9364fa6 引入。 这个commit回滚了firewall (fw3)的版本，目的是解决lock的问题。在revert掉这个commit之后，mss钳制就好了。 如果我没理解错的话，这个lock问题应该指的是开了某些插件（比如luci-app-unblockmusic）之后，运行/etc/init.d/firewall restart会直接卡住，一直在等待锁的释放。这个问题是因为这些插件在firewall hook脚本里面重启了firewall，导致死锁。可以参考https://github.com/DHDAXCW/DoorNet_Series/blob/master/patches/001-fix-firewall.patch （初始来源未知）的做法，在firewall的init脚本里面强制释放掉锁。 @coolsnowwolf 可以参照patch来修改一下。

请问怎么revert掉这个commit，新手不懂，还望赐教！谢谢你。

在源码目录运行git revert 9364fa6e6ca3485767a70556d6f1fb09b3e09f4b，然后参考那个001-fix-firewall.patch修改相应文件（其实就是加了几句代码，如果你不用到unblockmusic等插件，可以不做）。

[miaoermua]

lean 回滚了一版 https://github.com/coolsnowwolf/lede/commit/a4426eb5a4c089ce03f915feb5a838efeec219cb 应该好了，待编译核实