Potential IBSS race

Potential IBSS race

[James Prestwood]

Hi,

It appears that when two IBSS networks are started at the same time
they sometimes don't pick each other up and two separate IBSS networks
are created. I have turned on IBSS logging and see beacons coming in
from both networks AFTER each interface creates its own IBSS, but they
dont come soon enough for either interface to realize there is already
an IBSS. Is there any mitigation in the kernel or anything outlined in
802.11 that handles this case of two IBSS networks being created
simultaneously (or close to it)? Even delaying the second network by a
full second sometimes results in this behavior.

[    3.915143] wlan1: sta_find_ibss (active_ibss=0)
[    3.916022] wlan1: sta_find_ibss: did not try to join ibss
[    3.960484] wlan0: sta_find_ibss (active_ibss=0)
[    3.961643] wlan0: sta_find_ibss: did not try to join ibss
[    5.798696] wlan1: sta_find_ibss (active_ibss=0)
[    5.800526] wlan1: sta_find_ibss: did not try to join ibss
[    5.802579] wlan0: sta_find_ibss (active_ibss=0)
[    5.804300] wlan0: sta_find_ibss: did not try to join ibss
[    7.782708] wlan0: sta_find_ibss (active_ibss=0)
[    7.784529] wlan0: sta_find_ibss: did not try to join ibss
[    7.786557] wlan0: Trigger new scan to find an IBSS to join
[    7.788525] wlan1: sta_find_ibss (active_ibss=0)
[    7.789132] wlan1: sta_find_ibss: did not try to join ibss
[    7.789779] wlan1: Trigger new scan to find an IBSS to join
[    8.471675] wlan1: sta_find_ibss (active_ibss=0)
[    8.473610] wlan1: sta_find_ibss: did not try to join ibss
[    8.475957] wlan0: sta_find_ibss (active_ibss=0)
[    8.477434] wlan0: sta_find_ibss: did not try to join ibss
[   10.790703] wlan0: sta_find_ibss (active_ibss=0)
[   10.792698] wlan0: sta_find_ibss: did not try to join ibss
[   10.795035] wlan0: Trigger new scan to find an IBSS to join
[   10.796543] wlan1: sta_find_ibss (active_ibss=0)
[   10.797125] wlan1: sta_find_ibss: did not try to join ibss
[   10.797988] wlan1: Trigger new scan to find an IBSS to join
[   11.480676] wlan1: sta_find_ibss (active_ibss=0)
[   11.482586] wlan1: sta_find_ibss: did not try to join ibss
[   11.484822] wlan1: Creating new IBSS network, BSSID 62:f3:4f:db:22:e8
[   11.486643] wlan0: sta_find_ibss (active_ibss=0)
[   11.487302] wlan0: sta_find_ibss: did not try to join ibss
[   11.487995] wlan0: Creating new IBSS network, BSSID da:4d:66:a0:ca:52
[   11.590664] wlan1: RX beacon SA=02:00:00:00:00:00
BSSID=da:4d:66:a0:ca:52 TSF=0x5a4fc850a65c2
[   11.592753] wlan1: BCN=0x5a4fc850a6133 diff=1167 @4294678818
[   11.594002] wlan0: RX beacon SA=02:00:00:00:01:00
BSSID=62:f3:4f:db:22:e8 TSF=0x5a4fc850a72cd
[   11.595688] wlan0: BCN=0x5a4fc850a614a diff=4483 @4294678821

(beacons continue for a while until the test fails)

Thanks,
James

Re: Potential IBSS race

[Johannes Berg]

On Wed, 2020-05-06 at 08:44 -0700, James Prestwood wrote:
> Hi,
> 
> It appears that when two IBSS networks are started at the same time
> they sometimes don't pick each other up and two separate IBSS networks
> are created. I have turned on IBSS logging and see beacons coming in
> from both networks AFTER each interface creates its own IBSS, but they
> dont come soon enough for either interface to realize there is already
> an IBSS.

I guess that makes some sense. Perhaps the number of scans should be
random, but then of course if they land on the same value, it'll still
happen.

> Is there any mitigation in the kernel or anything outlined in
> 802.11 that handles this case of two IBSS networks being created
> simultaneously (or close to it)? 

If neither of them has any other stations, then it should go into the
merge timer every 30 seconds. But if they're identical, then maybe even
that doesn't work since they'll go scanning at the same time, and again
fail?

Maybe that's a better approach - make the merge timer be randomized
between 30 and 60 seconds or so, so that they can eventually merge.

> Even delaying the second network by a
> full second sometimes results in this behavior.

A second isn't really sufficient I guess, because a full scan will take
5 seconds or so. That's the minimum you'd have to delay, I think. At
least if you're creating the network on a channel that's scanned early
in the scan (i.e. a 2.4 GHz channel).

johannes

Re: Potential IBSS race

[James Prestwood]

Hi Johannes,

> 
> Maybe that's a better approach - make the merge timer be randomized
> between 30 and 60 seconds or so, so that they can eventually merge.
> 

That sounds good, unfortunately it doesn't really help with our test
environment since we don't want to wait around for that long... But
yeah due to how long scanning takes, maybe thats just the way it is. In
a real world situation this is probably fine.

Thanks,
James

Re: Potential IBSS race

[Johannes Berg]

On Wed, 2020-05-27 at 16:06 -0700, James Prestwood wrote:

> > Maybe that's a better approach - make the merge timer be randomized
> > between 30 and 60 seconds or so, so that they can eventually merge.
> > 
> 
> That sounds good, unfortunately it doesn't really help with our test
> environment since we don't want to wait around for that long... But
> yeah due to how long scanning takes, maybe thats just the way it is.

If you can come up with a better solution, I'm all ears :)

But if your main concern is about the wait in testing, then I suggest
you go to ARCH=um and time-travel=infcpu testing like wpa_supplicant has
done, that was something like a 6x (!) testing speed increase for me.

Since it's all software/hwsim that shouldn't be too difficult.

johannes

Re: Potential IBSS race

[James Prestwood]

On Thu, 2020-05-28 at 08:56 +0200, Johannes Berg wrote:
> On Wed, 2020-05-27 at 16:06 -0700, James Prestwood wrote:
> 
> > > Maybe that's a better approach - make the merge timer be
> > > randomized
> > > between 30 and 60 seconds or so, so that they can eventually
> > > merge.
> > > 
> > 
> > That sounds good, unfortunately it doesn't really help with our
> > test
> > environment since we don't want to wait around for that long... But
> > yeah due to how long scanning takes, maybe thats just the way it
> > is.
> 
> If you can come up with a better solution, I'm all ears :)
> 
> But if your main concern is about the wait in testing, then I suggest
> you go to ARCH=um and time-travel=infcpu testing like wpa_supplicant
> has
> done, that was something like a 6x (!) testing speed increase for me.

Hmm, I'll play around with this. Sounds promising.

Thanks
> 
> Since it's all software/hwsim that shouldn't be too difficult.
> 
> johannes
>