Despite Maemo is based on Debian, not all concepts have been adopted: While Debian uses the file "/etc/network/interfaces" to store the network interface configuration profiles along with the parameters used to select a distinctive configuration (see here), the Maemo platform employs a graphic selection of the connectivity to use.
The configuration is not stored in traditional config files beneath "/etc/", and does not use shell scripts for initialization. Therefore, it is not possible to hook into network configration like it can be done in conventional Debian systems. Since my university requires the use of vpnc, this is kind of uncomfortable.
But there is hope: Although the graphical wizard does not trigger shell scripts, it does inform the system about the connectivity status by emitting signals via DBUS.
Receiving DBUS broadcasts
DBUS is a system which is used on numerous occasions throughout Maemo and not limited to networking. DBUS, which is short for "Desktop Bus", provides an interface applications can register themselves at. Other programs can then emit signals that will be received by those processes. There a two seperats busses: On user or session specific, which can be used by processes for interprocess communication, and a global system bus, which transports messages regarding changed hardware or other events concerning the computer system as a whole.
Establishing a network connection is such an event: The network wizard triggers messages that inform other listening processes about the change. The program
dbus-monitor can be used to investigate and debug those broadcasts; To make the program listen on the global system bus, issue the following command:
~ $ dbus-monitor --system signal if=org.freedesktop.DBus; mtd=ServiceAcquired; snd=org.freedesktop.DBus; dtl=:1.55 string::1.55
If you establish a new WLAN connection, several messages are passed over the bus:
signal if=com.nokia.icd; mtd=status_changed; snd=:1.14; dtl=n/a string:Foonet string:WLAN_INFRA string:IDLE
As you can see, DBUS messages carry some payload with them. This message originating from the interface "com.nokia.icd" ("icd" probably means "internet connection daemon") informs us about a status change concerning the network connection labeled "Foonet", which is a WLAN_INFRA connection (WLAN with access points), and is currently idle.
signal if=com.nokia.icd; mtd=status_changed; snd=:1.14; dtl=n/a string:Foonet string:WLAN_INFRA string:CONNECTING
We are now trying to establish the selected connection as reported by DBUS.
signal if=com.nokia.wlancond.signal; mtd=connected; snd=:1.16; dtl=n/a string:wlan0 array[ byte:0 byte:6 byte:37 byte:232 byte:115 byte:138 ] int32:32 signal if=com.nokia.icd; mtd=status_changed; snd=:1.14; dtl=n/a string:Foonet string:WLAN_INFRA string:CONNECTED
According to the last signal, we were successfull in our attempt to connect to the network.
Additionally to the messages listed above, playing the system in offline mode propagates the following message:
signal if=com.nokia.mce.signal; mtd=sig_device_mode_ind; snd=:1.0; dtl=n/a string:flight
After returning the device from "flight mode", this is reverted by:
signal if=com.nokia.mce.signal; mtd=sig_device_mode_ind; snd=:1.0; dtl=n/a string:normal
There a plenty of signals travelling on the bus - In fact DBUS is even used to launch programs through the Nokia UI. But also many system events are accompanied by DBUS events:
Blanking the screen
After a few seconds of inactivity, the screen goes blank to conserve power, along with triggering the corresponding DBUS signals:
signal if=com.nokia.mce.signal; mtd=system_inactivity_ind; snd=:1.0; dtl=n/a boolean:true
signal if=com.nokia.mce.signal; mtd=system_inactivity_ind; snd=:1.0; dtl=n/a boolean:false
Sliding into the cover
If the Nokia 770 is pushed into the cover with the display visible, the following event is reported twice:
signal if=org.kernel.kevent; mtd=change; snd=:1.6; dtl=n/a
If however the device is closed by pushing the cover into its protective position, more action takes place:
signal if=com.nokia.ke_recv.shell_on; mtd=shell_on; snd=:1.19; dtl=n/a
signal if=com.nokia.ke_recv.shell_off; mtd=shell_off; snd=:1.19; dtl=n/a
These two signals are escorted by those related to the device shutting down the active network connection.
Pressing the "home" key
Of all hardware keys, the "home" seems to be the only one triggering a global DBUS signal:
signal if=com.nokia.mce.signal; mtd=sig_home_key_pressed_ind; snd=:1.0; dtl=n/a
Handling the MMC storage
DBUS is also responsible for managing your card slot. The lever holding the MMC-RS in place seems to include a switch, so DBUS can broadcast your intention to remove the card even before you do so; if you pull out the cover, DBUS already initiates the umount of the device:
signal if=org.kernel.kevent; mtd=umount; snd=:1.6; dtl=n/a
The real removal of the memory card then is reported by another event:
signal if=org.kernel.kevent; mtd=remove; snd=:1.6; dtl=n/a
Upon reinsertion, nothing happens until the lever is closed:
signal if=org.kernel.kevent; mtd=change; snd=:1.6; dtl=n/a signal if=org.kernel.kevent; mtd=add; snd=:1.6; dtl=n/a signal if=org.kernel.kevent; mtd=add; snd=:1.6; dtl=n/a signal if=org.kernel.kevent; mtd=add; snd=:1.6; dtl=n/a signal if=org.kernel.kevent; mtd=umount; snd=:1.6; dtl=n/a signal if=org.kernel.kevent; mtd=mount; snd=:1.6; dtl=n/a
Power supply information
Connecting the charger also triggers special DBUS events:
signal if=com.nokia.bme.signal; mtd=charger_connected; snd=:1.8; dtl=n/a signal if=com.nokia.bme.signal; mtd=charger_charging_on; snd=:1.8; dtl=n/a
Removal of the power supply also triggers a special signal:
signal if=com.nokia.bme.signal; mtd=charger_disconnected; snd=:1.8; dtl=n/a signal if=com.nokia.bme.signal; mtd=charger_charging_off; snd=:1.8; dtl=n/a
Many wireless networks require the use of a special VPN client to gain access to "The Real Thing": Just retrieving an address from the DHCP server will leave you without usable connectivity (VPNC for Maemo). However, since Maemo assumes that every WLAN connection leads to the big and shiny Internet, the DBUS signal indicating network access is fired as soon as a valid lease is received, so applications will run into timeouts after relying on the wrong information.
Although I have not found a solution for networks using static configuration, there is a possibility for WLANs using DHCP: Maemo utilizes the program "udhcpc" to query the configuration server. This client software employs several scripts in the directory
/etc/udhpc/that are triggered on setup and deconfiguration of the interface, an ideal location to hook into.
/etc/udhpc/default.scriptis called with one of the following parameters:
The maemo version of that scripts then just calls /etc/udhcpc/default.deconfig, default.bound, default.renew or default.nak, depending on the servers reaction (See the documentation for more information).
We also have to identify the network we are connecting to, since we do not want to start the VPN client on every occasion; If we could tap into DBUS, we cold use the network name to make this decision, however, this is not possible at the moment. We have to use the data that is supplied by udhcpc through environment variables. The most promising ones are $router or $domain, since they probably do not change often. To gain a list of all variables and their values, add the following line into the appropiate script:
set > /tmp/dhcp-vars.txt
You can now inspect the file /tmp/dhcp-vars.txt for useful values for identification, and add a hook to the script.
I have to use vpnc to gain access to my university wlan, so I added the following lines to default.renew:
if [ "$router" = "172.17.2.1 " ]; then /var/lib/install/usr/sbin/vpnc-connect /var/lib/install/etc/vpnc/ecampus.conf fi
Since VPNC has to be killed if the interface is shut down, I also added /var/lib/install/usr/sbin/vpnc-disconnect to default.deconfig. However, this script is executed too called, so VPNC has no chance to sign off properly; Connection from a different computer will be denied for some time, but reconnecting your Nokia 770 to the private network will work without trouble. You can circumvent this issue by manually signing off (just execute /var/lib/install/usr/sbin/vpnc-disconnect with your WiFi still running).
If everything works as planned, the VPN connection is established right before the dbus-send statement in default.renew propagates the available connectivity throughout the system.