Opened 4 years ago

Closed 4 years ago

#10532 closed defect (fixed)

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

Reported by: godiard Owned by: godiard
Priority: normal Milestone: 10.1.3
Component: gnome-desktop Version: not specified
Keywords: Cc: martin.langhoff, dsd, sridhar
Blocked By: Blocking: #10409
Deployments affected: Action Needed: no action
Verified: no

Description

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

Attachments (8)

cpsection-network-model.patch (2.1 KB) - added by martin.langhoff 4 years ago.
olpc-session.patch (725 bytes) - added by godiard 4 years ago.
cpsection_network_model.py.patch (3.1 KB) - added by godiard 4 years ago.
0001-OLPC-10532-Users-disable-networking-in-nm-applet.patch (4.5 KB) - added by godiard 4 years ago.
new.patch (3.4 KB) - added by erikos 4 years ago.
cleanup
0001-OLPC-10532-Users-disable-networking-in-nm-applet-V2.patch (4.4 KB) - added by godiard 4 years ago.
0001-olpc-session-disable-rfkill-but-keep-wlan-down-for.patch (1.7 KB) - added by martin.langhoff 4 years ago.
v3 -- for dsd' s master and v1.0 branches
0001-olpc-session-disable-rfkill-but-keep-wlan-down-for.2.patch (1.7 KB) - added by martin.langhoff 4 years ago.
v3 -- for dsd' s master and v1.0 branches

Download all attachments as: .zip

Change History (42)

comment:1 Changed 4 years ago by 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.

comment:2 Changed 4 years ago by martin.langhoff

  • Component changed from not assigned to gnome-desktop
  • Milestone changed from Not Triaged to 10.1.3
  • Owner set to martin.langhoff

comment:3 Changed 4 years ago by martin.langhoff

  • Cc martin.langhoff added
  • Owner changed from martin.langhoff to godiard

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.

Changed 4 years ago by martin.langhoff

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by martin.langhoff

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

comment:6 Changed 4 years ago by 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).

comment:7 Changed 4 years ago by 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

comment:8 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by martin.langhoff

rfkill is confirmed to NOT have regulatory reasons.

comment:10 Changed 4 years ago by 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".

comment:11 Changed 4 years ago by 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.

Changed 4 years ago by godiard

comment:12 follow-up: Changed 4 years ago by godiard

Added patch to olpc-session using dbus-send

Changed 4 years ago by godiard

comment:13 Changed 4 years ago by 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

comment:14 in reply to: ↑ 12 Changed 4 years ago by 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.

comment:15 Changed 4 years ago by 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.

comment:16 Changed 4 years ago by martin.langhoff

  • Action Needed changed from never set to add to build

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

comment:17 Changed 4 years ago by martin.langhoff

  • Action Needed changed from add to build to package

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

comment:18 Changed 4 years ago by 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)

comment:19 Changed 4 years ago 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).

comment:20 Changed 4 years ago by 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.

Changed 4 years ago by erikos

cleanup

comment:21 Changed 4 years ago by erikos

  • Action Needed changed from package to test in build

Will be in the currently building 359.

comment:22 Changed 4 years ago by 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)

comment:23 Changed 4 years ago by dsd

  • Action Needed changed from test in build to code

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?

comment:24 Changed 4 years ago by dsd

  • Cc dsd added

comment:25 Changed 4 years ago by dsd

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

Changed 4 years ago by martin.langhoff

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

Changed 4 years ago by martin.langhoff

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

comment:26 Changed 4 years ago by 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.

comment:27 Changed 4 years ago by martin.langhoff

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

comment:28 follow-up: Changed 4 years ago by 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.)

comment:29 in reply to: ↑ 28 Changed 4 years ago by 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.

comment:30 Changed 4 years ago by 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.

comment:31 Changed 4 years ago by martin.langhoff

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

dsd, thanks!

comment:32 Changed 4 years ago by erikos

  • Action Needed changed from code to test in build

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

comment:33 Changed 4 years ago by sridhar

  • Cc sridhar added

comment:34 Changed 4 years ago by greenfeld

  • Action Needed changed from test in build to no action
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.