#10694 NORM 11.3.0: After XO-1 sleep, there is a 3-4min delay before wireless access points appear

[Zarro Boogs per Child]

#10694: After XO-1 sleep, there is a 3-4min delay before wireless access points
appear
---------------------------------------+------------------------------------
           Reporter:  erikos           |       Owner:  dsd                              
               Type:  defect           |      Status:  new                              
           Priority:  normal           |   Milestone:  11.3.0                           
          Component:  network manager  |     Version:  Development build as of this date
         Resolution:                   |    Keywords:                                   
        Next_action:  diagnose         |    Verified:  0                                
Deployment_affected:                   |   Blockedby:                                   
           Blocking:                   |  
---------------------------------------+------------------------------------

Comment(by dsd):

 I moved house a few times and now I can reproduce this!

 This is quite a tangled issue. And its racy, so it doesn't *always*
 happen. And you won't see it so much if your AP is on a channel lower than
 5.

 When the system goes into suspend, the device goes away as the hardware
 gets powered down. However NetworkManager does not get to act on this
 until system resume time.

 The system resumes, the new network device appears and NetworkManager
 immediately kicks off a scan.

 Then, NM and wpa_supplicant take care of the old device going away. NM
 tells wpa_supplicant to remove the interface, and wpa_supplicant tries to
 disconnect and stuff. We get to:

 {{{
 static void wpa_driver_wext_disconnect(struct wpa_driver_wext_data *drv)
 {
         const u8 null_bssid[ETH_ALEN] = { 0, 0, 0, 0, 0, 0 };
         u8 ssid[32];
         int i;

         /*
          * Clear the BSSID selection and set a random SSID to make sure
 the
          * driver will not be trying to associate with something even if
 it
          * does not understand SIOCSIWMLME commands (or tries to associate
          * automatically after deauth/disassoc).
          */
         wpa_driver_wext_set_bssid(drv, null_bssid);

         for (i = 0; i < 32; i++)
                 ssid[i] = rand() & 0xFF;
         wpa_driver_wext_set_ssid(drv, ssid, 32);
 }
 }}}

 Unfortunately, wext is quite badly designed here. The wext ioctls take a
 string to identify which network interface you want to act upon - i.e.
 "eth0"

 So even though wpa_supplicant is trying to disconnect the eth0 that went
 away as we went into suspend, in which case we would want these operations
 to be a no-op/error (acting on dead device), actually eth0 has gone away
 and come back as a new device, and these operations take effect on the new
 eth0.

 As the function shows, to disconnect, wpa_supplicant asks for association
 to a random SSID. This request reaches libertas, which decides to abort
 the current all-channel all-SSID scan (which by this time is only
 partially complete and usually has only scanned about one third of the
 channels), and replace it with a SSID-specific scan for the random SSID
 that wpa_supplicant requested. This SSID-specific scan completes with no
 results (surprise surprise) so the driver then presents the results of the
 first (incomplete) scan, the results of which are incomplete. The next
 scan won't happen for a few minutes, leading to this experience where most
 APs only appear after waiting a while.

 This problem would go away with F15+ and a newer kernel, where nl80211
 would be used instead of wext inside wpa_supplicant. nl80211 sensibly uses
 ifindex, not interface name, to identify which device you want to talk to.

 Nevertheless, I'll see if I can untangle this inside of libertas.

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