#9048 HIGH Not Tri: Wireless scanning causes network pauses

Zarro Boogs per Child bugtracker at laptop.org
Wed Nov 26 15:58:39 EST 2008


#9048: Wireless scanning causes network pauses
---------------------------------+------------------------------------------
           Reporter:  johnf      |       Owner:  mbletsas        
               Type:  defect     |      Status:  new             
           Priority:  high       |   Milestone:  Not Triaged     
          Component:  wireless   |     Version:  not specified   
         Resolution:             |    Keywords:  scan packet loss
        Next_action:  never set  |    Verified:  0               
Deployment_affected:  Australia  |   Blockedby:                  
           Blocking:             |  
---------------------------------+------------------------------------------

Comment(by jcardona):

 Replying to [comment:9 ashish]:
 > I believe during scan, firmware sends NULL frame with PM bit set to 1 to
 AP before moving off-channel to prevent frame loss. Therefore, I expect
 there should not be frame loss in ingress as well unless scan is taking
 too large and AP fails to buffer traffic.
 >

 Thanks Ashish.  We've confirmed that with the sniffer, and yes, we see no
 loss of ingress traffic. Of course this only applies to infra traffic, as
 there is no way to prevent ingress losses on the mesh interface while
 scanning.

 > One difference I could see in the attached dmesg log is the number of
 channels that are sent
 > by the driver to firmware while doing progressive scan. In build 656,
 where it seems there is > no frame loss, driver sends 1 or 2 channels per
 scan (command 0x6), whereas in build 767,
 > driver sends 4-5 channels per scan.

 The driver stops the interface queues before scanning.  The purpose of
 that is to inform the networking stack that sits above the driver cannot
 currently process new packets.  It would be
 entirely valid behavior if the IP stack just dropped those packets:  after
 all this is just best effort delivery.

 We'll try to confirm that the packets are indeed dropped (and not
 buffered) at the network stack layer.

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


More information about the Bugs mailing list