Using Bodhi on My Chromebook: Network, Suspend

Introduction

In previous posts, I have discussed installing Bodhi on my Samsung (ARM) Chromebook and updating it to support Chromium and Flash, plus controlling the brightness via the brightness keys on the keyboard. In this post, I will discuss (wireless) network configuration/management and also suspend on lid close.

Network

From my investigation, I found 3 main candidates for network configuration and management for Bodhi. Most likely there are others, but these were the ones I saw being discussed and used (by different people).  The choices I found were:

1. EConnMan: This is the EFL (Enlightenment) user interface for ConnMan.
2. Network Manager: This uses GNOME and is the network configuration/management tool that comes by default with Ubuntu.
3. WICD: This is a lightweight python based wireless/wired network manager.

At first glance, given that EConnMan is EFL based and given my desire to use Enlightenment modules where feasible, this would appear to be my first choice. However, in reading the Bodhi forums, it seems that users were being dissuaded from using EConnMan, at least when they encountered problems. The alternative suggested was Network Manager.

For a while I tried using Network Manager. I have used Network Manager for years on my Ubuntu machines, and in fact still do.  It is probably the most functional and most widely used solution in Ubuntu, and supports things such as mobile broadband.  It is somewhat heavy in terms of resources and it uses GNOME. Considering I am running Bodhi on a Chromebook with limited memory and disk space, (and using Enlightenment, not GNOME) I want lightweight solutions where feasible.  Additionally, although I got Network Manager to work, I had quite a few issues configuring the wireless security.  The problem may not have been Network Manager itself (and its accompanying nm-applet) but an issue using the keyring for storing passwords. 

Basically, the problem I encountered was that when I was queried (by nm-applet) to enter the password for my wireless router, it always prompted me again. When I invoked nm-applet from within a terminal window, I could see (based on messages printed out) that it could not find the password in the keyring and thus was prompting for it. Although the ~/.gnome2/keyrings directory existed, nothing was written there. I tried starting various keyring programs at start-up, but still did not resolve the issue. Note that I had already configured the policy kit for Network Manager as described here (which did result in the appearance of the dialog box where I was asked to enter the password). I should point out that I have not had keyring issues on Ubuntu in the recent past and it may well be that had I been using Bodhi on an x86 or x86_64 machine, I would not have had an issue. It is important to remember that while Bodhi is based on Ubuntu for x86 and x86_64, for ARM it is based solely on debian.  This may (or may not) be partially responsible for the issues I had with the keyring.

The only way I was able to enter the password for wireless access points in Network Manager was to use the network connections editor application, nm-connection-editor. Using this I was able to store the password in Network Manager configuration files, which does not use the keyring.  While this worked, it was not ideal and for this reason, plus the fact that Network Manager is more resource intensive (and is GNOME based), I decided to try WICD.

To try WICD, I needed to turn off Network Manager. I did not want to uninstall it initially (although I may later). To turn off the Network Manager daemon I executed:

sudo insserv -r network-manager

That way if I wanted it started in the future I could use

sudo insserv network-manager

to have it automatically started at start-up.

I also had to turn off Network in the list of Enlightenment start-up apps.  The start-up apps are reached via  the main Bodhi menu at Settings->All->Apps->Startup Applications.

Since I had previously installed and then disabled WICD, I needed to have its daemon started automatically at start-up. I did this with:

sudo insserv wicd

I also went into the Bodhi menu to Startup Applications and turned on "Wicd Network Manager Tray".  Based on some documentation I read, I also added my user ID to the "users" group. I had previously added it to the "netdev" group.  I don't know which group membership, if either, is required. Update 11/28/2013: Looking at /etc/dbus-1/system.d/wicd.conf I see on my machine that the group you need to be in is "netdev".

After restarting, the WICD gadget appeared in the tray and I was able to click on it and configure wireless networks. I should also point out that I prefer the look of the WICD tray gadget versus the one from Network Manager (nm-applet). The one from Network Manager seems too big. Clearly this is a personal preference.

One other thing to note is that both Network Manager and WICD install pm-utils scripts for handling suspend/resume via pm-utils.  This will be relevant in the next section.

Lid Close and Suspend

Although I have been using Linux for well over 10 years, I have been hesitant to use suspend/resume.  First, Linux typically boots up somewhat quickly (typically 30 seconds or so) as opposed to some Windows machines which took minutes. Additionally, I am aware of people having issues with machines they continually suspended and resumed, that were cleared up after a reboot.  However, despite the fact that Bodhi on my Chromebook boots in about 10 seconds, I decided to play with suspend/resume anyway, as I don't expect to have numerous programs running simultaneously and will thus hopefully not run into many problems.

Most people seem to have their laptops suspend when they close the lid, so I decided to see if I could get that configured easily.  To support detecting and handling lid events, I needed to use something like ACPI.  Although I was told ACPI did not work well on ARM, I did find some information here  (see Advanced tab) about it being used on Samsung Chromebooks for handling suspend on lid close. I installed the acpid package, which is the ACPI daemon.  Note that I had previously tried to install acpi-support in addition to acpid, but was unsuccessful (for ARM architecture--others should be OK). The acpi-support package depends on acpi-fakeykey which was not available. At one point I even tried compiling acpi-fakekey and created a package for it (for ARM). However, the actual code (at run-time) depends on uinput (a kernel module), which is something that was not available in my ARM kernel.

Despite not being able to install acpi-support, which provides many helpful scripts for use with ACPI, I was able to create the event handler and script I needed.  I found useful information on ACPI events here. First I went into /etc/acpi/events and added (as root) a file named lid with the following contents:

event=button/lid
action=/etc/acpi/lid.sh %e

The first line tells it the action type, and the second gives the path to an executable (script in this case) to execute, passing the event string. I added /etc/acpi/lid.sh with the following contents:

#!/bin/bash
case $3 in
  close)
     pm-suspend
     ;;
  *)
     ;;
esac

After making these changes and rebooting, I was able to suspend on lid close.

Note that the event string passed into the script for lid close is:

button/lid LID close

and for lid open is:

button/lid LID open

This is why the script is looking at the third argument.

One thing I mentioned previously was that both Network Manager and WICD provide scripts for handling suspend and resume events. You can find these scripts in /usr/lib/pm-utils/sleep.d.  The scripts are 55NetworkManager and 55wicd respectively.  Upon resume from suspend, WICD did start up again and connect fairly quickly.