#9235 NORM 8.2.1: 8.2.1 WPA connectivity regressions

[Zarro Boogs per Child]

#9235: 8.2.1 WPA connectivity regressions
--------------------------------+-------------------------------------------
           Reporter:  dsd       |       Owner:  mbletsas     
               Type:  defect    |      Status:  new          
           Priority:  normal    |   Milestone:  8.2.1        
          Component:  wireless  |     Version:  not specified
         Resolution:            |    Keywords:               
        Next_action:  diagnose  |    Verified:  0            
Deployment_affected:            |   Blockedby:               
           Blocking:            |  
--------------------------------+-------------------------------------------

Comment(by dsd):

 The argument that "it works in one configuration therefore there is no bug
 in my code" is rarely valid... Also, if you could not establish a
 connection on build 767 then that is a different bug - this bug is about
 regressions, that is, APs that used to work that no longer do.

 When testing using with wpa_supplicant, I found that my success
 consistently varied depending on whether I was using -d or -dd or not.
 This further suggests problems with timing, depending on exactly how busy
 the CPU is at the time of connection.

 Note that the debug output must be going onto the active console, not to a
 file, for this behaviour to happen (the important thing being that the CPU
 is busy drawing lots of text on the framebuffer).

 Also, there are actually 2 bugs being described here.
  1. Some WPA APs used to work, but now do not (or the connectivity is
 noticably less reliable)
  2. Even with APs that do work, the automatically-established connection
 after a reboot fails in a very mysterious way (association and WPA
 handshake *complete* but it fails during actual data transfer, e.g. DHCP).

 From the information above, it sounds like they haven't attempted to
 reproduce #2. At least to me, it seems unlikely that a bug in userspace
 could cause that problem. It would be very interesting to run another
 system with wireshark in monitor mode when this happens. I suspect that
 somehow the keys are being lost or corrupted and hence the packets are not
 transmitted correctly.

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