#9160 NORM Not Tri: XO-AP: spurious association requests

[Zarro Boogs per Child]

#9160: XO-AP: spurious association requests
----------------------------------+-----------------------------------------
 Reporter:  carrano               |                 Owner:  carrano      
     Type:  defect                |                Status:  new          
 Priority:  normal                |             Milestone:  Not Triaged  
Component:  wireless-thin-driver  |               Version:  not specified
 Keywords:                        |           Next_action:  reproduce    
 Verified:  0                     |   Deployment_affected:               
Blockedby:                        |              Blocking:               
----------------------------------+-----------------------------------------
 (This can be related to #9048)

 When XOs are associated to an XO-AP (XO running as an AP):

 - All the associated stations issue Association Requests in sync at every
 100 seconds or so. The fact that they are in sync indicates that this is
 somehow triggered by the AP.

 - Pings from a station to the AP will fail in a sequence, of between 5 and
 30 seconds. The association led (keyhole) will indicate that the XO is
 reassociating and the hostapd output on the XO-AP will confirm this.

 - Testing with chat. Occasionally an XO will leave the chat and join
 again. I believe that this will happen during longer blackouts, i.e, will
 be related to the same issue (above).

 The periodic assoc requests are triggered by NM (if NM is not running the
 reassociation does not occur), but the root cause seems to lie on the XO-
 AP, since the reassociations *are not* observed when the XOs are connected
 to regular APs. The resulting blackouts will be experienced by the
 activities on the XO.

 Overall, it seems that the XOs are losing association frequently. After
 the new fix for #9048, it is time to test that again.

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