WLAN二层隧道下PPPOE拨号后web页面无法打开问题分析

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拨号后，从用户pingsina，sohu的网站是可以ping通的故障分析但是能PING的这几个网站，web界面在用户侧都无法正常打开。故障分析通过在用户侧和AC侧同时抓包发现，这个数据部分的长度是1408个字节故障分析正常情况下数据包的组成如图所示：因为采用pppoe拨号的认证方式，又会多加8个字节的pppoe的头，所以总字节数为20+8+6+18+20+20+1408+8=1508超过1500字节，经研发确认由于连云港移动该AC设备是二层隧道组网的模式，存在AC分片的问题，导致WEB界面无法打开的故障现象，已经在其他省份也出现类似故障，需要升级补丁版本才能解决该问题。故障分析针对AC版本升级后故障现象依旧的现象，在用户侧和AC侧重新进行抓包，尽快定位及解决故障。到AC机房后，进行AC侧和用户侧同时进行报文的抓取，AC侧报文如下：发现数据部分的长度还是1408字节，AC上没有进行分片处理。故障分析通过命令的方式在业务板上把tcp-mss改成1300后，现场通过抓包软件确定MTU值还是1408字节的包，而且存在重传的现象。故障分析至此基本确定原因为升级后的（V1.2.1）版本制定时没有考虑到目前现网还存在PPPOE认证的方式来实现WLAN业务，从而导致升级的V1.2.1版本对超过1408的数据分片没有效果，因此原来故障现象依旧，通过核查两处代码，也可以发现该问题：tcp-mss对PPPOE二层隧道不生效，原代码问题在Ether_InputHandler函数中，对于目的MAC不是AC的报文，将进行二层隧道的tcp-mss修改处理，具体代码为：if(g_rmios_tcp_mss_num){if(mFlagMatch(m,MBF_WLAN_L2)||((gTrunkPortMask&(0x1mPortGet(m)))&&l2fwdEnableTest(m))){if(ETHERTYPE_IP==ether_type){L2_TcpMssUpdate(m-mdata+netmail);}}}从上述源代码，可以很清楚地知道对PPPOE的tcp-mss不支持；故障分析RMIOS对PPPOE下行方向二层隧道分片不生效，原代码问题L2_PacketForward在通过目的MAC地址查二层转发表后，如果报文是发给STA的，那么通过构造二层隧道往STA发包，具体流程如下：if(pfwd-property&L2FWD_PROPERTY_SESSION_BIT){….pSession=sta_session_find(pfwd-staSessionid);…pTunnel=wtpTunnelGet(mEth,pSession-staTunnelId);if(pTunnel-property&WTP_TUNNEL_IPV6){}Else{构造二层隧道首部mMtuSet(mEth,WLAN_TUNNEL_MTU);/*此处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起三层隧道的模式，不存在该问题，因此可以打算由目前二层隧道组网方式，修改为三层隧道的组网方式。谢谢！