Bug 1584

Summary: Old Association Request Timeouts are not canceled
Product: ns-3 Reporter: Pedro Fortuna <pedro.fortuna>
Component: wifiAssignee: Nicola Baldo <nicola>
Severity: minor CC: ahippo, nikkipui, ns-bugs, pedro.fortuna, ruben, tomh, tommaso.pecorella
Priority: P5    
Version: ns-3-dev   
Hardware: PC   
OS: Linux   
Attachments: Patch
fixed typo in 831ad8abd1c0

Description Pedro Fortuna 2013-02-10 20:43:21 EST
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).
Comment 1 Daniel L. 2013-02-13 16:26:16 EST
Can you attach a code that produces this problem?
Comment 2 Pedro Fortuna 2013-02-13 17:38:26 EST
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...

Comment 3 Daniel L. 2013-04-29 08:44:56 EDT
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.

Comment 4 Pedro Fortuna 2013-08-16 10:09:37 EDT

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.

Comment 5 Tommaso Pecorella 2013-08-17 16:53:18 EDT
Created attachment 1663 [details]

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.
Comment 6 Tom Henderson 2013-08-19 02:33:40 EDT
committed:  changeset 831ad8abd1c0
Comment 7 Andrey Mazo 2013-08-19 09:57:21 EDT
Created attachment 1664 [details]
fixed typo in 831ad8abd1c0
Comment 8 Andrey Mazo 2013-08-19 09:58:40 EDT
(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.
Comment 9 Tommaso Pecorella 2013-08-19 12:31:38 EDT
Thanks Andrey

changeset:   10179:8dc92cb1e737
Comment 10 Andrey Mazo 2013-08-19 18:01:51 EDT
(In reply to comment #9)
> Thanks Andrey
> changeset:   10179:8dc92cb1e737

Thank you for applying!