#10397 NORM Not Tri: XOs may fail to communicate in noisy 802.11 environment

[Zarro Boogs per Child]

#10397: XOs may fail to communicate in noisy 802.11 environment
-----------------------+----------------------------------------------------
 Reporter:  greenfeld  |                 Owner:  wad          
     Type:  defect     |                Status:  new          
 Priority:  normal     |             Milestone:  Not Triaged  
Component:  hardware   |               Version:  not specified
 Keywords:             |           Next_action:  never set    
 Verified:  0          |   Deployment_affected:               
Blockedby:             |              Blocking:               
-----------------------+----------------------------------------------------
 I am testing several XOs of varying OS versions with a few access points
 we have in our XO testing room.  The XOs are typically placed 1 to 5 feet
 away from the AP.

 Still, the XOs seem to have difficulty finding each other at the Sugar
 level, as well as connecting to the schoolserver on the AP. But the signal
 meters shown by iwconfig on the XOs tend to report near-perfect quality
 connection estimates (100/100 or 70/70).  But taking a few XOs home along
 with an AP results in much better network performance than working in the
 office.

 Complicating things are the high number of 802.11 APs in the surrounding
 area.  It may take 5-10+ sweeps by an XO's wireless card before said
 computer detects the ESSID of the AP in the same room with it.  A single
 "iwlist eth0/wlan0 scan" command will spot anywhere between 25-40 ESSIDs.
 Repetitive scans joined together with grep/sort/uniq spotted approximately
 70 unique ESSIDs in the area.

 Running the ping command shows ping times typically at the <50 ms end of
 the 5-300 ms range, but with seemingly random jumps in response times with
 no packet loss.  Iwconfig reports that there are rx crypt errors at a
 lower level even with encryption disabled, but I do not know what the
 expected/acceptable error rates for decoding an 802.11 channel are.

 I'm filing this ticket in case anyone has any ideas on how to look into
 this, and also to personally track this.   Purely TCP-based communications
 from the laptop (such as HTTP) seem to work fine as well as DHCP/DNS
 requests.

 Watching with Wireshark on another laptop, I sometimes see periods where
 mDNS requests are not responded to (or at least said responses heard).
 And the laptops often never come out of salut and switch to gabble/jabber
 even if they were previously successfully registered to the schoolserver.
 I do not however know if this is the root cause.

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