Users disable networking in nm-applet, and Sugar does not re-enable it

[godiard]

This ticket depends on #10409 "GNOME Breakability Issues -- options and actions breaking Gnome and Sugar"

[godiard]

Install package cnetworkmanager

yum install cnetworkmanager

To enable the network do:

cnetworkmanager -o on

We need do this in /usr/bin/olpc-switch-to-sugar or copy the python code.

[martin.langhoff]

Patch to sugar's cpsection/network/model.py attached.

With this patch, we

• Consider nm wireless and rfkill state to populate the checkbox.
• When enabling and disabling we perform the equivalent actions to what nm-applet does if you enable/disable both 'networking' and 'wireless networking'.

Discussion - NM dbus API: The dbus api documentation is inaccurate. It talks about the Sleep(bool) method call; but nm-applet uses Enable(bool). This is true both on NM0.7 (F11) and NM0.8 (F14). So this patch uses Enable() to match nm-applet.

Discussion - rfkill: when we bring the network down, we are still applying rfkill. This confounds the GNOME side as nm-applet + NM will not report the wlan card if it's rfkilled. I am devising a workaround, but I wonder why we rfkill.

[martin.langhoff]

Note: the patch needs review and testing for the cases where on the GNOME side (or via cnetworkmanager) only Wireless or Networking has been disabled. In other words -- it may need to read each setting before setting it.

[martin.langhoff]

Confirmed with pgf - the rfkill we have is for battery-saving purposes.

[martin.langhoff]

I think we can live with "If you disabled networking, re-enable it from Sugar". So I would just tidy up and test the patch we have, controlling the Sugar side.

Otherwise, we can fiddle with the wlan/rfkill state from olpc-session (and perhaps /etc/init.d/olpc-configure).

[martin.langhoff]

What we could do in olpc-session is something along the lines of

   # in the non-sugar-desktop block
   if [ -e /home/olpc/.rfkillfile ]; then
       # unblock via rfkill but make sure we tell nm to keep it off
       rfkill unblock wifi
       # we shouldn't actually use cnetworkmanager
       # use dbus-send instead
       cnetworkmanager -w 0
   fi

[greenfeld]

The rfkill might also have some regulatory basis, even if we do not require it to pass for our compliance testing.

For instance, we may not be allowed to even transmit anything, including AP probe frames, in an airplane or explosive/blasting area where cell phones also have to be turned off or in "Airplane mode". A hard rfkill transmit disable switch may be required for such a purpose.

[martin.langhoff]

rfkill is confirmed to NOT have regulatory reasons.

[pgf]

i don't think we should be quick to sacrifice between 500 to 800 mW (xo-1.5 vs. xo-1) simply because the user selected a non-sugar desktop. i turn off wireless because i know it will make my laptop run longer -- not because i particularly care about suppressing transmissions for "airplane mode".

[martin.langhoff]

We are not quick to sacrifice anything. We preserve those savings as long as the user is in Sugar.

We would preserve those savings if NM was able to handle setting rfkill status. It's not, there are no hooks we can use for this case, and fixing NM is way out of scope for the 10.1.3 release which should be closing right now.

[godiard]

Added patch to olpc-session using dbus-send

[godiard]

The new patch resolve a issue getting the initial state , and another when in gnome the user disable only wireless but not network manager

[pgf]

Replying to godiard:

Added patch to olpc-session using dbus-send

the comment says "unblock wifi", which is misleading.

also, what happens if the user switches from sugar to gnome and then back? seems to me that the rfkill state will have been lost.

[martin.langhoff]

what happens if the user switches from sugar to gnome and then back?

Correct -- slightly higher power consumption. A reboot into Sugar will set things straight.

It's a minor issue compared with end users being unable to re-enable the network.

It is expected that with these patches we still have some inconsistencies left over because the handling of rfkill is different on the different desktop environments.

If you think it through, the only way to really resolve the inconsistencies is to have NM able to handle manage the rfkill status.

[martin.langhoff]

The olpc-session patch is in an olpc-utils rpm in my public_rpms/f11 dir .

[martin.langhoff]

Actually - re-setting to package as the model.py patch needs to get into a sugar rpm. Simon?

[pgf]

i think that if /home/olpc/.rfkill_block_wifi exists, then wifi should be rfkill blocked. if that can't happen in gnome, so be it, but it should always be the case in sugar. otherwise, change the name of the file to "/home/olpc/.wifi_is_off_but_we_dont_know_why". (only half kidding :-)

but really, can't olpc-session do a proper rfkill when sugar starts? this would make the cpsection patch unnecessary. (i think)

[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).

[pgf]

"Uncle!" okay. ship it. i don't like it, but i see the point. we do need to actively persue and encourage a proper NM fix.

[erikos]

cleanup

[erikos]

Will be in the currently building 359.

[godiard]

|TestCase| You can enable or disable network in Gnome or Sugar and switch to the other environment and the network must be usable. Known issues: * If you disable network in Sugar, rfkill is used. Changing to Gnome rfkill is not used, because NetworkManager can't manage it. * If you disable network in Gnome and change to Sugar, the adhoc-network icons are present, but wireless is disabled (OLPC #10543) * Enable/disable network in Sugar, using checkbox in control panel, takes a little time, but there are not visual feedback. (OLPC #10546)

[dsd]

This needs to go into master before going into 10.1.3 final. Looks OK but it introduces a bug:

1. Disable radio in sugar for power saving purposes
2. Switch to GNOME
3. Switch back to Sugar

--> wifi board is now powered up and sucking power

any chance of an updated patch?

[dsd]

also, to maintain RF silence, you should disable wireless in NM before unblocking rfkill

[martin.langhoff]

v3 -- for dsd' s master and v1.0 branches

[martin.langhoff]

v3 -- for dsd' s master and v1.0 branches

[martin.langhoff]

dsd, pgf, the v3 patch handles your request that we rkfill again on switched from Gnome to Sugar.

The same patch applies to master and v1.0 branches from dsd's repo.

[martin.langhoff]

Note -- I accidentally hit submit twice. Both v3 attachments are the same. Oops.

[pgf]

i'm okay with this. i'd be happier if we could give gnome the ability to turn rfkill on/off (a new applet? modified nmapplet?), but i understand time is short. i have a slightly older release on my 1.5 machine (os850) and the nmapplet is broken even in the absence of rfkill -- if i uncheck "enable wireless", there's no way to get it back, even after a reboot. (i'm guessing switching to sugar and back with the most recent patches might fix this.)

[erikos]

Replying to pgf:

i'm okay with this. i'd be happier if we could give gnome the ability to turn rfkill on/off (a new applet? modified nmapplet?), but i understand time is short.

Yes, this is a bit out of scope.

i have a slightly older release on my 1.5 machine (os850) and the nmapplet is broken even in the absence of rfkill -- if i uncheck "enable wireless", there's no way to get it back, even after a reboot. (i'm guessing switching to sugar and back with the most recent patches might fix this.)

Hmm, I can not reproduce. When I uncheck the "enable wireless" in GNOME, I can enable it again. No reboot needed. Did test on 360.

[dsd]

thanks, applied.

Couldnt reproduce pgf's issue, I suspect the bug has not been fixed since 850 but we'll need a more detailed test procedure.

[martin.langhoff]

pgf, agreed -- opened #10575 so we don't forget

dsd, thanks!

[erikos]

Please test in 361 that this is not true anymore: #comment:23

[greenfeld]

Disabling the network (radio & networking overall) in GNOME and restarting it in Sugar appears to be working in 10.1.3 os860 for both XO-1 & XO-1.5 systems.