终于找到华硕路由器经常掉线的原因（技术贴，小白勿入）

燃烧的木头

楼主苦逼程序员一枚，也是技术宅一个，入手的是华硕RT-AC66u，杭州电信100M光纤入户，PPPoE拨号方式上网。
跟很多人一样，我也发现PPPoE经常断开重连，起初怀疑是电信光宽带的问题，前前后后投诉了差不多10次，电信上门仪器测试，线路测试，各种方式都试过，还是一样，最后换了光猫依旧无改善
最后电信方面没办法了，叫我不要用路由，用windows拨号，看看会不会出现这样的问题，开玩笑！！用电脑拨号，我家里的手机、平板之类的怎么办？还有一系列的智能wifi插座都没法用了，想想其实问题也不大，断一下很快连上，玩游戏也就表现为卡顿一下，除了有点不爽，倒也还能勉强接受，就算了，没再去找电信扯皮了（无奈啊.........）

以上是背景，，交代完毕。

最近闲来无事，手痒，于是又来折腾这个问题。电信解决不了，那么咱就自己来，谁让咱是搞技术的呢？
鉴于还无法定位问题原因，最简单的办法就是排除法。首先，用TP-Link拨号，持续一个星期，没有断线，这让我很好奇，难道身价如此之高的AC66u，还比不上身价只有AC66u的十分之一的TP-Link？我只能说这不科学！！

开始以为是对非windows主机拨号都有限制，但是TP-Link也不是windows主机啊，莫非TP-Link是模拟windows主机的PPPoE拨号？
用wireshark抓包，发现TP-Link和windows主机拨号的包还是有区别的，再用RT-AC66u拨号，抓包后发现，RT-AC66u拨号和TP-Link拨号是一样的，这尼玛！！这什么情况？？难道真的是AC66u软件不稳定导致的？

拨号是一样的，那好。只有尝试分析一下拨号后的行为了，运气好的话说不定能发现点什么、、、
宽带一次只能用一个路由器拨号，我先打开抓包工具，用RT-AC66u拨号，拨号成功后一直等，观察到RT-AC66u拨号断线重拨3次之后，断开电源，保存抓包数据，判断依据是wan口的公网IP发生变化了。时间花了很久，大概4个小时。
接下来，同样用TP-Link拨号，抓包4个小时，保存抓包数据，接下来分析两次抓包数据的不同。

一番分析，结合自己对PPPoE的了解，终于发现了问题所在：“RT-AC66u拨号断线的原因是电信对echo请求没有响应，导致超时后自动断开”。而TP-Link拨号，是不主动发送echo请求的，只被动回应来自电信PPPoE服务器的echo请求。这就是问题所在！！

找到问题的根源了，那么我就顺便看看为什么4个小时断网重连3次，telnet到RT-AC66u，输入用户名和密码，打开/tmp/ppp/options.wan0，发现存在如下两个属性：
lcp-echo-interval 6
lcp-echo-failure 10
好家伙，6秒一次lcp-echo请求，10次收不到，就认为pppoe断开了。这本来也是正常的，国外用户没这个问题就是明证，可恶的电信运营商，为了节省服务器资源，不响应路由器发送的echo请求。咱们普通消费者也没办法——

按照这个原理，那也应该是60秒断线一次啊，为啥4个小时才断3次？？
原来服务器会主动间隔一段时间，发送一次echo请求，让路由器回应，证明PPPoE没有断开，每次路由器收到服务器发来的echo请求，就立即回应，然后知道PPPoE没有断开，重新开始计时这60秒。抓包数据显示，在断线前60秒内，确实没有收到电信PPPoE服务器发来的echo请求，然后自己发出去的
echo请求请求，电信服务器又不响应，然后可怜的RT-AC66u就以为PPPoE拨号连接断开了，于是重拨。。。

PS：
经过查阅相关资料，以及抓包核实，号windows下默认不发送请求，只回应来自对方的echo请求，这也是windows自带PPPoE拨号稳定不断线的原因。

发现这个问题后，我就把这个问题反馈给了华硕官方售后，一天后收到答复说已把问题反馈给后端开发人员，也不知道处理得怎么样了，一直在等新版正式固件发布。

微信扫一扫，阅读更方便^_^

涵哥

燃烧的木头 发表于 2015-8-12 19:35
哇塞，涵哥大驾光临，不胜荣幸！！
我抛砖引玉，引来了涵哥，还答复的这么详细，十分感谢。

我这边有一个方法，即删掉那两个lcp的规则，可以让你的AC66U不掉线。你可以试试
首先，你不要开双wan，然后在拨号成功之后，telnet进去
1.killall pppd
2.vi /tmp/ppp/options.wan0   ->移除lcp那两行
3.pppd file /tmp/ppp/options.wan0
经过这3个步骤，你在观察一下是否掉线

燃烧的木头

涵哥 发表于 2015-8-12 18:26
看到你的帖子之后，涵哥这边也进行了验证，发现这个问题如你所说，确实是运营商的问题，应为运营商没有响应 ...

哇塞，涵哥大驾光临，不胜荣幸！！
我抛砖引玉，引来了涵哥，还答复的这么详细，十分感谢。

涵哥的观点我深表赞同，确实是运营商的问题，我在帖子中也说了，就是“电信PPPoE服务器为了节省资源，不响应”造成的。但这个真没办法去找他们，总不能抓包截图投诉吧？所以说这个要去投诉操作难度还是挺大的、、他们会说，windows下拨号从来不掉线。

我想说的是，华硕官方应该顺应潮流，像windows自带拨号一样，不主动发echo请求就好了，这样也不会等不到服务器的echo回应而掉线重拨。反正PPPoE服务器会发echo请求过来，只要路由器回应了，就不会断开，路由器收到echo请求也知道连接没有断开。

这样皆大欢喜。像TP-Link等就是这么做的、

涵哥

燃烧的木头 发表于 2015-8-12 22:08
问题原因找到了，也报告给话说官方了，只希望能尽快修复这个问题

希望官方能重视这个问题

legend6013618

这个问题我也遇到过搞了我一个月，我也是找了电信换了猫。结果电信测线路一点问题都没有，是最新版的beta version 3.0.0.4.378.6117，你降级一下到3.0.0.4.376.3861或者beta version 3.0.0.4.378.4850 。我开始都不觉得华硕的固件会出现这么低级的掉线问题，结果后来降级一点问题都没有。我谷歌翻译了一下日志 的确是一个无响应问题问题导致无限重拨大概5分钟左右收不到一个回应，然后就继续重拨，可惜我道行不够没抓包，最后解决办法暂时降级固件就可以了

涵哥

看到你的帖子之后，涵哥这边也进行了验证，发现这个问题如你所说，确实是运营商的问题，应为运营商没有响应造成的。涵哥这边的运营商是正常响应的，所以没有这个问题。

以下为涵哥的验证步骤：
1.确认一下涵哥的AC68U的lcp-echo的时间间隔是不是和你的一样，

看了一下，和你的一模一样

2.然后就是抓包了，涵哥这边也是PPPOE的线路。发现当路由器每发一次lcp的request封包，就会有一个HUAWEI的设备进行reply。如下

所以，每次都会有响应，这样AC68U就不会断线了。

3.但是因为涵哥用的是HUAWEI的猫，所以怀疑是不是HUAWEI的猫在做reply，(内心想着猫不会这么高大上)，所以毅然的做了检查。如下

对比了一下，果然不是猫在做回应。那估计就是运营商的设备在做回应，想到这，感觉涵哥是幸福的，毕竟运营商能及时回应。


所以，最终的结论就是，有些华硕路由器WAN口掉线时，不是因为路由器本身原因，而是运营商懒得回应造成的。这个需要投诉

esavior001

能不能让梅林修复

燃烧的木头

esavior001 发表于 2015-8-10 21:11
能不能让梅林修复

不知道怎么反馈给梅林，。。。。

zyklon519

话说，我是北京联通100M光纤，为啥我没有这个问题呢？是联通和电信的差别么

13305612099

看了燃烧的木头的分析和涵哥的抓包图，更坚定了我不能再继续学习下去的决心了，一点基础都没有，隔行如隔山呀，还是能刷个固件就算了

燃烧的木头

zyklon519 发表于 2015-8-11 17:06
话说，我是北京联通100M光纤，为啥我没有这个问题呢？是联通和电信的差别么 ...

不是所有运营商都是这个样子的，另外PPPoE服务器负载大的时候，也可能不回应或者延迟较长时间回应的
你满速(或者接近满速)下载的时候，服务器echo回应，路由器也可能收不到。

我觉得这个就是固件的问题，干嘛不学windows自带拨号，不主动发echo请求，只回应服务器的echo请求？

燃烧的木头

13305612099 发表于 2015-8-12 19:08
看了燃烧的木头的分析和涵哥的抓包图，更坚定了我不能再继续学习下去的决心了，一点基础都没有，隔行如隔山 ...

涵哥是大神，我不过是抛砖引玉，没想到涵哥能来、

你也不要这么谦虚，我知道的也不多，知识都是慢慢积累起来的