wpa_s->bssid not getting cleared.
sukhdeep at gmail.com
Tue Mar 6 04:22:28 EST 2007
Thanks for your prompt response.
I am looking at version 0.4.9. Is it too old for discussion here ?
I will start planning to use 0.5.7 .
As you pointed, wpa_supplicant_event_disassoc() does clear the wpa_s->bssid,
but unfortunately, I am not getting that event from my client-card when the
AP is removed, or when assoc fails. I get a DEAUTHENTICATE, but no
corresponding EVENT_DEAUTH. I am checking if I should raise EVENT_DISASSOC
I am not using wpa_cli. I just remove ( power down ) the AP. I do this,
since there is no de-auth from the AP when I change the configuration, and
the client thinks that it is still connected. Removing the AP forces a
LOST-AP event on the client.
More details on my test/setup are given below.
Should I raise a bug for the change to wpa_supplicant_disassociate() ?
Test setup :
I was trying to see if any change done on the AP is properly updated by the
supplicant without shutting down/restarting the supplicant.
1. So, I start the test with single WLAN with CCMP and associate, ping the
2. I add another WLAN ( TKIP) to the AP so that it results in a mixed-mode
environ in which the pairwise-cipher is CCMP and group cipher should be
3. I restart the AP, so the MU forcibly re-associates to the AP.
I made the following observations :
1. At first, the supplicant was failing trying to match the RSN IE(correct
one) in the 3rd EAPOL mesg to the one(wrong one) it got in probe request (
group cipher mismatch). The reason is that the supplicant is not making a
request to get the latest scan results from the driver/client-card. <==
Should this not be a common problem ?
So, I forcibly make a new get_scan_results() request on every association.
2. Even then I observed that the group cipher was not properly updated. It
takes the default value from configuration file.
The reason was that though the assoc_wpa_ie is properly updated by the
wpa_supplicant_event_associnfo(), it is not used by
wpa_supplicant_event_assoc(). Since the wpa_s->bssid is not NULL,
wpa_supplicant_select_config()-->wpa_supplicant_set_suites() is not called
which sets the correct group cipher.
3. Then, I notice that after the last failure, wpa_supplicant_disassociate()
was called, but which left the wpa_s->bssid intact. this prevents proper
initialization on cipher suites the next time.
On 2/27/07, Jouni Malinen <j at w1.fi> wrote:
> On Mon, Feb 26, 2007 at 01:52:55PM +0530, Sukhdeep Johar wrote:
> > Why is wpa_s->bssid not being cleared in the
> > and wpa_supplicant_disassociate () ??
> Which version of wpa_supplicant are you looking at?
> wpa_supplicant_event_disassoc() clears wpa_s->bssid by calling
> wpa_supplicant_mark_disassoc(). wpa_supplicant_disassociate() does not
> seem to do this, though. I think it would be reasonable to modify
> wpa_supplicant_disassociate() to use wpa_supplicant_mark_disassoc() for
> this (after having called wpa_clear_keys() which needs the
> > Due to this, I notice that the supplicant is not able to set the
> > properly in the wpa_supplicant_event_assoc(), since the function doesn't
> > make a call to wpa_supplicant_select_config() when the wpa_s->bssid is
> > already configured.
> That's interesting.. I haven't seen this myself, but this looks like a
> possible path in the case when wpa_supplicant_disassociate() is used.
> > The association/authentication goes through fine the first time, since
> > wpa_s->bssid is NULL, and the proper configuration is set. But on later
> > invocations, when I remove the AP and bring it back to the network, I
> > observed the above.
> Are you doing anything with the client (e.g., wpa_cli commands) or just
> remove the AP and after some time bring it back?
> Jouni Malinen PGP id EFC895FA
> HostAP mailing list
> HostAP at shmoo.com
But for the last minute,... Nothing would get done.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the HostAP