wpa_s->bssid not getting cleared.

[Sukhdeep Johar]

Hi Juoni,

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
instead.

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() ?

regards,
Sukhdeep

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
MU.
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
TKIP.
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.

regds,
Sukhdeep
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
> wpa_supplicant_event_disassoc()
> > 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
> wpa_s->bssid).
>
> > Due to this, I notice that the supplicant is not able to set the
> cipher-id
> > 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
> the
> > 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
> http://lists.shmoo.com/mailman/listinfo/hostap
>



-- 
But for the last minute,... Nothing would get done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20070306/fa85f2f9/attachment.htm