[PATCH mac80211] cfg80211: fix channel configuration in IBSS join

[Antonio Quartulli]

On 28/01/14 11:41, Arend van Spriel wrote:
> On 01/28/2014 10:54 AM, Antonio Quartulli wrote:
>> With the current approach if another cell having the same
>> BSSID (but using a different channel) exists then cfg80211
>> picks up the wrong BSS object.
> 
> Not entirely sure this patch is right. How can you have another IBSS
> cell with the same BSSID. That sounds dead wrong to me. Here is what
> IEEE802.11-2012 has to say about the BSSID:

On IBSS join you can manually specify the frequency and the BSSID to use.
It is common to use a fixed BSSID when setting up a mesh network: this
will avoid troubles given by merge and split operations..

> 
> "If the BSSType indicates an IBSS, the STA shall start an IBSS, and the
> BSSID shall be an individual locally administered IEEE MAC address as
> defined in 9.2 of IEEE Std 802-2001. The remaining 46 bits of that MAC
> address shall be a number selected in a manner that minimizes the
> probability of STAs generating the same number, even when those STAs are
> subjected to the same initial conditions.""
> 
>> The result is a mismatching channel configuration between
>> cfg80211 and the driver, that can lead to any sort of
>> problem.
>>
>> The issue can be triggered by having an IBSS sitting on
>> given channel and then asking the driver to create a new
>> cell using the same BSSID but with a different frequency.
> 
> So you have a single driver/device in which you setup two IBSS cells and
> it allows you/user-space to use the same BSSID. That is strange.
> 

With mac80211 you can force a given frequency and then it's easy to end
up in this situation.

e.g.:
Node A creates an IBSS on channel X, node B joins the IBSS, node B
leaves, node B tries to create an IBSS on channel Y (it can because we
can force a given frequency) and we end up in the problem I am trying to
fix with this patch.

This is a not so strange use case. Imagine you have a mesh network and
you want to switch to a new channel: you will pass through the scenario
I described.


I can agree that this is not "fully standard compliant"...but it does
not hurt and this is why we have this "fixed-freq" attribute.


Cheers,

-- 
Antonio Quartulli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20140128/352c3890/attachment.sig>