Bugzilla – Bug 1584
Old Association Request Timeouts are not canceled
Last modified: 2013-08-19 18:01:51 EDT
In StaWifiMac::SendAssociationRequest(...) We create an Association Request Timeout: m_assocRequestEvent = Simulator::Schedule (m_assocRequestTimeout, &StaWifiMac::AssocRequestTimeout, this); But before that we are not cancelling any existing one. We should do this: if (m_assocRequestEvent.IsRunning ()) { m_assocRequestEvent.Cancel (); } This problem was happening to me in a weird time coincidence where an old AssocRequestTimeout was arriving between a new AssociationRequest and its completion: - Sta sends association request 1 and schedules AssocReqTimeout1 - Sta1 looses connection. - Sta1 sends association request 2 and schedules AssocReqTimeout2 - Sta1 receives notification caused by AssocReqTimeout1 and my code would assume that association request 2 failed - Sta1 gets notification that association request 2 was completed. This bug goes all the way back to ns-3.2 (at least).
Can you attach a code that produces this problem?
Hi Daniel, This problem is hard to reproduce as it requires a number of different events to occur in a very specific order. The problem was manifesting itself in my PhD simulation model. It's a very specific network scenario, with lots of code. I want to help, but right now I don't have time to do the amount of work required to strip it down to a simple scenario where the problem manifests itself. That being said, I think the problem can be quite easily confirmed just by going through the code considering the example I provided. As I said, I believe this fix is perfect: if (m_assocRequestEvent.IsRunning ()) { m_assocRequestEvent.Cancel (); } It worked for me :-) P.S: not sure if the there's a similar problem with the Active Probing timer... Best, Pedro
Hi Pedro, Can you remember what happens at the step 2 of your scenario (i.e. Sta1 looses connection)? Your proposed fix will definitely work. But I'm just curious how that scenario could happen since it may be an indication of other problems. From the flow of the code, it looks like that scenario is not possible (but obviously it happened with your code). If you can recall what triggered the "Sta1 looses connection", please let me know. I just want to make sure that there is no other problem that is more serious with the flow of the sta. Thanks
Hi, Sorry for taking so much time to answer. Basically Sta1 looses the connection because it is moving. Therefore, the first AP is no longer reachable. It then tries to connect to AP2 (association request 2) which will succeed, but due to the described issue, the STA is no longer expecting the Association Complete message. Best, Pedro
Created attachment 1663 [details] Patch The bug is still in the current release. The patch fixes it and fixes also the other events not being canceled upon rescheduling. Concerning the other ones, I'm not sure they could lead to a bug. However it's a good practice to not scheudule an event for a timeout handling without being ssure that the previous one is canceled.
committed: changeset 831ad8abd1c0
Created attachment 1664 [details] fixed typo in 831ad8abd1c0
(In reply to comment #6) > committed: changeset 831ad8abd1c0 Looks like, the changeset contains a copy-paste error, so the attachment 1664 [details] is also required.
Thanks Andrey changeset: 10179:8dc92cb1e737
(In reply to comment #9) > Thanks Andrey > > changeset: 10179:8dc92cb1e737 Thank you for applying!