#10532 NORM 10.1.3: Users disable networking in nm-applet, and Sugar does not re-enable it

[Zarro Boogs per Child]

#10532: Users disable networking in nm-applet, and Sugar does not re-enable it
-------------------------------------+--------------------------------------
           Reporter:  godiard        |       Owner:  godiard      
               Type:  defect         |      Status:  new          
           Priority:  normal         |   Milestone:  10.1.3       
          Component:  gnome-desktop  |     Version:  not specified
         Resolution:                 |    Keywords:               
        Next_action:  package        |    Verified:  0            
Deployment_affected:                 |   Blockedby:               
           Blocking:  10409          |  
-------------------------------------+--------------------------------------

Comment(by martin.langhoff):

 The cpsection patch is needed -- currently the action happens when you are
 in the CP, without restarting Sugar.

 In olpc-session: yes we _could_ re-rfkill if the file is in place so
 Sugar-Gnome-Sugar yo-yo users get rfkill on both. This would fix an
 inconsistency no user will ever spot so we'd only be satisfying our own
 OCD :-)

 Now, please, think the scenarios through. Various additional
 inconsistencies remain. Follows a non-comprehensive list:

  * In 'pristine state' (no .rfkill_block_wifi in place, fresh boot), boot
 into Gnome, disable networking and/or Wireless, go to Sugar. wlan will
 stay down but no rfkill will take place. Oops.
  * In 'pristine state', boot into Sugar, disable radio. Reboot -- rfkill
 persists (good!). Switch to Gnome - enable network + wlan. Reboot -- NM
 cannot make "wlan enabled" persist. Oops.
  * In 'pristine state', boot into Gnome, disable network and/or wlan.
 Reboot. Does not persist. Oops!

 I am sure you can think a few reasonable use cases that act weird. It is
 all over the place.

 As I've said, without NM handling this directly, we are in a world of pain
 with this.

 Now -- this fix is merely to ameliorate the most user-visible aspect of
 it, that has been reported repeatedly.

 It is not the right fix -- which belongs in NM (and associated toolchain).

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