<div>Hi Juoni,</div>
<div> </div>
<div>Thanks for your prompt response. </div>
<div> </div>
<div>I am looking at version 0.4.9. Is it too old for discussion here ? </div>
<div>I will start planning to use 0.5.7 .</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>More details on my test/setup are given below. </div>
<div> </div>
<div>Should I raise a bug for the change to wpa_supplicant_disassociate() ?</div>
<div> </div>
<div>regards,</div>
<div>Sukhdeep</div>
<div> </div>
<div>Test setup :</div>
<div>-----------------</div>
<div>I was trying to see if any change done on the AP is properly updated by the supplicant without shutting down/restarting the supplicant.</div>
<div>1. So, I start the test with single WLAN with CCMP and associate, ping the MU.</div>
<div>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.</div>
<div>3. I restart the AP, so the MU forcibly re-associates to the AP.</div>
<div> </div>
<div>I made the following observations : </div>
<div>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 ?
</div>
<div>So, I forcibly make a new get_scan_results() request on every association. </div>
<div> </div>
<div>2. Even then I observed that the group cipher was not properly updated. It takes the default value from configuration file.</div>
<div>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.
<br> </div>
<div>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.<br> </div>
<div>regds,</div>
<div>Sukhdeep</div>
<div><span class="gmail_quote">On 2/27/07, <b class="gmail_sendername">Jouni Malinen</b> <<a href="mailto:j@w1.fi">j@w1.fi</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Mon, Feb 26, 2007 at 01:52:55PM +0530, Sukhdeep Johar wrote:<br><br>> Why is wpa_s->bssid not being cleared in the wpa_supplicant_event_disassoc()
<br>> and wpa_supplicant_disassociate () ??<br><br>Which version of wpa_supplicant are you looking at?<br>wpa_supplicant_event_disassoc() clears wpa_s->bssid by calling<br>wpa_supplicant_mark_disassoc(). wpa_supplicant_disassociate() does not
<br>seem to do this, though. I think it would be reasonable to modify<br>wpa_supplicant_disassociate() to use wpa_supplicant_mark_disassoc() for<br>this (after having called wpa_clear_keys() which needs the<br>wpa_s->bssid).
<br><br>> Due to this, I notice that the supplicant is not able to set the cipher-id<br>> properly in the wpa_supplicant_event_assoc(), since the function doesn't<br>> make a call to wpa_supplicant_select_config() when the wpa_s->bssid is
<br>> already configured.<br><br>That's interesting.. I haven't seen this myself, but this looks like a<br>possible path in the case when wpa_supplicant_disassociate() is used.<br><br>> The association/authentication goes through fine the first time, since the
<br>> wpa_s->bssid is NULL, and the proper configuration is set. But on later<br>> invocations, when I remove the AP and bring it back to the network, I<br>> observed the above.<br><br>Are you doing anything with the client (
e.g., wpa_cli commands) or just<br>remove the AP and after some time bring it back?<br><br>--<br>Jouni Malinen PGP id EFC895FA<br>_______________________________________________<br>
HostAP mailing list<br><a href="mailto:HostAP@shmoo.com">HostAP@shmoo.com</a><br><a href="http://lists.shmoo.com/mailman/listinfo/hostap">http://lists.shmoo.com/mailman/listinfo/hostap</a><br></blockquote></div><br><br clear="all">
<br>-- <br>But for the last minute,... Nothing would get done.