Bugzilla – Bug 396
Weird WiFi error state with STA slowing approaching the wifi range of an AP
Last modified: 2013-06-28 07:40:30 EDT
I have been experiencing strange wifi problems related to mobility. In my test case, a STA initially starts in a distance such that communication with an AP almost-but-not-quite works. At this distance (31 meters, with tweaked Rx/Tx gains of -10dB) the STA can hear AP beacons and is able to associate, but the AP is not able to correctly receive the packets sent by the STA. However, after a few seconds I move the STA to well within wifi range of the AP, but still the AP is not able to receive the packets. Some weird error state has been entered while the STA was at a distance of 31 meters and the WiFi MAC will never again be able to recover from it until it leaves wifi range and enters again. However, if the STA initially starts at 30 meters distance from the AP, then it communicates and keeps communicating.
Created attachment 283 [details] test script If you run this script, initially with BUG=True, a STA will be created at d=31, and after a few seconds it will move to d=10. With BUG=False, the STA will be created at d=30, and after a few seconds it will move to d=10. With BUG=False, the NqapWifiMac logs look something like this in the final seconds of simulation: 98000000000ns NqapWifiMac:SendOneBeacon(0x899640) 98000375066ns NqapWifiMac:Receive(0x899640, 0x8a8be0, 0x7fff86237020) 98000375066ns NqapWifiMac:Receive(): forwarding frame from=d0:00:00:00:00:02, to=ff:ff:ff:ff:ff:ff 98000375066ns NqapWifiMac:ForwardDown(0x899640, 0x8a8be0, d0:00:00:00:00:02, ff:ff:ff:ff:ff:ff) 98000375066ns NqapWifiMac:ForwardUp(0x899640, 0x8a9fe0, d0:00:00:00:00:02) 98100000000ns NqapWifiMac:SendOneBeacon(0x899640) With BUG=True, instead they look like this: 98000000000ns NqapWifiMac:SendOneBeacon(0x899640) 98000393066ns NqapWifiMac:Receive(0x899640, 0x8aa920, 0x7fff52d2bb20) 98100000000ns NqapWifiMac:SendOneBeacon(0x899640)
One more note: in this weird state, the STA can receive everything sent by the AP, but the AP does not receive packets sent by the STA. So I suspect the error is in the state machine of the AP, not in the STA.
Created attachment 284 [details] improve wifi logging This patch improves logging in wifi header and NqapWifiMac. With it I see: 99000423066ns NqapWifiMac:Receive(0x899650, ns3::LlcSnapHeader (type 0x112) Payload (size=64), DATA ToDS=1, FromDS=0, MoreFrag=0, Retry=1, MoreData=0 Duration/ID=60us DA=ff:ff:ff:ff:ff:ff, SA=d0:00:00:00:00:02, BSSID=d0:00:00:00:00:01, FragNumber=0, SeqNumber=99) 99000423066ns NqapWifiMac:Receive(): data from a station that is not associated So it seems the problem is that the STA thinks is associated, but the AP thinks it is not.
And here's how the association problem happens. In the no-bug scenario, this happens: 100100100ns NqstaWifiMac:SendAssociationRequest(0x8a8490, d0:00:00:00:00:01) 102568200ns NqapWifiMac:Receive(0x899650, ns3::MgtAssocRequestHeader (ssid=test, rates=[6000000mbs 9000000mbs 12000000mbs 18000000mbs 24000000mbs 36000000mbs 48000000mbs 54000000mbs]), MGT_ASSOCIATION_REQUEST ToDS=0, FromDS=0, MoreFrag=0, Retry=1, MoreData=0 Duration/ID=60us, DA=d0:00:00:00:00:01, SA=d0:00:00:00:00:02, BSSID=d0:00:00:00:00:01, FragNumber=0, SeqNumber=0) 102568200ns NqapWifiMac:SendAssocResp(0x899650, d0:00:00:00:00:02, 1) 102746300ns NqstaWifiMac:Receive(0x8a8490, 0x8aae40, 0x7fff3d5022e0) 102746300ns NqstaWifiMac:Receive(): assoc completed 102806400ns NqapWifiMac:TxOk(0x899650) 102806400ns NqapWifiMac:TxOk(): associated with sta=d0:00:00:00:00:02 In the bug scenario, it is different: 300100103ns NqstaWifiMac:SendAssociationRequest(0x8a8490, d0:00:00:00:00:01) 307387206ns NqapWifiMac:Receive(0x899650, ns3::MgtAssocRequestHeader (ssid=test, rates=[6000000mbs 9000000mbs 12000000mbs 18000000mbs 24000000mbs 36000000mbs 48000000mbs 54000000mbs]), MGT_ASSOCIATION_REQUEST ToDS=0, FromDS=0, MoreFrag=0, Retry=1, MoreData=0 Duration/ID=60us, DA=d0:00:00:00:00:01, SA=d0:00:00:00:00:02, BSSID=d0:00:00:00:00:01, FragNumber=0, SeqNumber=0) 307387206ns NqapWifiMac:SendAssocResp(0x899650, d0:00:00:00:00:02, 1) 307565309ns NqstaWifiMac:Receive(0x8a8490, 0x8aa120, 0x7fff7ffaad90) 307565309ns NqstaWifiMac:Receive(): assoc completed 307640872ns NqapWifiMac:TxFailed(0x899650) 307640872ns NqapWifiMac:TxFailed(): assoc failed with sta=d0:00:00:00:00:02 It sounds like the STA receives the AssocResp, but the AP never receives the ACK of the AssocResp that it sent, so it assumes that association failed. With the MacLow logging this is confirmed: 307565309ns NqstaWifiMac:Receive(): assoc completed 307581309ns MacLow:SendAckAfterData(0x8a8620) 307581309ns MacLow:ForwardDown(0x8a8620, 0x8aada0, 0x7fffde836c30, wifia-6mbs) 307581309ns MacLow:ForwardDown(): d0:00:00:00:00:02 send CTL_ACK, to=d0:00:00:00:00:01, size=14, mode=wifia-6mbs, duration=0ns, seq=0x0 307625412ns MacLow:ReceiveError(0x899800, 0x8aaf90, 0.71913) 307625412ns MacLow:ReceiveError(): d0:00:00:00:00:01 rx failed 307640872ns MacLow:NormalAckTimeout(0x899800) 307640872ns MacLow:NormalAckTimeout(): d0:00:00:00:00:01 normal ack timeout 307640872ns NqapWifiMac:TxFailed(0x899650) 307640872ns NqapWifiMac:TxFailed(): assoc failed with sta=d0:00:00:00:00:02 The problem here is that the STA from then on assumes to be associated, and doesn't try to associate again, but the AP assumes the STA is not associated and silently drops frames from that STA. I have no idea how to fix this, my knowledge of 802.11 state machines is not so detailed :P
(In reply to comment #4) > It sounds like the STA receives the AssocResp, but the AP never receives the > ACK of the AssocResp that it sent, so it assumes that association failed. > The problem here is that the STA from then on assumes to be associated, and > doesn't try to associate again, but the AP assumes the STA is not associated > and silently drops frames from that STA. I agree with this analysis but I don't really see how to fix this. i.e., I see nothing in the 802.11 standard which allows you to deal with this problem and detect that we have a STA which believes that it is associated while it is not.
changeset 4ac29a986eef
Then, what is the solution for this problem? It would be possible associate both nodes manually or permit the associaton without the ACKs??