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

谢 谢！ 移动改变生活 移动改变生活 移动改变生活 THANK YOU 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拨号后，从用户ping sina，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字节的数