#7825 BLOC 8.2.0 (: can't complete WPA handshake with D-Link WBR-2310

[Zarro Boogs per Child]

#7825: can't complete WPA handshake with D-Link WBR-2310
------------------------+---------------------------------------------------
   Reporter:  dsd       |       Owner:  jcardona            
       Type:  defect    |      Status:  assigned            
   Priority:  blocker   |   Milestone:  8.2.0 (was Update.2)
  Component:  wireless  |     Version:  not specified       
 Resolution:            |    Keywords:  8.2.0:? relnote     
Next_action:  review    |    Verified:  1                   
  Blockedby:            |    Blocking:                      
------------------------+---------------------------------------------------

Comment(by jcardona):

 Replying to [comment:33 carrano]:
 > Replying to [comment:32 carrano]:
 >
 > > In short, no doubt that reducing key installation time improved
 matters, the question is what other issues may prevent us to associate to
 WPA APs.
 >
 > Actually, I'll step back a little and rephrase that: "What is preventing
 us to associate", since this issue I am facing may not be related to WPA.
 Still, I'll post this here for now, and ask for your opinions whether this
 is material for another ticket.
 >
 > What I notice is that during repetitions of the associate to WPA test
 there are some failures that do not seem related to WPA. I've been trying
 to capture logs. For now, what I have is a lot of nonsensical scanning
 information in dmesg output.
 >
 > * APs listed with wrong SSIDs
 > * APs listed with wrong mac addresses
 > * APs with 00:00:00:00:00:00 mac address
 > * bogus hidden SSIDs
 > * Deauthentications due to "New BSSID"
 >
 > One interesting example:
 > {{{
 > [ 1514.829213] libertas scan: 00: BSSID 02:2d:3d:c5:45:07, RSSI 32, SSID
 'olpc-mesh'
 > [ 1514.829213] libertas scan: 01: BSSID 00:00:00:00:00:00, RSSI 0, SSID
 '<hidden>'
 > [ 1514.829213] libertas scan: 02: BSSID 00:14:6c:df:aa:00, RSSI 60, SSID
 'Harumaki'
 > [ 1514.829213] libertas scan: 03: BSSID 00:16:01:84:2b:0f, RSSI 64, SSID
 'zocos'
 > [ 1514.829213] ADDRCONF(NETDEV_CHANGE): msh0: link becomes ready
 > [ 1514.831117] libertas scan: is_network_compatible() FAILED: wpa_ie
 0xdd wpa2_ie 0x0 WEP d WPA d WPA2 d privacy 0x10
 > [ 1514.831153] libertas scan: is_network_compatible() FAILED: wpa_ie
 0xdd wpa2_ie 0x0 WEP d WPA d WPA2 d privacy 0x10
 > [ 1514.831181] libertas assoc: Could not find best network
 > [ 1514.831201] libertas assoc: ASSOC: reconfiguration attempt
 unsuccessful: -101
 > [ 1514.831250] libertas assoc: Association Request:
 > [ 1514.831261]     flags:     0x00000770
 > [ 1514.831271]     SSID:      'zocos'
 > [ 1514.831279]     chann:     11
 > [ 1514.831288]     band:      0
 > [ 1514.831296]     mode:      2
 > [ 1514.831304]     BSSID:     00:00:00:00:00:00
 > [ 1514.831314]     secinfo:
 > [ 1514.831322]     auth_mode: 1
 > [ 1514.831348] libertas assoc: Deauthenticating due to new BSSID
 > }}}
 >
 > It seems that scanning is generating garbage and, as this is the initial
 phase of an association it will have a domino effect over the process.
 >
 > Note: this tests are using the kernel Deepak patched for us and 8.2-760.
 >
 > What do you think? Should we spin off a scanning issue ticket or am I
 chasing ghosts?

 A while ago the association related tasks were moved to a deferred work
 queue.  One of the delayed tasks was the installation of keys.  My patch
 removes the artificial delays in key installation.  It may have affected
 how association requests are constructed and the command sequence sent to
 the firmware.

 So cannot have affected scanning, but it may have affected association.

 1. Could you run your test with 0x4121 >
 /sys/modules/libertas/parameters/libertas_debug?  That would show us the
 command sequence sent to firmware.

 2. Can you post your testing procedure to the ticket?

 Thanks!

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