#4131 BLOC First D: WLAN appears to die after some number of suspend/resumes

[Zarro Boogs per Child]

#4131: WLAN appears to die after some number of suspend/resumes
-----------------------+----------------------------------------------------
  Reporter:  wad       |       Owner:  wad                   
      Type:  defect    |      Status:  reopened              
  Priority:  blocker   |   Milestone:  First Deployment, V1.0
 Component:  wireless  |     Version:                        
Resolution:            |    Keywords:  mesh, relnote         
  Verified:  0         |  
-----------------------+----------------------------------------------------

Comment(by jcardona):

 Replying to [comment:16 cjb]:
 > Hi Javier,
 >
 > We're in China, so you don't have sniffer access.

 You can
 [http://wiki.laptop.org/go/Wireless#Capturing_wireless_traffic_on_the_xo
 capture traffic with any xo].

 > We think the AP was sending
 > traffic to the XOs, because other XOs in the room were resuming, and
 because these
 > XOs started to suspend/resume successfully again once we rebooted them.

 What I had observed before is that the AP was in the bad state, not the
 xo.  In particular, traffic addressed to one particular xo was sent to a
 different one.  Other nodes were unaffected.  That seems to be consistent
 with your observation.
 Are you still using the Linksys WRT54G?

 > Also, when we woke them up by hand, we tried to ping the AP, and
 couldn't get any
 > response from it despite it still being there.

 If the AP is in the bad state that I described
 [http://dev.laptop.org/ticket/4131?replyto=16#comment:7 above], some nodes
 should still be able to ping it.

 > Could you let me know how to send mesh traffic to the nodes, please?

 1. Associate the source xo (Y) with the same AP that the suspended xo (X)
 is associated with and bring up the mesh interface.  The association is
 just to be sure that both are in the same channel:  the AP will not be
 used to send traffic.
 {{{
   # iwconfig eth0 mode managed essid <your_ssid>
   # ifconfig msh0 192.168.5.Y
 }}}

 2. Manually populate the arp table on the ping source
 {{{
   # arp -s <192.168.5.X> <xo_Y_mac>
 }}}

 3. Ping
 {{{
   # ping 192.168.5.X
 }}}

 > I left one machine turned on and still in the bad state.  Is there
 anything we can > do on it for you?

 Wake up manually and try to ping other nodes over mesh.  Does that work?
 Can you sniff from another xo and see if any is traffic transmitted?

-- 
Ticket URL: <https://dev.laptop.org/ticket/4131#comment:18>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system