#1974 HIGH Trial-3: need null packet support in libertas firmware

[Zarro Boogs per Child]

#1974: need null packet support in libertas firmware
--------------------------+-------------------------------------------------
  Reporter:  dcbw         |       Owner:  rchokshi
      Type:  enhancement  |      Status:  new     
  Priority:  high         |   Milestone:  Trial-3 
 Component:  wireless     |     Version:          
Resolution:               |    Keywords:          
  Verified:  0            |  
--------------------------+-------------------------------------------------
Changes (by rchokshi):

  * type:  defect => enhancement

Comment:

 Replying to [comment:4 dcbw]:
 > Ronak; thanks for the new firmware with null packet.

 You are welcome :).

 >
 > One question about it though.  Does the firmware automatically do this
 when issues a scan command, or is the interface for controlling NULL
 packets as described in the spec  on pg. 24 (Table 4: Transmit Packet
 Flags) implemented?  Ideally we'd the Transmit Packet Flags available to
 us as well, though that's not a blocker for trial-2 at all.

 I understand but right now, the firmware will send NULL packets everytime
 you scan (only while associated) channels other than the current WiFi
 channel. To make the most use of this transmission power and the time
 spent away from the channel, you could scan 5 - 6 channels at a time (i.e.
 half the channels available). This way, you would remain away from the AP
 for a reasonable time but not for too long.

 >
 > Originally this was a blocker due to suboptimal scan behavior that
 resulted from fixes to a bug we had a long time ago where the AP would
 time out the association because the card was away from the channel for so
 long.  That fix broke up the scan into 3 distinct pieces (separately from
 the additional breakup to avoid overrunning the returned firmware scan TLV
 buffer).  I've since fixed that up in the driver and made the scanning
 behavior _better_, but it's still not optimal and we'd like to bound the
 _entire_ scan with NULL packets.  Currently the driver is still breaking
 up full scans from the WEXT interface into 3 or 4 separate runs, waiting
 300ms in between each run for the card to return to the associated
 channel.  Bounding full scans with NULL packets should (?) enable us to
 get rid of that 300ms wait between sub-scans.

 Ronak >> In lieu of my comment above, this should be fine as well.

 >
 > Ronak, can you reclassify this as "enhancement" when you've replied to
 the question I posted about which interface the NULL packet stuff exposes
 (ie, Table 4, p. 24 or otherwise)? It's no longer a blocker for Trial-2
 but still need to clarify the firmware interface for this from you.

 Ronak >> Done.

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