已初步确定是螃蟹的AP模式逻辑问题,并非死锁。
测试环境
1.rtl8723ds (AP) <-----> iphone (STA)
触发条件
1.作为AP模式
2.正在发送数据
3.对方STA进入SLEEP模式,有概率触发该bug。
问题描述
1.hal\rtl8723d\sdio\rtl8723ds_xmit.c 中 xmit_xmitframes 函数
#ifdef CONFIG_AP_MODE
if (MLME_IS_AP(padapter) || MLME_IS_MESH(padapter)) {
if ((pxmitframe->attrib.psta->state & WIFI_SLEEP_STATE) &&
(pxmitframe->attrib.triggered == 0)) {
RTW_INFO("%s: one not triggered pkt in queue when this STA sleep, break and goto next sta\n", func);
break;
}
}
#endif
这段代码意图其实是符合 80211 中的传统省电模式 (Legacy Power Save)
传统省电模式 (Legacy Power Save)
假设某个时间STA进入sleep,它通过发送数据帧或null-date帧来告诉AP我进入省电了
AP收到这个帧后就不发数据帧给处于省电模式下的STA了。
STA会在下一个 DITM period wake up,并收到AP的beacon
在beacon 中DTIM 信息元素会告诉 STA,你sleep的时候有发你的数据,我替你存下了,快来取
但实际工作的时候不知道为什么驱动会反复的触发发送信号量,然后反复的进入这个流程,导致 RTWHALXT 线程占满CPU。
而且影响到了正常的收发逻辑。
暂时解决方案
注释掉上述 break; 语句,逻辑变更为,即使 STA 进入休眠仍然发送,STA收不到就收不到,该帧就算丢弃了。
实验发现也并没有造成多大的通讯延迟影响。
后续解决方案
联系模块fae尝试解决。但我不认为模块fae方面有能力解决这个问题。(我是普通用户不是VIP)