当前位置： 首页 > news >正文

中国最大网站建设公司,网站空间和域名区别,宜昌微网站建设,网站开发分层参考 Android Network/WiFi 那些事儿 前言 本文将讨论几个有意思的网络问题#xff0c;同时介绍 Android 上常见WiFi 问题的分析思路。 网络基础Q A 一. 网络分层缘由 分层想必大家很熟悉#xff0c;是否想过为何需要这样分层#xff1f; 网上大多都是介绍每一层…参考 Android Network/WiFi 那些事儿 前言 本文将讨论几个有意思的网络问题同时介绍 Android 上常见WiFi 问题的分析思路。 网络基础Q A 一. 网络分层缘由 分层想必大家很熟悉是否想过为何需要这样分层 网上大多都是介绍每一层的职责似乎对为何要分层很少提及。 从软件设计模式的角度来看分层有点像MVC、MVP、MVVM 等Android 架构模式。 其本质是为了解耦职责更加明确修改的话只改一层即可不至于牵一发而动全身。 通过分层对外屏蔽其复杂性这样出问题的话容易定位到问题。 每一层的职责又是什么呢 传输层解决的是进程定位的问题、网络层解决数据包寻路的问题、数据链路层解决局域网传输的问题。 二. MAC 层扮演的角色 关于MAC 层扮演的角色你可能会说因为ip 会变mac 地址的话不过这似乎并没有解释清楚。 首先我们需要达成这样的一个共识 网络包在到达最终目的地之前是不知道目标mac 地址的这期间会经历无数次mac 层封装ip 层的过程比如某一次mac层包装ip层时这时候的mac层地址并不一定是最终的目标mac地址。 有可能是相连的一台路由器的mac地址解码之后看ip发现ip 不在这个局域网内然后再次包装一层mac 地址发给相连也有可能不是相连反正就是根据某种规则规定的下一个路由器路由器。 数据包上ip 地址的作用是在外网上投递用的内网就不行了必须要用mac使用mac 其中一个原因是为了在局域网内确认到那台正确的计算机。 信息传递时候需要知道的其实就是两个地址 • 终点地址Final destination address • 下一跳的地址Next hop address IP地址本质上是终点地址它在跳过路由器hop的时候不会改变而MAC 地址则是下一跳的地址每跳过一次路由器都会改变。 [引用1] 归纳下来一句话 MAC 作用是局域网内寻址IP 作用是网络寻址。 三. DHCP 从日志中看DHCP 的过程 (logcat driver) QDHCP Offer 和 DHCP ACK是广播包吗 A取决于client 端的ip 协议栈的能力如果协议栈在初始化过程中不接收单播IP报文请在DHCP Discovery/ Request报文的Flags里明确告知服务器设置BROADCAST flag 1服务器就用广播来和客户端通信。 Q是否存在static ip 和DHCP Server 分配给Client 的ip 冲突的情况 A其实在最后的确认阶段当Client收到DHCP Server发送的DHCP ACK 报文之后并不会马上使用Server 分配的这个地址而是会发送目的地址为Server 分配地址的ARP 请求报文作最后的确认即免费ARP。 如果没有检测到冲突则将此地址与自己绑定。如果检测到冲突就向DHCP Server发送DHCPDECLINE报文在Request IP Addressoption 50字段填入Server提供的发生冲突的IP地址.发送完成后等待一段时间再开始重新申请IP地址直至申请到一个可用的IP地址。 四. TCP 我们接下来讨论TCP 的几个疑问 为何TCP 是三次握手而挥手是四次 握手的作用是为了初始化双边的序列号这个是众所周知的事情。 问题是为何是三次握手 其实TCP 的3次握手是优化的结果它应该是4次握手由于是从零开始的建立连接因此将SYN的ACK及被动打开的SYN合并成一个SYN-ACK仅此而已。 为什么TCP的断链是4次挥手而不是3次 其实这个问题可以换个问法 为什么针对主动断开方的FIN的ACK以及本端的FIN不能合并 因为TCP 连接是全双工的握手阶段可以将ACK 和SYN 合并是因为此时没有数据上的连接所以可以放心的合并。 然而挥手阶段就不一样了假设Client 端数据传输完了认为此时可以断开而Server 端可能还有数据要传为了避免数据丢失或者损坏Server 端先发ACK然后等数据传输完成后再发送FIN 和ACK。 上面提到的无论是三次握手还是四次挥手其次数约定的核心是TCP 是全双工。 如果不理解这句话的话不妨多看几遍上面的握手和挥手流程。 为何说TCP 是 可靠 协议 TCP 发送端和接收端并不存在真实的类似网络专线的东西而是通过Client 和Server 各自维护一定数据结构(一种状态机)来记录和维护连接的状态。 TCP 作为这样一个抽象的协议跑在不可靠的IP 协议之上在一个不可靠的介质上传输其本质不可能是可靠的。 既然下层链路不可靠那么TCP 是如何实现所谓的可靠 基于丢包检测以及超时重传 如何判断丢包和解决丢包的问题 引入ACK 和 超时重传事实上远没这么简单复杂网络下还会涉及到滑动窗口、拥塞控制等概念受限篇幅我们后续会另起一篇文章讨论拥塞控制。 超时时间内没收到Ack 则重发可能是发的路上丢了也可能是Ack 丢了 图中绘制的是超时重传还有一个经常被提及的快速重传其本质也是超时重传只是一个优化而已。 Q快速重传时的优先级是怎样的 A

1. lost 数据段 IsLost (SeqNum): This routine returns whether the given sequence number is considered tobe lost. The routine returns truewheneither DupThresh discontiguous SACKed sequences have arrived above SeqNum or (DupThresh * SMSS) bytes with sequence numbers greater than SeqNum have been SACKed. Otherwise, the routine returns false. (摘自 RFC3517 A Conservative Selective Acknowledgment)
2. 新的尚未发送的数据段
3. 没有标记为LOST没有标记为SACKed没有重传过的数据段 Q每个 seq 都需要一个 ack 吗 A这其实涉及一个概念ACK 延迟确认 延迟确认可以让我们同时对多个接受的报文进行一次确认又称之为累积确认 这样接收方就不必对每个报文都进行确认接收到多个报文后如果延迟时间内没有报文到来就发送下一个期望接收报文的 ack。 好处显而易见就是节省带宽弊端也很明显那就是延迟带来的性能损失甚至会造成不必要的超时重传。 QRTO 依据RTT 计算出来准确吗 A某些场景下不准确会导致误判重传 “The Transmission Control Protocol (TCP) usesa retransmission timer to ensure data delivery inthe absence ofany feedback from the remote data receiver. The duration ofthis timer isreferred toasRTO (retransmission timeout).” 根据RTT 计算出RTO 在内核中是一个比较复杂的过程这里不展开讨论其细节有兴趣的话可以看下 RFC 6298 的 The Basic Algorithm。 除了真实的网络丢包导致的RTO 之外还有一种情况下的RTO 超时被称为虚假重传超时比如突发拥塞导致的RTT 极速拉升、路由链路变更导致新RTT 较高、RTT 波动较大的受干扰无线环境下等都可能会出现这种情况。 WiFi 常见问题 我们平时在实际项目上经常会遇到一些WiFi 相关的问题比如连接不上、异常掉线等问题。我们打算例举出WiFi 常见问题讨论其「一般分析思路」。
4. 连接问题 为何会出现连接失败 比较常见的原因 密码错误、Auth 失败、握手异常、DHCP 失败等。 一. 握手失败 1, 2 握手失败通常是由于密码错误 17:29:23.276148 [ cds_ol][ 0x10cb45409a9][ 14:28:23.026125]wlan: [6161:D:QDF] DPT: 0379:255 EAPOL: [0] [M1] SA: ec:41:18:08:df:9d  –DA:bc:7f:a4:35:0a:95 17:29:23.276159[ soft_i][ 0x10cb454559e][ 14:28:23.027139] wlan:[ 0:D:QDF] DPT:0381:255EAPOL:[ 0] [ M2] SA:bc:7f:a4:35:0a:95– DA: ec:41:18:08:df:9d //重复进行1,2握手间隔时间 1s 17:29:26.838232 [ cds_ol][ 0x10cb6a1b219][ 14:28:25.038825]wlan: [6161:D:QDF] DPT: 0384:255 EAPOL: [0] [M1] SA: ec:41:18:08:df:9d  –DA:bc:7f:a4:35:0a:95 17:29:26.838243[ soft_i][ 0x10cb6a1f966][ 14:28:25.039776] wlan:[ 0:D:QDF] DPT:0386:255EAPOL:[ 0] [ M2] SA:bc:7f:a4:35:0a:95– DA: ec:41:18:08:df:9d 17:29:27.038660 [ cds_ol][ 0x10cb8eb8450][ 14:28:27.038427]wlan: [6161:D:QDF] DPT: 0389:255 EAPOL: [0] [M1] SA: ec:41:18:08:df:9d  –DA:bc:7f:a4:35:0a:95 17:29:29.043572[ soft_i][ 0x10cb8eba31f][ 14:28:27.038839] wlan:[ 0:D:QDF] DPT:0391:255EAPOL:[ 0] [ M2] SA:bc:7f:a4:35:0a:95– DA: ec:41:18:08:df:9d //重复两次后失败 17:29:29.043606 [ kworke][ 0x10cbb354e58][ 14:28:29.037922]wlan: [15785:D:MGMT _TXRX] tgt_mgmt _txrx_rx _frame_handler: 1043: Rcvd mgmt frame subtype c0 (frame type 10) from ec:41:18:08:df:9d, seq _num 1049, rssi -17 tsf_delta: 0 密码错误可以从driver 日志中进一步证实 03-0618: 23: 06.58565010241024D wpa_supplicant: wlan0: State: 4WAY_HANDSHAKE - DISCONNECTED 03-0618: 23: 06.5861887491247D WifiHW : [ 1] getevent: IFNAMEwlan0  3WPA: 4-Way Handshake failed - pre- sharedkeymay be incorrect 03-0618: 23: 06.5861987491247D WifiHW : [ 2] getevent: IFNAMEwlan0 WPA: 4-Way Handshake failed - pre- sharedkeymay be incorrect 而3, 4 握手失败通常是路由设置问题 10:31:35.954886 [ cds_ol][ 22131061630][ 18:33:35.944171]wlan: [12981:I:QDF] qdf _dp_display _proto_pkt_always: 2093: DPT: 1145:255 EAPOL: [0] [M1] SA: 30:0d:9e:5a:83:6f  –DA:64:a2:00:77:4a:94 10:31:35.954914[ soft_i][ 22131098001][ 18:33:35.946066] wlan:[ 0:I:QDF] qdf_dp_display_proto_pkt_always:2093:DPT:1147:255EAPOL:[ 0] [ M2] SA:64:a2:00:77:4a:94– DA: 30:0d:9e:5a:83:6f 10:31:35.955028 [ cds_ol][ 22131150806][ 18:33:35.948815]wlan: [12981:I:QDF] qdf _dp_display _proto_pkt_always: 2093: DPT: 1150:255 EAPOL: [0] [M3] SA: 30:0d:9e:5a:83:6f  –DA:64:a2:00:77:4a:94 10:31:35.964895[ soft_i][ 22131186337][ 18:33:35.950667] wlan:[ 0:I:QDF] qdf_dp_display_proto_pkt_always:2093:DPT:1152:255EAPOL:[ 0] [ M4] SA:64:a2:00:77:4a:94– DA: 30:0d:9e:5a:83:6f //重复进行3,4握手间隔时间1s 10:31:36.948740 [ cds_ol][ 22150330716][ 18:33:36.947769]wlan: [12981:I:QDF] qdf _dp_display _proto_pkt_always: 2093: DPT: 1173:255 EAPOL: [0] [M3] SA: 30:0d:9e:5a:83:6f  –DA:64:a2:00:77:4a:94 10:31:36.954601[ soft_i][ 22150370206][ 18:33:36.949827] wlan:[ 0:I:QDF] qdf_dp_display_proto_pkt_always:2093:DPT:1175:255EAPOL:[ 0] [ M4] SA:64:a2:00:77:4a:94– DA: 30:0d:9e:5a:83:6f 10:31:37.964228 [ cds_ol][ 22169779798][ 18:33:37.960742]wlan: [12981:I:QDF] qdf _dp_display _proto_pkt_always: 2093: DPT: 1181:255 EAPOL: [0] [M3] SA: 30:0d:9e:5a:83:6f  –DA:64:a2:00:77:4a:94 10:31:37.964267[ soft_i][ 22169799422][ 18:33:37.961765] wlan:[ 0:I:QDF] qdf_dp_display_proto_pkt_always:2093:DPT:1183:255EAPOL:[ 0] [ M4] SA:64:a2:00:77:4a:94– DA: 30:0d:9e:5a:83:6f //重复两次后失败 10:31:38.948461 [ schedu][ 22188729766][ 18:33:38.947719]wlan: [12979:I:PE] Deauth RX: vdev 0 from 30:0d:9e:5a:83:6f for 64:a2:00:77:4a:94 RSSI -48 reason 15 mlm state 16, sme state 11 systemrole 3 二. DHCP 失败 //正常 IpClient.wlan0 StateMachine dump: 关键字onProvisioningSuccess 2021-02-07T09:29:31.941 - CMD_START wlan0/30 0 0 ProvisioningConfiguration{mEnableIPv4: true, mEnableIPv6: true, mEnablePreconnection: false 2021-02-07T09:29:32.033 - EVENT _PRE_DHCP _ACTION_COMPLETE wlan0/30 0 0 null [rcvd _inRunningState, proc_inRunningState] 2021-02-07T09:29:32.591 - INVOKE onProvisioningSuccess({{InterfaceName: wlan0 LinkAddresses: [ 192.168.31.⁴⁵⁄₂₄ ] DnsAddresses: [ /192.168.31.1 ] //异常 IpClient.wlan0 StateMachine dump: 关键字onProvisioningFailure 2021-02-07T12:24:32.069 - CMD_START wlan0/20 0 0 ProvisioningConfiguration{mEnableIPv4: true, mEnableIPv6: true, mEnablePreconnection: false 2021-02-07T12:24:32.095 - EVENT_PRE_DHCP_ACTION_COMPLETE wlan0/20 0 0 null [rcvd_inRunningState, proc_inRunningState] 2021-02-07T12:25:08.071 - INVOKE onProvisioningFailure({{InterfaceName: wlan0 LinkAddresses: [ fe80::63aa:c19f:9cf:²⁸⁶⁸⁄₆₄ ] DnsAddresses: [ ] Domains: null MTU: 0 TcpBufferSizes: 524288,1048576,8808040,262144,524288,6710886 Routes: [ fe80::/64 - :: wlan0 ]}}) //正常 DHCP client收到DHCP server分配的IP等信息 02-07 09:29:39.834 root 0 0 I [ soft_i][ 0x2d51ef84972][ 09:29:39.834889] wlan: [0:I:QDF] DHCP-D TX: SA:10:3f:44:af:8a:d4 DA:ff:ff:ff:ff:ff:ff msdu_id:861 status: succ 02-07 09:29:39.838 1073 2519 7028 D DhcpClient: Received packet: 10:3f:44:af:8a:d4 OFFER, ip /192.168.31.45, mask /255.255.255.0, DNS servers: /192.168.31.1 , gateways [/192.168.31.1] lease time 43200, domain null //异常 DHCP client没有收到DHCP server分配的IP等信息 [ 371.350648] [ soft_i][ 375560042590][ 12:24:32.098901] wlan: [0:I:QDF] DHCP-D TX: SA:e8:5a:8b:de:1f:43 DA:ff:ff:ff:ff:ff:ff msdu_id:1199 status: succ 分析 通常是由于信号弱导致因为DHCP 数据帧较大在信号弱时会出现交互失败的情形可以从日志中检查下rssi 值并在信号佳的位置对比测试。 三. Auth 失败 2021-05-12 10:22:43.578458 [ schedu][ 589237120609][ 22:22:43.577742]wlan: [26358:I:PE] Auth TX: success 2021-05-12 10:22:43.578514 [ schedu][ 589237125306][ 22:22:43.577987]wlan: [26358:I:PE] Auth RX: vdev 1 sys role 3 lim _state 7 from 54:75:95:e7:6f:61 rssi -63 auth_alg 0 seq 3976 //正常情况下code 是0这里的code 1表示路由拒绝认证需要进一步看路由拒绝原因 2021-05-12 10:22:43.578519 [ schedu][ 589237125762][ 22:22:43.578011]wlan: [26358:E:PE] lim _process_auth _frame_type2: 740: rx Auth frame from peer with failure code 1 54:75:95:e7:6f:61 2021-05-12 10:22:43.578524 [ schedu][ 589237126959][ 22:22:43.578073]wlan: [26358:E:PE] lim _process_mlm _auth_cnf: 543: Auth Failure occurred 分析 对应到driver 日志通常会打印出Auth frame from peer with failure其后跟的code 数值代表了本地失败的原因正常情况下是0这个值也可以通过sniffer 中auth帧的status值确定。 关于code 数值的含义可以查看 802.11 Association Status Codes 比如我们项目上之前还遇到过code 17这种情况 从表格中可以看出17表示被 AP 拒绝说明连接AP 的STA 太多已超出了AP 负载能力。
5. 掉线问题 为何会出现异常掉线 常见原因 framework 断开、Beacon miss、Kickout、Nud failed、Rx disassoc or deauth等 在介绍常见的掉线问题之前先回答这样一个问题 如何判断是上层断线还是底层断线 笔者经验而言
6. 如果是底层断线会先收到底层断线发上来的DISCONNECT Event然后supplicant才把state 切到 DISCONENCTED。
7. 如果是上层断线disconnection request会先到supplicantsupplicant state会先切到DISCONNECTED, 发送disconnect request 给driver 去真正断开wifi 连接。 从日志中判断的话一个简单的方法是搜关键字 wpa_supplicant: nl80211, wpa_supplicant: wlan0看打印关键日志的先后关系。 一. RSSI 信号差 搜索日志关键字 processedL2ConnectedState rec[ 902]: time 03-0316: 01: 25.327processedL2ConnectedState orgConnectedState dest null whatCMD_RSSI_POLL screen on560 //rssi 数值-52说明此时信号较好 stevenli_5G88:c3: 97: 32:c6:cc rssi -52f 5805sc 60link 720tx 0.1, 0.0, 0.0rx 1.5bcn 48014[ on: 2941tx: 831rx: 24period: 3009] fromscreen [ on: 79247period: 154965] score 60 分析 判断当前信号强弱我们通常是通过查看rssi 数值以及TX、RX数值来判断。 通常来讲RSSI 数值较好是介于-40~-60 之间-65 则认为信号较差。 二. Beacon 超时 首先需要先明白一点: Beacon 时间间隔是AP 设置的一般是100ms一个 和station 无关。 原理机制(MTK平台) 首先Hw 会判断如果连续10个Beacon 没有收到这时候会上报一个event 给 FwFw收到这个Interrupt 之后会重新设置 Linkdetect 的检查机制拉大检查监听Beacon 的 interrupt 为96Ms 如果接下来Hw 还是上报 Beacontimeout interrupt 。 这个时候Fw才真正上报 event 给 driver driver 收到这个Beacontimeout 之后会延迟5S做一个重连如果重连成功此次Beacontimeout 不处理认为是正常的。 如5S内还是重连不上上报给Fwk 做断线处理。 6  133.745238[ 827:main_thread][ wlan] [827]aisIndicationOfMediaStateToHost:(AIS INFO) Postpone the indication of Disconnect for 5 seconds 分析 通常是由于RSSI 信号差导致不过如果当时的网络环境比较差Noise 比较大也会导致Beacon 无法收到进而触发Beacontimeout。 三. ARP or DNS 异常 周期性检测DNS 状态过程中若发生fail会触发断线 //关键字 CMD_IP_REACHABILITY_LOST 或 NUD_FAILED rec[135]: time09-12 19:51:14.715 processedL2ConnectedStateorgConnectedState destnull what131221(0x20095)!CMD_IP_REACHABILITY_LOST rt210940/210940 FAILURE: LOST_PROVISIONING, NeighborEvent {elapsedMs210940, 192.168.1.1, [(null)], RTM_NEWNEIGH, NUD_FAILED} 或者搜索关键字 arp who-has 查看arp 是否有replydelay高不高。 四. Datastall 触发 原理机制 谷歌的一个在亮屏下一分钟检测一次网络状态的机制一旦判定异常则会通知给CS。 什么情况下会被判定是异常即发生了datastall呢
8. 过去一个poll 周期内丢包率达到了80% /**

• Default tcp packets fail rate to suspect as a data stall.
• Calculated by ((# of packets lost)(# of packets retrans))/(# of packets sent)*100. Ideally,
• the percentage should be 100%. However, the ongoing packets may not be considered as neither
• lost or retrans yet. It will cause the percentage lower. */ publicstaticfinal intDEFAULT_TCP_PACKETS_FAIL_PERCENTAGE  80;

1. 半小时内DNS 失败达到5次 // Default configuration values for data stall detection. publicstaticfinalintDEFAULT_CONSECUTIVE_DNS_TIMEOUT_THRESHOLD  5; publicstaticfinalintDEFAULT_DATA_STALL_VALID_DNS_TIME_THRESHOLD_MS  30* 60* 1000; driver日志中查看是否发生datastall类似日志如下 13:44:35.605317 [ kworker/u16:10][ 0x96c51f025d][ 13:44:35.602210]wlan: [6253:D:WMA] Received reason code 6 from FW 13:44:35.605322 [ kworker/u16:10][ 0x96c51f032a][ 13:44:35.602220]wlan: [6253:D:WMA] Data Stall event: 13:44:35.605389 [ kworker/u16:10][ 0x96c51f038a][ 13:44:35.602225]wlan: [6253:D:WMA] data _stall_type: 3 vdev _id_bitmap: 1 reason _code1: 0 reason_code2: 7 recovery_type: 0 13:44:35.605397 [ kworker/u16:10][ 0x96c51f11a3][ 13:44:35.602413]wlan: [6253:D:QDF] cds _set_log _completion: 2136: is_fatal 1 indicator 3 reason_code 6 recovery needed 0 13:44:35.629190 [ wlan_logging_th][ 0x96c51fc43e][ 13:44:35.604795]wlan: [900:D:HDD] send _flush_completion _to_user: Sending flush done to userspace reason code 6 五. TX/RX 收发包异常 除了看是否datastall我们还会查看TX/RX 数值变化以此来判断当前网络是否正常。 //异常RX的pkt cnt 涨幅很小正常情况下是持续增长 15:04:57.822610 [ wifico][ 0x183a3b70779][ 15:04:57.369087]wlan: [1372:D:HDD] wlan _hdd_get _sta_stats: [TX: Reporting MCS rate 8, flags 0x14 pkt cnt 267148, nss 2, bw 4]-[RX: Reporting MCS rate 8, flags 0x14 pkt cnt 450071, nss 2, bw 4] 15:05:00.379218 [ wifico][ 0x183a728afa9][ 15:05:00.378476]wlan: [1372:D:HDD] wlan _hdd_get _sta_stats: [TX: Reporting MCS rate 8, flags 0x14 pkt cnt 267148, nss 2, bw 4]-[RX: Reporting MCS rate 8, flags 0x14 pkt cnt 450073, nss 2, bw 4] 15:05:03.686570 [ wifico][ 0x183aa9a651c][ 15:05:03.388042]wlan: [1372:D:HDD] wlan _hdd_get _sta_stats: [TX: Reporting MCS rate 8, flags 0x14 pkt cnt 267148, nss 2, bw 4]-[RX: Reporting MCS rate 8, flags 0x14 pkt cnt 450074, nss 2, bw 4] 15:05:07.132915 [ wifico][ 0x183ae0eb713][ 15:05:06.406522]wlan: [1372:D:HDD] wlan _hdd_get _sta_stats: [TX: Reporting MCS rate 8, flags 0x14 pkt cnt 267148, nss 2, bw 4]-[RX: Reporting MCS rate 8, flags 0x14 pkt cnt 450075, nss 2, bw 4] 15:05:09.422157 [ wifico][ 0x183b18213a7][ 15:05:09.421730]wlan: [1372:D:HDD] wlan _hdd_get _sta_stats: [TX: Reporting MCS rate 8, flags 0x14 pkt cnt 267148, nss 2, bw 4]-[RX: Reporting MCS rate 8, flags 0x14 pkt cnt 450105, nss 2, bw 4] 15:05:13.535129 [ wifico][ 0x183b4f56b07][ 15:05:12.436868]wlan: [1372:D:HDD] wlan _hdd_get _sta_stats: [TX: Reporting MCS rate 8, flags 0x14 pkt cnt 267148, nss 2, bw 4]-[RX: Reporting MCS rate 8, flags 0x14 pkt cnt 450107, nss 2, bw 4] 分析 driver日志查看TX/RX 收发包是否正常不正常的话则通过Sniffer 进一步分析是路由没转发还是底层收了没往上传。 六 . AP 侧异常 09-06 10:48:56.919  3  1555.321037[ 3319:tx_thread][ wlan] Rx Deauth frame from BSSID[aa:63:df:5c:db:c5]. 09-06 10:48:56.919  3  1555.321093[ 3319:tx_thread][ wlan] Reason code 7 除了上面这种AP 侧主动发起的掉线外还有一些情况比如AP 侧更改了 security 2022 -02-1009 :31:32.0924 [ 3273.328514]2 (1) [4122:tx_thread] [wlan]rsnCheckSecurityModeChanged: ( RSNINFO) securitychange, WPA2- WEP 2022 -02-1009 :31:32.0924 [ 3273.328530]2 (1) [4122:tx_thread] [wlan]scanProcessBeaconAndProbeResp: ( SCNINFO) Beaconsecuritymodechangedetected 2022 -02-1009 :31:32.0924 [ 3273.328544]2 (1) [4122:tx_thread] [wlan]aisFsmStateAbort_NORMAL_TR: ( INITINFO) aisFsmStateAbort_NORMAL_TR 2022 -02-1009 :31:32.0924 [ 3273.328559]2 (1) [4122:tx_thread] [wlan]aisFsmDisconnect: ( INITINFO) aisFsmDisconnect
2. 漫游问题 触发Roaming 最常见的原因是low rssi除此之外还有一些原因 /* qcom* ROAM_TRIGGER_REASON_PER:

• Set if the roam has to be triggered based on a bad packet error rates (PER).

• ROAM_TRIGGER_REASON_BEACON_MISS:

• Set if the roam has to be triggered based on beacon misses from the connected AP.

• ROAM_TRIGGER_REASON_POOR_RSSI:

• Set if the roam has to be triggered due to poor RSSI of the connected AP.

• ROAM_TRIGGER_REASON_BETTER_RSSI:

• Set if the roam has to be triggered upon finding a BSSID with a better RSSI than the connected BSSID.

• Here the RSSI of the current BSSID need not be poor.

• ROAM_TRIGGER_REASON_PERIODIC:

• Set if the roam has to be triggered by triggering a periodic scan to find a better AP to roam.

• ROAM_TRIGGER_REASON_DENSE:

• Set if the roam has to be triggered when the connected channel environment is too noisy/congested.

• ROAM_TRIGGER_REASON_BTM:

• Set if the roam has to be triggered when BTM Request frame is received from the connected AP. //…..

• ROAM_TRIGGER_REASON_DEAUTH:

• Set if the roam has to be triggered when device receives Deauthentication/Disassociation frame from connected AP.

• ROAM_TRIGGER_REASON_IDLE:

• Set if the roam has to be triggered when the device is in idle state (no TX/RX) and suspend mode, if the current RSSI is determined to be a poor one.

• ROAM_TRIGGER_REASON_TX_FAILURES:

• Set if the roam has to be triggered based on continuous TX Data frame failures to the connected AP.

• ROAM_TRIGGER_REASON_EXTERNAL_SCAN:

• Set if the roam has to be triggered based on the scan results obtained from an external scan (not triggered to aim roaming). 以其中比较常见的一种ROAM_TRIGGER_REASON_BEACON_MISS 为例(qcom)

  Set beacon missed count threshold

  if beacon missed counter gRoamBmissFirstBcntgRoamBmissFinalBcnt,

  heartbeat error triggered

  gRoamBmissFirstBcnt 10 gRoamBmissFinalBcnt 20 当某一次的beacon miss 次数超过gRoamBmissFirstBcntgRoamBmissFinalBcnt之和则触发漫游寻找合适的目标漫游热点如果找不到候选者则会断开网络。 //first_bmiss_detected1 10个beacon miss 11:39:49.810713 R0: FWMSG: [2dd0beecbe] SWBMISS_TIMER_FN: vdev_id0, curr_bmiss_bcnt26, pre_bmiss_detected1, first_bmiss_detected1, final_bmiss_detected0, b_timeout1, cons_bmiss_count 61 11:39:49.834534 R0: FWMSG: [2dd0dcd3ef] SWBMISS_TIMER_FN: vdev_id0, curr_bmiss_bcnt27, pre_bmiss_detected1, first_bmiss_detected1, final_bmiss_detected0, b_timeout1, cons_bmiss_count 62 11:39:49.835649 R0: FWMSG: [2dd0fb07a0] SWBMISS_TIMER_FN: vdev_id0, curr_bmiss_bcnt28, pre_bmiss_detected1, first_bmiss_detected1, final_bmiss_detected0, b_timeout1, cons_bmiss_count 63 11:39:49.837121 R0: FWMSG: [2dd118f087] SWBMISS_TIMER_FN: vdev_id0, curr_bmiss_bcnt29, pre_bmiss_detected1, first_bmiss_detected1, final_bmiss_detected0, b_timeout1, cons_bmiss_count 64 //final_bmiss_detected1 在前面丢了10个beacon 的基础上又丢了20个beacon 11:39:49.837648 R0: FWMSG: [2dd11ed6b0] SWBMISS_NULL_SEND_CMPLT: vdev_id0, isQosNullSuccess0, isFinalBmiss1, first_bmiss_detected1, final_bmiss_detected1, fbmiss_evnt_posted0, vbmiss-connected 1, cons_bmiss_count 65 11:39:49.838136 R0: FWMSG: [2dd11eda17] VDEV_MGR_FINAL_BMISS_DETECTED: vdev_id 0 11:39:49.838657 R0: FWMSG: [2dd11ee1b0] ROAM_FINAL_BMISS_RECVD curr_rssi_avg -68 dBm bcn_rssi_last -68 dBm roam_scan_state(IDLE 0/ACTIVE_SCAN 1/ACTIVE_ROAM 2) 0 scan_param.mode(5-7)/fina_scan(0-4) 0x62 scan_status(bit3)/candidate_found(bit2)/send_beacon_to_host(bit1)/final_bmiss_recvd(bit0) 0x06 is_qnull_fbmiss 0 //触发漫游前的扫描 11:39:49.838724 R0: FWMSG: [2dd11ee4d5] ROAM_SCAN_REQUESTED send_beacon_to_host 1 scan_type(FULL 0/CHANLIST 1/CHANMAP 2/FORCED 3/5G_ONLY 4) 2 roam_scan_state (IDLE 0/ACTIVE_SCAN 1/ACTIVE_ROAM 2) 0 final_scan 1 num_chan 13 11:39:49.838738 R0: FWMSG: [2dd11ee532] ROAM_FINAL_BMISS_SCAN scan_policy0xf,skip_dfs0,active_dwell55 birst_dur900 小结 至此我们讨论了网络上几个有趣的问题同时讨论了Android 平台上常见的WiFi 问题分析思路。本文由于受限于篇幅加之笔者水平限制相信会存在不足的地方希望本文能够起到抛砖引玉的作用。 参考文献 https: //blog.csdn.net/shuyan1115/article/details/102476599 https: //juejin.cn/post/6844903986189844493 https: //blog.csdn.net/dog250/article/details/52548345