Patchwork [RFC,1/2] Support fixing the BSSID in IBSS mode.

login
register
mail settings
Submitter Nicolas Cavallari
Date Jan. 25, 2012, 5:52 p.m.
Message ID <1327513955-9992-1-git-send-email-cavallar@lri.fr>
Download mbox | patch
Permalink /patch/137809/
State Accepted
Commit 9e2af29f9bf065099b9a2abceaf40ac0e1bf86fa
Headers show

Comments

Nicolas Cavallari - Jan. 25, 2012, 5:52 p.m.
When the "bssid=" option is set for an IBSS network and ap_scan = 2,
ask the driver to fix this BSSID, if possible.

Previously, any "bssid=" option were ignored in IBSS mode when ap_scan=2.

Signed-hostap: Nicolas Cavallari <cavallar@lri.fr>
---

Whould like to know if it is the right approach, driver-wise and
configuration-wise.
I'm not aware of any program specifying a BSSID when creating an IBSS
network, except NetworkManager that does it only when the user
requests it.

 src/drivers/driver.h            |    7 +++++++
 wpa_supplicant/wpa_supplicant.c |    7 +++++++
 2 files changed, 14 insertions(+), 0 deletions(-)
Jouni Malinen - Jan. 28, 2012, 9:39 a.m.
On Wed, Jan 25, 2012 at 06:52:34PM +0100, Nicolas Cavallari wrote:
> When the "bssid=" option is set for an IBSS network and ap_scan = 2,
> ask the driver to fix this BSSID, if possible.
> 
> Previously, any "bssid=" option were ignored in IBSS mode when ap_scan=2.

Thanks, applied both patches.

> Whould like to know if it is the right approach, driver-wise and
> configuration-wise.
> I'm not aware of any program specifying a BSSID when creating an IBSS
> network, except NetworkManager that does it only when the user
> requests it.

Well, this is not really the way IBSS is supposed to work, but since
this type of hacks have been implemented in some drivers, we might as
well support them in wpa_supplicant.
Antonio Quartulli - Jan. 28, 2012, 11:19 a.m.
On Sat, Jan 28, 2012 at 11:39:13 +0200, Jouni Malinen wrote:
> On Wed, Jan 25, 2012 at 06:52:34PM +0100, Nicolas Cavallari wrote:
> > When the "bssid=" option is set for an IBSS network and ap_scan = 2,
> > ask the driver to fix this BSSID, if possible.
> > 
> > Previously, any "bssid=" option were ignored in IBSS mode when ap_scan=2.
> 
> Thanks, applied both patches.
> 
> > Whould like to know if it is the right approach, driver-wise and
> > configuration-wise.
> > I'm not aware of any program specifying a BSSID when creating an IBSS
> > network, except NetworkManager that does it only when the user
> > requests it.
> 
> Well, this is not really the way IBSS is supposed to work, but since
> this type of hacks have been implemented in some drivers, we might as
> well support them in wpa_supplicant.

Actually I'm curious about this behaviour...if we have another IBSS with
ESSID=x and BSSID=y1 and we start a new IBSS with ESSID=x (the same) and a fixed
BSSID=y2 then the two cells will not join each other...
At this point, what is another new client supposed to do (if it has not fixed
BSSID)? join the first one? the second one? this maybe an already mentioned and
solved problem but actually this is not totally clear to me...does the ieee standard 
'allow' such scenario?


Cheers,
Nicolas Cavallari - Jan. 28, 2012, 10:06 p.m.
On 28/01/2012 12:19, Antonio Quartulli wrote:
> On Sat, Jan 28, 2012 at 11:39:13 +0200, Jouni Malinen wrote:
>> On Wed, Jan 25, 2012 at 06:52:34PM +0100, Nicolas Cavallari wrote:
>>> When the "bssid=" option is set for an IBSS network and ap_scan = 2,
>>> ask the driver to fix this BSSID, if possible.
>>>
>>> Previously, any "bssid=" option were ignored in IBSS mode when ap_scan=2.
>> Thanks, applied both patches.
>>
>>> Whould like to know if it is the right approach, driver-wise and
>>> configuration-wise.
>>> I'm not aware of any program specifying a BSSID when creating an IBSS
>>> network, except NetworkManager that does it only when the user
>>> requests it.
>> Well, this is not really the way IBSS is supposed to work, but since
>> this type of hacks have been implemented in some drivers, we might as
>> well support them in wpa_supplicant.
> Actually I'm curious about this behaviour...if we have another IBSS with
> ESSID=x and BSSID=y1 and we start a new IBSS with ESSID=x (the same) and a fixed
> BSSID=y2 then the two cells will not join each other...
> At this point, what is another new client supposed to do (if it has not fixed
> BSSID)? join the first one? the second one? this maybe an already mentioned and
> solved problem but actually this is not totally clear to me...does the ieee standard 
> 'allow' such scenario?
This scenario is already possible without fixed BSSID : if the new
station is in the middle of two stations that can't see each other, it
will still have to choose the oldest. The not-choosen one will
eventually merge with the two (unless it has fixed bssid, or broken ibss
merge, the latter being more common).

Patch

diff --git a/src/drivers/driver.h b/src/drivers/driver.h
index d72c83b..d0cddd4 100644
--- a/src/drivers/driver.h
+++ b/src/drivers/driver.h
@@ -516,6 +516,13 @@  struct wpa_driver_associate_params {
 	 * STA mode: bits 0..3 UAPSD enabled for VO,VI,BK,BE
 	 */
 	int uapsd;
+
+	/**
+	 * fixed_bssid - Whether to force this BSSID in IBSS Mode.
+	 * 1 = Fix this BSSID and prevent merges.
+	 * 0 = Do not fix BSSID.
+	 */
+	int fixed_bssid;
 };
 
 enum hide_ssid {
diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index 68b80b9..47366e1 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -1364,6 +1364,13 @@  void wpa_supplicant_associate(struct wpa_supplicant *wpa_s,
 		params.ssid = ssid->ssid;
 		params.ssid_len = ssid->ssid_len;
 	}
+
+	if (ssid->mode == WPAS_MODE_IBSS && ssid->bssid_set
+	    && wpa_s->conf->ap_scan == 2) {
+		params.bssid = ssid->bssid;
+		params.fixed_bssid = 1;
+	}
+
 	if (ssid->mode == WPAS_MODE_IBSS && ssid->frequency > 0 &&
 	    params.freq == 0)
 		params.freq = ssid->frequency; /* Initial channel for IBSS */