这个问题一开始的现象是部分station无法连接某台AP。无线抓包后发现station和AP间首先进行了正常的关联交互，即station发送probe req，ap回复probe rsp，再station发送Auth包ap回复Auth包，最后station发送assoc req包ap回复assoc rsp包。到这里乍一看一切正常，正常情况下station应该发送数据包进行正常的数据通信，但station再一次发送probe req，然后之前的流程又被进行一遍。就这样，不断重复连接过程，导致部分station无法正常连接，如下图：
分析可能是由于ap发送的assoc rsp有什么问题，导致station认为无法正常连接而进行重连操作。打开ap发送的assoc rsp详细内容果然发现不寻常之处：
这里的status code等于5，正常情况下应该为0，表示连接成功；
分析wlan驱动源码在ieee80211_mgmt_ap.c的函数ieee80211_setup_assocresp()中找到了status code组包的位置：
刚好在capinfo下面与抓包内容一致，status code的内容来自于ieee80211_setup_assocresp()的第四个变量reason。搜索执行ieee80211_setup_assocresp()的位置。最终我们在ieee80211_mlme_ap.c的ieee80211_mlme_recv_assoc_request()函数中找到了可疑位置，这里参数reason由assocstatus导入：
而变量assocstatus在前面有可能被设置为宏IEEE80211_REASON_ASSOC_TOOMANY，这个宏的值就是5
从字面上来看应该是ap资源不足导致的，具体原因待调查。。。