1、WLAN二层隧道下PPPOE拨号后web页面无法打开问题分析,目录,问题描述,故障分析,故障定位及结论,解决方案,问题描述,故障主题: PPPOE拨号后， WEB页面无法打开故障详细描述: 连云港移动WLAN网络出现连接CMCC-YWSPC（PPPOE认证方式）后出现上QQ正常，但WEB页面无法打开的故障现象，而且在AC版本升级到V1.2.1(支持PEAP认证方式)后，故障依旧,目录,故障分析,问题描述,故障定位及结论,解决方案,故障分析,现场AC、AP组网拓扑图：,故障分析,目前现场AC版本: 增强型综合业务板 V1.2.1版本先前AC版本（V1.2版本）升级前：出现该故障：在PPPOE拨号
2、后，从用户ping sina，sohu的网站是可以ping通的,故障分析,但是能PING的这几个网站，web界面在用户侧都无法正常打开。,故障分析,通过在用户侧和AC侧同时抓包发现，这个数据部分的长度是1408个字节,故障分析,正常情况下数据包的组成如图所示：,因为采用pppoe拨号的认证方式，又会多加8个字节的pppoe的头，所以总字节数为20+8+6+18+20+20+1408+8=1508 超过1500字节，经研发确认由于连云港移动该AC设备是二层隧道组网的模式，存在AC分片的问题，导致WEB界面无法打开的故障现象，已经在其他省份也出现类似故障，需要升级补丁版本才能解决该问题。,故障分析
3、,针对AC版本升级后故障现象依旧的现象，在用户侧和AC侧重新进行抓包，尽快定位及解决故障。到AC机房后，进行AC侧和用户侧同时进行报文的抓取，AC侧报文如下：发现数据部分的长度还是1408字节，AC上没有进行分片处理。,故障分析,通过命令的方式在业务板上把tcp-mss 改成1300后，现场通过抓包软件确定MTU值还是1408字节的包，而且存在重传的现象。,故障分析,至此基本确定原因为升级后的（V1.2.1）版本制定时没有考虑到目前现网还存在PPPOE认证的方式来实现WLAN业务，从而导致升级的V1.2.1版本对超过1408的数据分片没有效果，因此原来故障现象依旧，通过核查两处代码，也可以发现
4、该问题：tcp-mss对PPPOE二层隧道不生效，原代码问题在Ether_InputHandler函数中，对于目的MAC不是AC的报文，将进行二层隧道的tcp-mss修改处理，具体代码为：if (g_rmios_tcp_mss_num)if (mFlagMatch(m, MBF_WLAN_L2) | (gTrunkPortMask 从上述源代码，可以很清楚地知道对PPPOE的tcp-mss不支持；,故障分析,RMIOS对PPPOE下行方向二层隧道分片不生效，原代码问题L2_PacketForward在通过目的MAC地址查二层转发表后，如果报文是发给STA的，那么通过构造二层隧道往STA发包，具
5、体流程如下：if (pfwd-property /*此处WLAN_TUNNEL_MTU =1448*/ ,故障分析,注意上述代码和IP报文长度截图，即此时MTU=1448，而IP包头也正好等于1448字节，在后续流程中肯定不会对此报文进行分片。,目录,故障定位及结论,问题描述,解决方案,故障分析,故障定位及结论,由于连云港移动这边，AC采用二层隧道的组网方式，因此在PPPOE拨号认证方式的情况下，江苏目前已下发支持PEAP认证方式的AC版本（V1.2.1）,但由于新升级（V1.2.1版本）制定时没有考虑到目前二层隧道组网模式下，还存在PPPOE认证的方式来实现WLAN业务，从而导致升级的V1.2.1版本对超过1408字节的数据分片没有效果，因此原来故障现象依旧。,目录,解决方案,问题描述,故障分析,故障定位及结论,解决方案,通过加载版本补丁解决，目前补丁版本已发布，并且正在其他地市进行试点。从厂家研发处获知类似问题只发生在AC起二层隧道组网的模式下，AC起三层 隧道的模式，不存在该问题，因此可以打算由目前二层隧道组网方式，修改为三 层隧道的组网方式。,
