[Trac #841] reproducible loss of wireless association

[Zarro Boogs per Child]

#841: reproducible loss of wireless association
----------------------+-----------------------------------------------------
 Reporter:  Quozl     |        Owner:  marcelo 
     Type:  defect    |       Status:  assigned
 Priority:  blocker   |    Milestone:  BTest-3 
Component:  wireless  |   Resolution:          
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by rchokshi):

 Replying to [comment:19 dcbw]:
 > This should also be reproducible by doing a manual connection and
 running 'iwlist eth0 scan' every so often.
 >
 > Scanning should _not_ cause the firmware or driver to loose the
 association to the AP ever.  We should probably make sure that userspace-
 triggered scanning is async, so that each scan request actually triggers 3
 or 4 firmware scan commands.  They are already broken up like that in the
 driver, but the driver blocks on completion of all 3 before returning.
 The trick is to make sure you don't stay off the currently associated AP's
 channel for too long; so after scanning each channel or two (using ~ 200 -
 250ms dwell time), jump back to the association channel for a bit, then
 scan two more channels, etc.

 Ronak >> this is correct explanation. We usually fix the dwelling time to
 be 100ms maximum, assuming that the beacon interval on the APs is 100TUs.
 But if you want to scan a lot of channels at one time, you can sqeeeze the
 max channel dwelling time to be approx. 50ms and do an active scan (if you
 are currently doing a passive scan).

 >
 > We should put some debugging code into the driver to see exactly how
 long a scan really takes, and how long the card is on a different channel
 than the current association channel.  Another option is to have the card
 tell the AP to queue packets and such when it scans, which is similar to
 the notification cards send when they enter brief sleep for power saving.

 Ronak >> This is also a trick that we do sometimes. Just that if this is
 really required, we will have to provide an additional hook to you guys to
 program the firmware to send a NULL Data packet to the AP. I will check
 into this.

-- 
Ticket URL: <http://dev.laptop.org/ticket/841#comment:20>
One Laptop Per Child <http://laptop.org/>