#10458 NORM Not Tri: os353+ XO-1 - randomly, Neighborhood View does not support making connections, but does not tell the user what is wrong

[Zarro Boogs per Child]

#10458: os353+ XO-1 - randomly, Neighborhood View does not support making
connections, but does not tell the user what is wrong
-------------------------+--------------------------------------------------
 Reporter:  mikus        |                 Owner:  erikos                           
     Type:  enhancement  |                Status:  new                              
 Priority:  normal       |             Milestone:  Not Triaged                      
Component:  sugar        |               Version:  Development build as of this date
 Keywords:               |           Next_action:  never set                        
 Verified:  0            |   Deployment_affected:                                   
Blockedby:               |              Blocking:                                   
-------------------------+--------------------------------------------------
 Sometimes, clicking on an icon in Neighborhood View may fail to produce
 the expected result.
 [[BR]]os353 xo-1 (manually upgraded with latest rpms).

 ----
   Rarely, this XO-1 system after boot shows three mesh icons in
 Neighborhood View, but clicking on them has no effect.  These situations
 are usually accompanied by 'eth0' being missing from 'ifconfig'.  It is
 not the hardware -- I can start up (and use) the mesh by manually issuing
 'ifconfig' and 'route' commands (with appropriate IP addresses) to the
 'msh0' interface.  But since there exists a bypass, this situation is not
 a show-stopper.

 ----
 My reason for writing this ticket is that on one particular system,
 Neighborhood View often (but not always) fails to show any Access Point
 Icons.  [I've seen this symptom, but rarely, on another XO-1 system.  My
 remaining os353 XO-1s all have properly usable Neighborhood Views.]

 The problem can be an undefined 'eth0' interface (as in #10195), or it can
 be that even after I issue 'ifconfig eth0 up', that interface fails to
 scan for WiFi networks.

 When Neighborhood View fails to show any Access Point icons, the
 experienced user can go to Terminal and use manual commands to view the
 status of 'eth0', and the status of scanning.  But as noted in #10292 (for
 the radio being off) there is no specific indication in Neighborhood View
 as to HOW COME access point icons are not being shown.  To address
 uncertainty, the user needs to be informed "what to do now" (e.g., by a
 warning message at the top of Neighborhood View).

 But what is REALLY wrong with Neighborhood View is when it *does* show
 icons to be clicked on -- but that information is unusable.  I am writing
 this ticket to request that a "Refresh" button be provided for
 Neighborhood View -- to delete existing icons for resources which can NOT
 be currently communicated with.

 ----
 ----
 I am attaching three system dumps, in reverse time order:

 The 19.20 dump is after I deleted 'msh0' from the rules.d network entry
 (in an effort to automatically disable 'msh0'), then booted.  Network
 manager redefined 'msh0' anyway.  Took system dump.
 [By the way -- substantially later, an Access Point icon *did* show up in
 Neighborhood View -- so this was not an instance of the problem -- but
 after booting it was not evident what would occur.]

 The 19.19 dump was an experiment at booting with libertas tracing, then
 taking a system dump.

 The 19.16 dump was from my initial reaction to finding 'eth0' not defined.
 I turned on libertas tracing, then issued various combinations of commands
 to turn hardware off/on, turn service off/on, turn the Network Manager
 off/on, turn the mesh off/on.
 While there is no pattern to regard to which action followed which, there
 may be a clue (to the missing 'eth0') in the traces resulting from the
 individual actions.

  [[BR]]
 It may be that there is a hardware problem with the XO-1 with the randomly
 disappearing 'eth0' (but 'msh0' not disappearing).  Even then,
 Neighborhood View SHOULD inform the user when that happens.

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