#7415 HIGH 8.2.0 (: Neighborhood view shows my AP twice

[Zarro Boogs per Child]

#7415: Neighborhood view shows my AP twice
----------------------+-----------------------------------------------------
   Reporter:  morgs   |       Owner:  dsd                              
       Type:  defect  |      Status:  new                              
   Priority:  high    |   Milestone:  8.2.0 (was Update.2)             
  Component:  sugar   |     Version:  Development build as of this date
 Resolution:          |    Keywords:  blocks:8.2.0                     
Next_action:  review  |    Verified:  0                                
  Blockedby:          |    Blocking:                                   
----------------------+-----------------------------------------------------
Changes (by dsd):

 * cc: erikg, dcbw (added)
  * next_action:  diagnose => review
  * component:  network manager => sugar


Comment:

 This is a race. Under normal circumstances, here is what happens inside
 the Device class (src/hardware/nmclient.py):

  1. __init__ asynchronously fires off a getProperties request over dbus
  1. Some time later, the getProperties request completes and
 _update_reply_cb is called with the results
  1. _update_reply_cb calls _update_networks which unconditionally creates
 Network objects for all networks that were returned

 In the problematic case that we see here, the following happens:

  1. __init__ asynchronously fires off a getProperties request over dbus
  1. '''NetworkManager generates NetworkAppeared messages for some
 networks, causing network_appeared() to be invoked and create a
 corresponding Network object'''
  1. Some time later, the getProperties request completes and
 _update_reply_cb is called with the results
  1. _update_reply_cb calls _update_networks which unconditionally creates
 Network objects for all networks that were returned

 So, we end up with the a Network object for the same WLAN being created in
 steps 2 and 4.

 We are not really sure why NetworkManager generates NetworkAppeared
 messages at this early stage. Does it always generate NetworkAppeared
 messages for all networks that are listed in the config file? Does it see
 a hidden network and assume that it corresponds to an entry in the config
 file? Given that we soon want to upgrade to NM-0.7 (which will shake up
 all this code anyway), we don't think it's worth investigating. The NM-0.6
 source code did not offer any immediately obvious answers.

 I see 2 easy ways of fixing this, patches attached:
  1. 0001-Avoid-network_appeared-race.patch: Ignore all NetworkAppeared
 messages until we've finished initializing
  1. 0001-Avoid-adding-already-appeared-networks-twice.patch: In
 _update_networks(), check that we didn't already create the Network
 earlier

 I can't decide which one I like best. Possibly (1), except I'm not 100%
 sure on the assumption I detail in the comments.

 Just to clarify, these patches are either-or: pick one or the other, not
 both. I tested both separately, both independently solve the bug.

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