#8799 HIGH 8.2.1: WPA association issue: XO do not respond to first EAPOL frame

[Zarro Boogs per Child]

#8799: WPA association issue: XO do not respond to first EAPOL frame
---------------------------+------------------------------------------------
     Reporter:  carrano    |        Owner:  jcardona     
         Type:  defect     |       Status:  new          
     Priority:  high       |    Milestone:  8.2.1        
    Component:  wireless   |      Version:  not specified
   Resolution:             |     Keywords:               
  Next_action:  never set  |   Spec_stage:  unknown      
    Blockedby:             |     Blocking:               
Spec_reviewer:             |     Verified:  0            
Spec_reviewed:  0          |  
---------------------------+------------------------------------------------

Comment(by jcardona):

 One of the failure modes that we see ("bad-secinfo") is characterized by
 using
 an invalid security configuration to associate with a WPA AP.  This only
 happens when the association is requested from the GUI.  A log showing
 this
 failure is included in my previous comment:

 {{{
 [  520.445201]     secinfo:             #  <---- should be WPA
 }}}

 In my last comment I suspected the driver clearing secinfo.  Turns out
 that the security info is cleared by wpa_supplicant via a SIOCSIWAUTH
 ioctl prior to associating:

 {{{
 [70110.612569] libertas wext: IW_AUTH_WPA_VERSION_DISABLED
 }}}

 In addition to this, we've observed that this failure always happens when
 NetworkManager invokes wpa_supplicant with a ap_scan mode set to 2 (see
 /usr/share/doc/wpasupplicant/examples/README.wpa_supplicant.conf for
 details about scan modes).
 In those instances when NM invokes wpa_supplicant with ap_scan mode set to
 1 we do
 not observe this failure.

 We can successfully associate with our AP by invoking wpa_supplicant in
 both
 modes, 1 and 2.  But looking at NM source code we see that AP_SCAN 2 is
 only
 used if:

 {{{
 if (!nm_ap_get_broadcast (ap) || is_adhoc || !supports_wpa)
                 ap_scan = "AP_SCAN 2";
 }}}

 And none of these conditions should be true:

  * !nm_ap_get_broadcast (ap): true for hidden APs that do not broadcast
 their SSID (not our case)
  * is_adhoc: if the network is ad_hoc
  * !supports_wpa: if the driver reports that the hardware can't do WPA

 Our conclusion at this time is that this failure occurs because NM gets
 invalid information about the AP and invokes wpa_supplicant with invalid
 security parameters.

-- 
Ticket URL: <http://dev.laptop.org/ticket/8799#comment:7>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system