#5485 HIGH Update.: Doesn't accept my Wep key anymore

[Zarro Boogs per Child]

#5485: Doesn't accept my Wep key anymore
-----------------------+----------------------------------------------------
  Reporter:  gdesmott  |       Owner:  mbletsas
      Type:  defect    |      Status:  reopened
  Priority:  high      |   Milestone:  Update.1
 Component:  wireless  |     Version:          
Resolution:            |    Keywords:          
  Verified:  0         |    Blocking:          
 Blockedby:            |  
-----------------------+----------------------------------------------------

Comment(by dcbw):

 For the mesh autostart thing, it was always kind of flaky.  ISTR that mesh
 autostart cleared some device state in the firmware or something like that
 that screwed the existing connection.  That wasn't my understanding of how
 it was _supposed_ to work (which was just to bring up the mesh if no
 association was performed within 10 seconds or something).  It just
 screwed with the internal firmware state and stuff just didnt' work.

 For the should_deauth_infrastructure() issue, when the
 CMD_802_11_DEAUTHENTICATE command response comes back from the firmware,
 lbs_mac_event_disconnected() is called which clears priv->connect_status,
 frees current rx & tx packets, and sends the SIOCSIWAP "disassociated"
 WEXT signal.  It's quite unclear what the firmware's behavior actually is
 in this case, and I can't really see what in the driver would depend on
 priv->connect_status to substantially change behavior.

 If the status is already LBS_CONNECTED, that doesn't mean anything for the
 association process really.  The driver logs indicate that the correct
 association parameters were sent to the firmware, and that the driver
 received an appropriate association response from the firmware after
 completing the association and authentication commands.  Note that each
 test I did was a separate run of the supplicant, like so:

 {{{
 a) do something in driver
 b) build driver
 c) insmod modules
 d) run wpa_supplicant
 e) run dhclient
 f) killall -TERM dhclient
 g) Ctl+C wpa_supplicant
 h) go to (d)
 }}}

 The second run of the supplicant would correctly associate, but no packets
 ever got received by the driver and passed up to the kernel.  They got
 filtered out somewhere in firmware, or perhaps the DHCP requests never got
 received by the APs I was using.

 To ensure that it's not the driver, but would be the firmware, we would
 need to instrument the driver at every applicable place where
 priv->connect_status is checked and ensure that the branch taken there had
 no real effect on the association process.  A quick look over the code
 doesn't seem like it does, and the diffs of the driver dmesg log output I
 looked at didn't show any significant differences _other_ than the
 should_deauth_infrastructure() change.  I didn't see any real differences
 in command #s sent to the driver (with the exception of the missing
 DEAUTHENTICATE), but I did not inspect the actual command contents.

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