Re: Problem with BSSID selection



On Sun, 2010-09-26 at 13:55 +0200, Pietro Battiston wrote:
> I think an extract of my syslog is the best explanation of my problem:
> 
> Sep 26 12:50:47 voubian NetworkManager[1417]: <info> Activation (wlan0)
> starting connection 'Non-auto Nonna.net'
> Sep 26 12:50:47 voubian NetworkManager[1417]: <info> (wlan0): device
> state change: 3 -> 4 (reason 0)
> [...]
> Sep 26 12:50:48 voubian NetworkManager[1417]: <info> Config: added
> 'bssid' value '00:19:5b:51:a3:e9'
> [...]
> Sep 26 12:58:15 voubian wpa_supplicant[1436]: Associated with
> 00:22:6b:a7:54:c1
> Sep 26 12:58:15 voubian wpa_supplicant[1436]: CTRL-EVENT-CONNECTED -
> Connection to 00:22:6b:a7:54:c1 completed (reauth) [id=0 id_str=]
> Sep 26 12:58:15 voubian NetworkManager[1417]: <info> (wlan0): supplicant
> connection state:  completed -> associated
> Sep 26 12:58:15 voubian NetworkManager[1417]: <info> (wlan0): supplicant
> connection state:  associated -> completed
> Sep 26 12:58:18 voubian NetworkManager[1417]: <info> (wlan0): roamed
> from BSSID 00:19:5B:51:A3:E9 (Nonna.net) to 00:22:6B:A7:54:C1
> (Nonna.net)
> 
> 
> (notice the 'config' parameter 'bssid'  - set in the connection
> properties UI - and the last line).
> 
> Is this a bug or am I missing anything?
> The situation is problematic because 00:22:6B:A7:54:C1 is a repeater
> which is indeed received with a stronger signal, but has a worse
> bandwith (since it's further from the AP).
> 
> In case it's influent: nm 0.8.1-2+b1 under Debian testing, the network
> driver is ndiswrapper, both AP and repeater work on the same channel
> with the same password WEP encryption.

Roaming is mostly up to the driver.  First make sure that the "bssid"
property is going to the supplicant in the logs, which will look like
this:

Sep 28 08:08:33 dcbw NetworkManager[1280]: <info> Config: added 'ssid' value 'abby'
Sep 28 08:08:33 dcbw NetworkManager[1280]: <info> Config: added 'scan_ssid' value '1'
Sep 28 08:08:33 dcbw NetworkManager[1280]: <info> Config: added 'bssid' value '00:0f:aa:bb:cc:dd'
Sep 28 08:08:33 dcbw NetworkManager[1280]: <info> Config: added 'key_mgmt' value 'NONE'
Sep 28 08:08:33 dcbw NetworkManager[1280]: <info> Config: added 'auth_alg' value 'OPEN'
Sep 28 08:08:33 dcbw NetworkManager[1280]: <info> Config: added 'wep_key0' value '<omitted>'
Sep 28 08:08:33 dcbw NetworkManager[1280]: <info> Config: added 'wep_tx_keyidx' value '0'

If that's happening, then we've told the supplicant not to roam.  After
that, it's up to the driver.  It may simply be the case that the Windows
driver you're using does not respect the request to lock to a specific
BSSID.  A quick check of ndisrapper sources shows that it does accept
the IWAP kernel call the is used to lock to a specific BSSID.

Basically, if you see the "Config: added bssid value xx:xx:xx:xx:xx:xx"
in your NetworkManager logs, it's then the supplicant and drivers
responsibility to suppress roaming.  At this point you'd want to rebuild
ndiswrapper with a small patch to put something like:

printk(KERN_INFO, "%s: setting AP address\n", __func__);

into iw_ndis.c's iw_set_ap_address() function and then check 'dmesg' to
verify that it's being called, or else enable ndiswrapper debugging and
make sure iw_set_ap_address() gets called.

Dan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]