Airplane mode for wireless.

[jg]

We need a user interface (and underlying software support) for disabling wireless on airplanes.

In principle, it could be as simple as telling people to use the console to issue a command "/sbin/ifdown eth0", or something more elegant. It should not be too easy; we want the children leaving their wireless on.

This is a bug to focus discussion on this issue, rather than necessarily causing any actual programming to be requested; we just need to make up our collective mind how to deal with this problem.

[gnu]

The user interface will need to be faster and easier than removing the battery -- otherwise people will just do that. (Either voluntarily, or on demand of airplane personnel.) The transmitter will also need to stay off, even if you resume or boot your OLPC to do some work on the plane. It should take an explicit action to turn it back on again. This argues for having the control and the status indicator wherever the usual wireless indication is (currently on the home screen).

Disabling the wireless should also reduce the power consumption (turn off power to the chips). I don't think it currently does that.

[kimquirk]

Moved to next SW release, Trial-2.

[Eben]

I don't think that airplane mode is really a concern for the demographic we're targeting. As such, I don't really want to - at least at this point in time - worry about neatly integrating this into the UI.

I think that a script run from the command line is more than simple enough for any who are actually going to need to do it. The only change I might suggest from the UI side is to have Sugar check for some flag set by said script and place a nice icon in the Home view which indicates the airplane mode status. Jim, could you reassign as appropriate; feel free to reassign to me if an icon is indeed wanted (or perhaps when it's needed) for this purpose.

[jg]

The other issue, not yet obvious, is whether we can get the wireless firmware to have as low power consumption and therefore the expected lifetime. Michailis believes we can do much better than we do today (and the power when associated to a conventional access point is indeed within spitting distance of the power levels we'd hoped for).

We now know how to turn the dcon off, so we know the wireless power consumption will be just the wireless power consumption.

But if power consumption stays at current levels, we'll probably need a suspend with wireless off state.

Since we don't yet really know the wireless firmware power consumption situation for sure, particularly for early production machines before the wireless refresh, I'm punting this to later.

[jg]

Candidate for configuration screen we've talked about...

[danw]

Replying to Eben:

I don't think that airplane mode is really a concern for the demographic we're targeting.

Give 1 Get 1 probably changes that.

[jg]

Yeah, I believe we have to get a simple control panel going...

This should be on that list.

[tomeu]

Last I heard about the control panel, I understood that for 1.0 we are going to go with some simple scripts. No UI for the control panel. Am I right?

[jg]

We were/are hoping for a simple UI to hook up to said scripts of the control panel.

Elegance of the control panel not required. We don't need anything as fancy as Eben's full control panel design for the completed panel; just something servicable for what we need to set.

Sorry for any mis-understanding.

[erikos]

For the airplane mode I use the sleep and wake methods of the NM to set the devices eth0 and the mesh one down. For the radio power part, driver patches will be required to turn off the radio power . Dan might be able to work on that so I reassign to him.

more info on the panel itself: http://wiki.laptop.org/go/Sugar_Control_Panel

[dcbw]

Note that in lieu of having the driver turn the radio off when all interfaces are down, you can use:

iwconfig eth0 txpower off

and to turn it back on,

iwconfig eth0 txpower 0

These require root privs as all low-level wireless commands that touch the radio do.

[jg]

I'll consider this for Update.1 if it is as trivial fix.

[gnu]

See #5146 for similar concerns about shutting off Mesh in non-airplane environments.

[Quozl]

Tested build 650, iwconfig eth0 txpower off and ifdown eth0 do not work, NetworkManager seems to put things back on.

What does work for this build is hiding the usb8388.bin firmware file in another name, and rebooting:

su -
cd /lib/firmware && mv usb8388.bin flying && reboot

and to put it back ...

su -
cd /lib/firmware && mv flying usb8388.bin && reboot

[jg]

I thought we got a sugar-control-panel command for this? Simon?

[jg]

sugar-control-panel -s radio off (hit 'Enter')

sugar-control-panel -s radio on

[Kityoko]

Replying to jg:

sugar-control-panel -s radio off (hit 'Enter') sugar-control-panel -s radio on

I tried using this command on build 650 and it didn't appear to work. The network manager brought back an IP after a few minutes.

[carrano]

I confirm that it is not working anymore. Not in 653 nor in joyride 1477.

It reports incorrectly (on when it is off, and vice versa) and also fails to set up.

I am attaching a shell.log which reflects the following sequence.

XO booted -> sugar-control-panel returns on -- OK; then ...

 $ sugar-control-panel -s radio off 
 $ sugar-control-panel -g radio
 off
 $ sugar-control-panel -s radio on 
 $ sugar-control-panel -g radio
 on
 $ sugar-control-panel -s radio off 
 $ sugar-control-panel -g radio
 on

I`ve seen other cases where it reports off immediately after a boot. Let me know if other logs may help.

[carrano]

'sugar-control-panel -s radio off' fails the second time

[erikos]

The control panel uses the sleep and wake methods of the NM to set the devices eth0 and the mesh one down. The power off then is part of the driver as i understand (i do not this functionality is there yet). We could use iwconfig to turn radiation off but from Quozl's note I gather that the iwconfig txpower off command do not work since the NetworkManager put back things.

So i guess this might be an issue in the NetworkManager?

[erikos]

After a few tests i think we must do both (let NM fall asleep and use txpower off) to be sure the radio is completely turned off since with:

   iwconfig eth0 txpower off

only NM seems to still try to get a connection back.

Attached patch will do both when the radio off command is invoked.

[erikos]

NM asleep and iwconfig txpower off

[erikos]

This is the detailed description of the test (joyride-1525):

a) use NM sleep/wake only
 - invoking the sleep command
 - NM goes to state 1
 - the wireless aquisition light is still on
 - the wireless activity light (.) is flashing from time to time
 - the NM logs do not change
 - iwconfig is showing txpower 13 dBm
 - the device is down fine, no ping etc
 - invoking the wake command
 - it tries to access the 3 mesh devices and finally reconnect to the AP

b) use 'iwconfig eth0 txpower off'
 - invoke 'iwconfig eth0 txpower off'
 - the wireless aquisition light is off
 - the wireless activity light (.) is off
 - iwconfig is showing txpower off
 - after a while (1-2 secs) NM is trying to reconnect
 - it finally connects to mesh network 1
 - the wireless aquisition light is on
 - the wireless activity light (.) is off
 - NM is not in state 1 (obviously)

c) use a and b
 - the wireless aquisition light is off
 - the wireless activity light (.) is off
 - it stays like that 

[erikos]

Actually we reviewed the solution a bit. Dan built a new NM which will turn up soon in joyride http://koji.fedoraproject.org/koji/buildinfo?buildID=32000. We use the setWirelessEnabled() dbus call now to turn TX power on and off and have no need to call iwconfig anymore to fulfill this task.

Attached patch will reflect the changes in the s.c.p

[erikos]

reworked patch that uses the new setEnabledWirless in NM

[ssb22]

On build 656 firmware Q2D07 I tried

sugar-control-panel -s radio off

but it did not turn the radio off: the signal light continued to flash from time to time, a nearby Windows Vista user complained that the XO was somehow sending him messages asking if he wanted to join the network (?? but I couldn't look at his laptop to find out what was happening), and Sugar sometimes briefly "got stuck" while the signal light was flashing.

The only thing that seems to work at the moment is to move /lib/firmware/usb8388.bin elsewhere and reboot (as described earlier on this thread). The advice on http://wiki.laptop.org/go/Support_FAQ etc may need to be updated before we cause any plane crashes.

[erikos]

Needed packages: NetworkManager-0.6.5-0.8.svn3246.olpc2 sugar-0.75.10-1.olpc2

The fix can be tested in >= joyride-1550. I tested it as working for a) connected to an AP and b) connected to mesh. One nitpick i encountered is that when you invoke the 'radio off' command (when you are connected to an AP or mesh, white border around icon) the 'i' and '(.)' lights both will be turned off. When NM still scans through the devices (e.g. when reconnecting after you have invoked 'radio on') only the '(.)' light will be turned off - the 'i' light is still on.

NOTE: Build 656 does not contain this patch.

[erikos]

Tested as working fine in 686.

[erikos]

I am happy with the result someone else might want to verify.

[gnu]

The new Sugar GUI should enable airplane users to turn off both the mesh and the regular WiFi in the 8.2.0 release. There is also an "aggressive suspend" mode that turns off the WiFi chip and USB ports. This fix is a big improvement over the open-a-terminal, type-commands form of airplane mode.