手机终端Android4.0用户认证失败分析报告.docx

手机终端Android4.0认证失败分析报告1 问题描述现场版本: V1.2.1故障主题: 使用android4.0系统进行WLAN业务上网时，无法通过认证故障详细描述: android4.0系统的手机在中兴WLAN的热点下，进行WEB进行认证时，无法认证成功，而在其他厂家的热点下，可以正常认证。2 故障分析通过现场在安卓手机和AC下行的抓包分析，发现认证不通过的原因是AC给用户发送的302重定向报文长度异常，即丢失了后半部分的内容，导致用户无法通过认证。进一步分析发现，在用户和AC建立TCP连接的3次握手中，终端和AC协商使用了window size的扩展属性Window scale，最终由于该属性AC实际不支持，导致了故障发生，具体分析如下：window size在TCP中占两个字节，正常情况最大为65535Byte。同时，RFC 1323中定义了Window scale option字段（取值范围为0-14，通过window size的大小左移Window scale的值计算实际的window size），使最大的window size增加到1Gbyte（21614 = 230）。window scale可选项只在TCP3次握手期间使用，并且需要两端均在syn报文中添加此属性才可生效。终端和AC建立TCP连接的三次握手时的window size协商流程：I9308 android 4.0手机系统sta 的syn报文，window size大小为0x3908 = 14600，同时在syn报文中携带window scale(值为64)；AC响应的syn ack报文，window size大小为8192，同时在syn报文中携带window scale(值为0),通知对端AC也支持window scale属性。STA响应的ack报文，window size大小为229，由于在AC在syn-ack报文中携带过window scale option，此时ACK报文的实际window size应该为229 * 26= 14656。而AC在收包时并未进行该可选属性的处理，直接按照ACK报文中的window size（229）来处理，由于302重定向报文（大约700字节）的大于229，所以报文长度只被限制在229，造成故障。如上图，Content-Type:text/html后的部分丢失，正常情况下，还应该有javascript部分代码。I9228 android 2.3手机系统sta 的syn报文，window size大小为0x16D0 = 5840，同时在syn报文中携带window scale(值为2)；AC响应的syn ack报文，window size大小为8192，同时在syn报文中携带window scale(值为0),通知对端AC也支持window scale属性STA响应的ack报文，window size大小为1460，由于在AC在syn-ack报文中携带过window scale option，此时ACK报文的实际window size应该为1460*22 =5840。AC直接按照ACK报文中的window size（1460）来处理，由于302重定向报文的小于1460，所以此时报文长度正常，也就android2.3手机可正常认证的原因。假设重定向报文大小为600字节，那么当2x 5840/600时，也就是syn报文中的window scale大于4时，那么也会造成重定向报文分片。I9308 android 4.0系统内核升级后STA的syn报文，Option字段中的携带window scale属性，且值为1AC对终端的SYN/ACK报文中，option字段也携带window scale属性，且值为0，并且声明自己的window size为8192TCP握手的最后一步终端回给AC的ACK中，根据a)中协商的scale为1的情况，告知AC自己的window size为7300，实际是7300×21=14600。由于AC只能解析7300这个系数，并不能正确解析为14600，但由于7300本身足够大，比重定向报文的700多字节要大很多，所以AC发给用户的重定向报文长度正常，后半部分不会丢失。认证可以通过上图可以看出，Content-Type: text/html后部分没有丢失，这样的重定向报文才可以被手机解析并进行从定向推送Portal操作。3原因分析：1、AC不支持window size scales属性，但是和终端协商时却声明支持该属性，造成终端使用该属性而AC不识别scales，只能识别其系数当作window size的值。2、由于安卓4.0版本较2.3版本，在TCP协议栈在建立TCP握手时，其scales值