Re: Bssid to supplicant config

[Dan Williams <dcbw redhat com>]

On Mon, 2008-05-19 at 10:04 +0800, charlyliu wrote:
> hi Dan,
> 
> After adding the function you wrote, I still have the same problem. the log is:
> 
> May 19 09:36:10 fc8 NetworkManager: <info>  Config: added 'ssid' value 'home'
> May 19 09:36:10 fc8 NetworkManager: <info>  Config: added 'scan_ssid' value '1'
> May 19 09:36:10 fc8 NetworkManager: <info>  Config: added 'bssid' value ''

Ok, looks like something's wrong with NM here.  I'll put it on my list
of things to check.

> May 19 09:36:10 fc8 NetworkManager: <info>  Config: added 'key_mgmt' value 'NONE'
> May 19 09:36:10 fc8 NetworkManager: <info>  Config: added 'auth_alg' value 'OPEN'
> May 19 09:36:10 fc8 NetworkManager: <info>  Config: added 'wep_key0' value '<omitted>'
> May 19 09:36:10 fc8 NetworkManager: <info>  Config: added 'wep_tx_keyidx' value '0'
> May 19 09:36:10 fc8 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
> May 19 09:36:10 fc8 NetworkManager: <info>  Config: set interface ap_scan to 1
> May 19 09:36:10 fc8 NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 0
> May 19 09:36:10 fc8 NetworkManager: <WARN>  set_network_cb(): Couldn't set network config: Did not receive correct message arguments..
> May 19 09:36:10 fc8 NetworkManager: <info>  Activation (wlan0/wireless): association request to the supplicant failed: fi.epitest.hostap.WPASupplicant.InvalidOptions - Did not receive correct message arguments.
> 
> 
> The other day also looked why wpa_supplicant doesn't take the ap I wanted and not the other with the same name and I saw that they don't have a case for my situation, When they are choosing the AP to connect they don't look if a connection has wep encryption and the ap has wpa encryption. I will also write now to wpa_supplicant to see if it's a bug.

Unfortunately, I think that's a legal combination.  Because WEP didn't
have much information in the beacon (just used the Privacy bit), you
can't tell much about it.  And having an AP that advertises WPA but also
supports legacy WEP clients is a configuration that is actually used.
In this case, all the AP can do is set the Privacy bit in it's beacon
(like static WEP), but that's also used for WPA, so you cannot tell that
the AP also supports static WEP.  There would be no difference between
an AP that supports WPA + Static WEP, and one that just supported WPA.

You _may_ be able to tell from the WPA IEs if the AP says it supports
WEP40 or WEP104 group encryption, but I'm not sure that's standardized
at all, and you certainly should not depend on that to indicate WPA +
static WEP support.

I think this is more a case of network misconfiguration, because APs in
the same ESS don't have compatible capabilities.

Dan

> Thanks Dan,
> 
> Charly Liu
> 
> -----Original message-----
> From:Dan Williams <dcbw redhat com>
> To:charlyliu linpus com
> Cc:networkmanager-list <networkmanager-list gnome org>
> Date:Tue, 13 May 2008 12:12:00 -0400
> Subject:Re: Bssid to supplicant config
> 
> On Fri, 2008-05-16 at 15:46 +0800, charlyliu wrote:
> > Hi all,
> > 
> > I'm trying to pass the AP bssid to a connection setting (at wireless_new_auto_connection) so when I want to connect, I also check the bssid. I do this because I notice that it doesn't connect if there is 2 aps with the same SSID and one is with WEP encryption (the one I want to connect to). 
> 
> This sounds somewhat like a driver problem.  Given an SSID and security
> parameters (via ENCODE, or ENCODEEXT + GENIE + AUTH), the driver takes
> the intersection of the parameters given to it by userspace, and it's
> own internal scan list, and uses one of the resulting BSSIDs to
> associate with.
> 
> So given an SSID and WEP encryption, the driver should not even be
> considering association with the non-WEP AP.  However, if both APs have
> the same SSID, and the same security parameters, then the driver would
> be free to choose either AP to associate with since there's no
> discernable difference between their capabilities.
> 
> > I tried many ways, saving a ether_addr inside the bssid->data, saving the string that I get with the function nm_access_point_get_hw_address and changing the settings verify, nm_ap_check_compatible and nm_supplicant_config_add_setting_wireless. But either ways work.
> 
> bssid is a GByteArray, so you'll need to initialize it with something
> like:
> 
> void set_bssid(struct ether_addr *addr, NMSetting80211Wireless *s_wireless)
> {
> 	if (s_wireless->bssid)
> 		g_byte_array_free (s_wireless->bssid, TRUE);
> 
> 	s_wireless->bssid = g_byte_array_sized_new (ETH_ALEN);
> 	g_byte_array_append (s_wireless->bssid, (const guint8 *) addr->ether_addr_octet, ETH_ALEN);
> }
> 
> Then of course that setting information gets pushed down to
> NetworkManager, which pushes it further down to the supplicant.  In your
> syslog messages during connection, do you see anything like:
> 
> NetworkManager: <info>  Config: added 'bssid' value 'xx:xx:xx:xx:xx:xx'
> 
> after setting the BSSID correctly in your settings service?  If not,
> then there's a bug in NetworkManager.
> 
> Dan
>