Maemo Connectivity Guide

Overview

This guide has been reviewed for maemo 4.0. This section briefly presents the clients and APIs of the maemo connectivity subsystem. Details on interfaces of connectivity are presented in the subsequent sections.

The maemo connectivity subsystem is implemented by using known Linux conventions. It resides in the user mode area of Linux, and relies on the Linux kernel through standard C libraries. Wireless LAN is the main channel to the Internet, but dial-up connections through cellular networks are also supported. The only medium to the phone is Bluetooth. The Bluetooth software of maemo is based on BlueZ, which is known as the de-facto implementation of Bluetooth for Linux. D-Bus is used for internal application level message exchange.

Even though the connectivity device drivers are closely related to this subsystem, they are considered to be outside of the scope.

Components of the maemo connectivity architecture:

Maemo connectivity UI - User Interface parts of the connectivity. This includes Connection manager, Control Panel applets and several different dialogs.

Maemo connectivity daemon (ICd) - LibConIC API works together with ICd, handling all Internet Access Points (IAPs). IC daemon handles both WLAN and Bluetooth connections.

OBEX wrapper - Interface to OBEX services. The primary target user of this library is the OBEX gnome-vfs module.

OpenOBEX - Open source implementation of the Object Exchange (OBEX) protocol. More information on OpenOBEX can be found from http://triq.net/obex/

BlueZ Bluetooth stack - The de-facto implementation of Bluetooth for Linux. More information on BlueZ can be found from http://www.bluez.org

BlueZ D-Bus API - BlueZ accepts commands via D-Bus.

WLAN connectivity daemon - The daemon controlling WLAN connections.

WLAN device driver - Device driver for Wireless LAN (IEEE 802.11g). Kernel driver is composed of two parts: a binary part (closed source) and an open source wrapper, binding the binary to the current Linux kernel.

Internet Access Points (IAP)

The central concept regarding Internet connections from maemo is the Internet Access Point (IAP). It represents a logical Internet (IP) connection, which will be defined by the user according to their needs. An IAP has a unique name. It defines the radio bearer (e.g. WLAN, CSD, GPRS) to be applied, and usually the data transfer speed, username, password, proxy server, and the corresponding access point in the Internet or the telephone number of the service provider's modem, among other characteristics.

Connectivity Subsystem

This section describes the system decomposition of the Connectivity subsystem. Maemo applications can open Internet connections by using the LibConIC API. The Internet Access subsystem will take care of the connection to the phone, if necessary, by using the services of the Phone Access subsystem. If an application needs to gain access to the phone's files, then the File selector will consult the Phone Access subsystem.

During the flight mode, the WLAN and Bluetooth radios must not be active. The Device System Management Entity (DSME) of maemo provides information about the transitions to and from the flight mode.

Phone and Internet connections are quite different by nature and behavior. The next sections will introduce these in more detail.

Phone Access

Phone Access is the subsystem handling connections to a mobile phone. It has a search utility for finding potential phones and inquiring the services they can offer. This is based on standard Bluetooth service discovery mechanism. Phone Access also keeps a record of phones having been connected to the device in GConf, and provides a list of them for the user to choose from. Phone Access relies on the Linux Bluetooth implementation called BlueZ. BlueZ offers the Berkeley socket interface to the HCI and to the L2CAP protocol for the user space applications.

In principle, any mobile phone supporting Bluetooth Service Discovery Protocol (SDP), Dial-up Networking profile (DUN) and File Transfer Profile (FTP) can be connected to maemo. However, there is variation especially in the level of file transfer services and OBEX in different mobile phones. Some products limit the access to the Inbox (Object Push), whereas more sophisticated ones make the Gallery and the memory card available. The recent products support the OBEX Capability request, which can be used to get more specific information about the file system on the phone.

Maemo connects to a phone on an on-demand basis, i.e. when an application requires a connection. As an example, when the Internet browser is about to open a URL, it will request the Phone Access to establish a connection to the phone. This makes Phone Access to bind an RFCOMM device to the requested service (in this case DUN) on the phone. In a similar fashion, the File Selector can set up a file transfer connection to the phone using another RFCOMM device. After binding to a service, the application in question can open the local RFCOMM device. Normal file selector access is performed with GnomeVFS layer to get transparent access to phone in the same way as internal flash and MMC are accessed.

The Bluetooth SIM Access (SAP) profile is also needed in maemo to perform WLAN authentication using the EAP-SIM authentication method. In this case, the EAP component will ask the BT sap component to get session keys from a GSM/UMTS phone.

Maemo Bluetooth also supports HID (keyboard) and OPP (printer) profiles.

Internet Access

The Internet Access subsystem manages connections to the Internet over both WLAN and cellular dial-up. It is also responsible for the configuration and management of Internet Access Points. The Internet Access provides applications with TCP/IP connections. They can be established with:

• WLAN connection to a wireless access point.
• Bluetooth connection through phone using Point-to-Point Protocol (PPP) and a cellular modem (in the phone).

In the latter case, AT commands are applied to establish a PPP link to the cellular modem and the connection to the Internet.

This section describes how the Internet Connectivity daemon works internally. The following subsections explain the behavior and the decomposition of this component in detail, also covering the interfaces that this component realizes.

Decomposition

When the ICd receives a request to activate or deactivate an IAP, ICd will activate the IAP or show an UI requesting the user to choose one, if no IAP has been selected as the default. Depending on the type of the IAP, ICd will activate or deactivate either a Bluetooth DUN or a WLAN interface.

ICd tracks the applications requesting IAPs by recording their D-Bus base service names. This allows ICd to detect situations where processes using an IAP have aborted or crashed. ICd also implements an idle timeout mechanism to shut down the active IAP, if no packets have been sent in a configurable amount of time.

Maemo version 3.0 introduced the automatic connection creation feature in the Internet Connectivity Daemon. In other words, the device will try to connect automatically to the saved IAPs, and keep connected as long as possible, unless the idle timeout is set. With this feature, applications like e-mail and RSS reader will always be up to date. The device will also be always ready for online usage, for example, incoming VoIP calls or IM chat. In former versions, the Internet connection was automatically closed when there were no more applications using it, or when the connection was idle for a given period of time defined by the configuration parameter idle timeout.

When not connected, the device scans for saved IAPs and tries to connect automatically, taking into account the value defined by the configuration parameter for search interval, which can be 5, 10, 30 or 60 minutes. All other values will be automatically mapped to "Never". This setup switches off the automatic connection feature. In this case, the device will behave just like the former versions: Connections will be created only when required by applications.

ICd is responsible for connection creation only, as it is the responsibility of each application to keep its data updated, and then providing the always-online feature.

While writing an application making use of the ICd system, the following points should be kept in mind:

• The application must always use the existing available connection.
• As it was done in former versions, if device is not connected but a connection is required by user interaction, the application must require connection creation using LibConIC API.
• The user should be kept aware of updates, making visible when the data was last updated.
• The application must register via LibConIC and listen to signals emitted by ICd (Connection Created, Lost and Changed), and react as follows:
  • Connection Created: Use the connection and update all data.
  • Connection Lost: Go to an idle state silently and wait until a new connection is created.
  • Connection Changed: Use the new connection.
• Automatic data updates must run in background and silently:
  • Alarming the user with unnecessary banners or dialogs should be avoided.
  • Usernames and passwords should be saved, so that automatic updates can be performed without prompts.
  • In this case, no failures are allowed to show error notification dialogs.
• The connectivity infrastructure takes care of error situations in a centralized way.

Automatic connection creation feature can also be switched off using flight mode (offline mode). While in this mode, the configuration parameter for allowing WLAN in flight mode is checked. Depending on the state of this configuration parameter, WLAN IAPs are either enabled or disabled in the flight mode. Also Bluetooth connections are normally disabled in the flight mode.

Bluetooth Dial-up Networking

ICd uses PPP to establish IP connectivity over Bluetooth DUN interfaces. If there already is a different IAP active using Bluetooth DUN, the old IAP is first deactivated. The IAP is activated according the following action sequence:

• The character device used by the Bluetooth DUN device is acquired from btcond. If the device is not available due to gateway not being present, exhaustion of simultaneous Bluetooth connections, or similar, ICd shows an error message to the user and aborts with a D-BUS error message.
• ICd starts PPP using the exec family of system calls. It directs PPP to use the acquired Bluetooth DUN device with the dial-up configuration parameters specified for the configured DUN IAP type. If PPP cannot get the connection established, ICd will show an error message to the user, and abort with a D-BUS error message. When the PPP connection is established, PPP-specific scripts will be run. These scripts will set dynamic IP connection related configuration entries, and send a state change D-BUS message to all the interested applications to indicate that the IAP has been established.

If the previously active IAP was not using Bluetooth DUN, it will be closed down after establishing the PPP connection.

A Bluetooth DUN is closed down by sending the PPP daemon a SIGINT or SIGTERM signal. This will terminate the PPP daemon, and remove all routing entries associated with the PPP dial-up interface. The PPP shutdown scripts will remove the dynamic IP connection related configuration entries, and send a state change D-BUS message announcing deactivation of the IAP. This is described below.

WLAN

When connecting to a WLAN, ICd needs to associate with the network, and enable EAP authentication and the DHCP client as needed. Independently of whether there is an IAP active using WLAN, the requested WLAN network will first be scanned to ensure that it is available. The current IAP will be deactivated, if the requested network is found and the current IAP is using WLAN. WLAN is activated according to the following procedure:

• If the network requires EAP authentication, the EAP authentication procedure is started. While performing the EAP authentication, the EAP software may show GUI dialogs relating to the EAP authentication procedure. When the EAP authentication has been completed, the EAP software will set security keys for the WLAN network, resulting in state change messages from wlancond. ICd will receive these messages but ignore them, and wait for the reply from EAP authentication instead. If the EAP authentication fails, ICd aborts with a D-Bus error message.
• After the EAP process has been started, ICd instructs wlancond to associate with the WLAN network. Any static security settings relating to pre-shared security keys are also supplied at this point. If a connection to the WLAN network cannot be established, ICd aborts with an error.
• As the DHCP client is a stand-alone program, it is started by using exec when the WLAN IAP requires dynamic IP address acquisition. When the DHCP client has obtained an IP address, it configures IP-related parameters, and sends a D-Bus signal to ICd. If the IP address lease cannot be obtained, ICd will timeout, stop the DHCP client and abort with a D-Bus error message.

Internet Connectivity API (in shorter form: Libconic) is an API for applications to manage internet connections on Maemo devices. It was introduced in the first IT OS 2007 release deprecating the old OSSO IC API (osso-ic-lib). OSSO IC API was conclusively removed in IT OS 2008 release. The interface documentation to libconic can be found at Internet Connectivity API

Unlike osso-ic-lib, Libconic is high level and stable object-oriented API. It can be used to

• Request internet connection
• Listen for internet connection status events
• Receive statistics of internet connection
• Get proxy settings for the current connection
• Get list of user saved connections (IAPs)

Application requirements

Applications have few requirements prior using the Libconic API. They are:

1. use non-blocking sockets
2. system D-BUS running
3. g_type_init() has to be called
4. no threading support in the Libconic API

If your application is a standard Hildon application, almost all of these requirements are already fulfilled. LibOSSO context initialization connects your application to both session and system D-BUS buses, g_type_init() is called as a part of gtk_init() and there is probably no extra threads used.

Non-blocking sockets

Blocking sockets cannot be used, because that would also block receiving of the Connectivity events. Use non-blocking sockets to receive the events properly. For example, GLib IO Channels with the G_IO_FLAG_NONBLOCK flag provide non-blocking way to use sockets.

With threads blocking sockets can be used, although Libconic API itself is not thread safe.

System D-BUS

Libconic API uses internally system D-BUS for delivering messages to the Connectivity components. Application needs to have normal D-BUS dispatch, watch and timeout monitoring running before the Libconic API can be used. If the GLib mainloop is used, this can be accomplished with dbus_connection_setup_with_g_main().

Please note that setting up LibOSSO context connects your application to required D-BUS.

GType

Libconic API is GObject-based. This means that to get API working, GLib's GType needs to be initialised properly. Use g_type_init() to do that.

No multiple threads

Libconic API is not thread-safe. If the applications have threads, use Libconic API only from the same context where GMainloop is running.

Libconic usage

Requesting for a connection

Libconic is asynchronous connection API, which heavily relies on GObject signals. Basically this means that GMainloop must be iterated in order to successful execution of connection requests. After your application has been correctly setup (please see previous section for some requirements), you can request for a connection with ConIcConnection object:

    gboolean success = FALSE;

    /* Create connection object */
    ConIcConnection *connection = con_ic_connection_new();

    /* Connect signal to receive connection events */
    g_signal_connect(G_OBJECT(connection), "connection-event", G_CALLBACK(my_connection_handler), NULL);

    /* Request connection and check for the result */
    success = con_ic_connection_connect(connection, CON_IC_CONNECT_FLAG_NONE);
    if (!success) g_warning("Request for connection failed");

At this point, your application does not yet have an internet connection. Successful return from con_ic_connection_connect() means only that request was successfully dispatched to the Internet Connectivity daemon. When the daemon has a connection ready, your application will receive an event (as an GObject signal) indicating that the device is connected. If the connection attempt fails, your application will receive a disconnected event with an error describing the reason for the failure.

Your connection handler (my_connection_handler() function registered in the previous snippet), could look like this:

static void my_connection_handler(ConIcConnection *connection,
                                  ConIcConnectionEvent *event,
                                  gpointer user_data)
{
    ConIcConnectionStatus status = con_ic_connection_event_get_status(event);
    ConIcConnectionError error;

    const gchar *iap_id = con_ic_event_get_iap_id(CON_IC_EVENT(event));
    const gchar *bearer = con_ic_event_get_bearer_type(CON_IC_EVENT(event));
    
    switch(status) {

        case CON_IC_STATUS_CONNECTED:
            g_debug("Hey, we are connected to IAP %s with bearer %s!", iap_id, bearer);
            break;

        case CON_IC_STATUS_DISCONNECTING:
            g_debug("We are disconnecting...");
            break;

        case CON_IC_STATUS_DISCONNECTED:
            g_debug("And we are disconnected. Let's see what went wrong...");
            error = con_ic_connection_event_get_error(event);

            switch(error) {

                case CON_IC_CONNECTION_ERROR_NONE:
                    g_debug("Libconic thinks there was nothing wrong.");
                    break;

                case CON_IC_CONNECTION_ERROR_INVALID_IAP:
                    g_debug("Invalid (non-existing?) IAP was requested.");
                    break;

                case CON_IC_CONNECTION_ERROR_CONNECTION_FAILED:
                    g_debug("Connection just failed.");
                    break;

                case CON_IC_CONNECTION_ERROR_USER_CANCELED:
                    g_debug("User canceled the connection attempt");
                    break;
            }
            break;

        default:
            g_debug("Unknown connection status received");
    }
}

Listening for connection events

Sometimes your application does not want to actively start connections, but it is still interested to know, when the device is online. It is possible to achieve this with Libconic "automatic events" feature, which is enabled with "automatic-connection-events" GObject property:

    /* Create connection object */
    ConIcConnection *connection = con_ic_connection_new();

    /* Connect signal to receive connection events */
    g_signal_connect(G_OBJECT(connection), "connection-event", G_CALLBACK(my_connection_handler), NULL);

    /* Set automatic events */
    g_object_set(G_OBJECT(Connection), "automatic-connection-events", TRUE, NULL);

When automatic events are turned on, the application will receive connected and disconnected events for all internet connection changes. In addition to this, the application will receive an event for the initial connection status. If the device is disconnected, ConIcConnectionEvent with status CON_IC_STATUS_DISCONNECTED will be emitted. This event will have NULL IAP ID and bearer as there is no IAP getting disconnected, but event just indicates that the device is offline.

Please note that you have to again iterate the main loop in order to receive the event. If you insist having the connection status information synchronously, you can always iterate the main loop yourself:

static void connection_info(ConIcConnection *connection,
                            ConIcConnectionEvent *event,
                            gpointer user_data)
{
    ConIcConnectionStatus status = con_ic_connection_event_get_status(event);
    ConIcConnectionStatus *status_ptr = (ConIcConnectionStatus*)user_data;
    *status_ptr = status;
}

...

    /* Create connection object and set on automatic events (see previous snippet) ... */
    static ConIcConnectionStatus status = 0xFFFF;
    ConIcConnection *connection = con_ic_connection_new();
    g_signal_connect(G_OBJECT(connection), "connection-event", G_CALLBACK(connection_info), &status);
    g_object_set(G_OBJECT(Connection), "automatic-connection-events", TRUE, NULL);

    /* Iterate main loop for the first connection event */
    while (status == 0xFFFF) g_main_context_iteration(NULL, TRUE);
    
    if (status == CON_IC_STATUS_CONNECTED) 
        g_debug("We are connected!");
    else
        g_debug("We are not connected!");

Receiving statistics of the connection

Receiving statistics of the current internet connection is achieved with con_ic_connection_statistics() function and corresponding event handler. If you want, you can get statistics for a specified IAP or just statistics for the current default connection. Please note that currently Internet Connectivity daemon provides only one internet connection at the time, so leaving IAP ID NULL is the best option.

static void connection_statistics(ConIcConnection *connection,
                                  ConIcStatisticsEvent *event,
                                  gpointer user_data)
{
    g_debug("Here are all kind of nice statistics about the connection:");
    g_debug("Time active: %u, signal strength: %u, received packets: %llu, "
            "sent packets: %llu, received bytes: %llu, sent bytes: %llu",
            con_ic_statistics_event_get_time_active(event),
            con_ic_statistics_event_get_signal_strength(event),
            con_ic_statistics_event_get_rx_packets(event),
            con_ic_statistics_event_get_tx_packets(event),
            con_ic_statistics_event_get_rx_bytes(event),
            con_ic_statistics_event_get_tx_bytes(event));
}

...

    /* ConIcConnection object named "connection" has already been created */
    g_signal_connect(G_OBJECT(connection), "statistics", G_CALLBACK(connection_statistics), NULL);
    if (!con_ic_connection_statistics(connection ,NULL)) 
        g_warning("Requesting connection statistics failed!");

Getting proxy settings

With Libconic, you can get internet connection proxy settings for various protocols. First, you should query, what kind of proxy mode is in use. This is achieved with con_ic_connection_get_proxy_mode() function. After getting the proxy mode, use the following functions to get the actual proxy settings:

• If proxy mode is CON_IC_PROXY_MODE_NONE, do not use any proxies.
• If proxy mode is CON_IC_PROXY_MODE_MANUAL, use the following functions to query proxy settings:
  • con_ic_connection_get_proxy_host() to get the proxy host
  • con_ic_connection_get_proxy_port() to get the proxy port
  • con_ic_connection_get_proxy_ignore_hosts() to get a list of hosts, for which the proxy should not be used.
• If proxy mode is CON_IC_PROXY_MODE_AUTO, use con_ic_connection_get_proxy_autoconfig_url() to get a proxy auto configuration URL.
  • Use of auto configuration URL is explained in Wikipedia

In this example, "connection-event" handler is modified to print HTTP proxy settings when we get connected:

static void my_connection_handler(ConIcConnection *connection,
                                  ConIcConnectionEvent *event,
                                  gpointer user_data)
{
    ConIcConnectionStatus status = con_ic_connection_event_get_status(event);
    GSList *ignore_hosts;

    if (status == CON_IC_STATUS_CONNECTED) {
        g_debug("We are connected! Let's see what kind of settings we have for HTTP proxy...");

        /* Do things based on specified proxy mode */
        switch (con_ic_connection_get_proxy_mode(connection)) {

            case CON_IC_PROXY_MODE_NONE:
                g_debug("No proxies defined, it is direct connection");
                break;

            case CON_IC_PROXY_MODE_MANUAL:
                g_debug("HTTP proxy %s:%d in use", 
                        con_ic_connection_get_proxy_host(connection, CON_IC_PROXY_PROTOCOL_HTTP),
                        con_ic_connection_get_proxy_port(connection, CON_IC_PROXY_PROTOCOL_HTTP));
                
                g_debug("List of hosts, for which proxy should not be used:");
                ignore_hosts = con_ic_connection_proxy_ignore_hosts(connection);
                for (GSList *iter = ignore_hosts; iter != NULL; iter = g_slist_next(iter)) {
                    g_debug("%s", (gchar *)iter->data);
                    g_free(iter->data);
                }
                g_slist_free(ignore_hosts);
                break;

            case CON_IC_PROXY_MODE_AUTO:
                g_debug("Proxy auto-config URL %s should be used", 
                        con_ic_connection_get_proxy_autoconfig_url(connection));
                break;
        }
    }
}

There exists also proxy functions for each individual protocol (like con_ic_connection_get_proxy_ftp_host()), but these functions are deprecated and should be avoided in newly-written code.

Getting list of user saved connection

You can get all user saved connections (IAPs) with con_ic_connection_get_all_iaps() function. The function returns simply singly linked list of ConIcIap objects:

    /* ConIcConnection object named "connection" has already been created */
    GSList *saved_iaps = con_ic_connection_get_all_iaps(connection);
    
    g_debug("The following connections have been saved by the user:");
    for (GSList *iter = saved_iaps; iter != NULL; iter = g_slist_next(iter)) {
        
        /* Get IAP object and print some information about it */
        ConIcIap *iap = (ConIcIap *)iter->data;
        g_debug("Connection %s called '%s' using bearer %s",
                con_ic_iap_get_id(iap), con_ic_iap_get_name(iap),
                con_ic_iap_get_bearer_type(iap));
        
        /* We unref the IAP object as we are not going to use it anymore */
        g_object_unref(iap);
    }

    g_slist_free(saved_iaps);

Porting application from OSSO IC API to Libconic

• If your application has not configured GType, GLib or D-BUS, then setup those:

  DBusConnection *system_dbus;
  GMainloop *main_loop;
  
  g_type_init();
  main_loop = g_main_loop_new(NULL, FALSE);
  
  system_dbus = dbus_bus_get(DBUS_BUS_SYSTEM, NULL);
  dbus_connection_setup_with_g_main(system_dbus, NULL);
  

• Include the correct header file:

  #include <osso-ic.h>
  
  ===>
  
  #include <conic.h>
  

• Setup ConIcConnection object and "connection-event" handler instead of osso_iap_cb_t callback:

  static void my_connection_cb(struct iap_event_t *event, void *arg)
  {
  ...
  }
  
  ...
  
      osso_iap_cb(my_connection_cb);
  
  ===>
  
  static void my_connection_cb(ConIcConnection *connection,
                               ConIcConnectionEvent *event,
                               gpointer user_data)
  {
  ...
  }
  
  ...
  
      ConIcConnection *connection = con_ic_connection_new();
      g_signal_connect(G_OBJECT(connection), "connection-event", G_CALLBACK(my_connection_cb), app_data);
  

• Manage connections through ConIcConnection API instead of osso_iap_connect() and osso_iap_disconnect():

  osso_iap_connect(OSSO_IAP_ANY, OSSO_IAP_REQUESTED_CONNECT, app_data);
  osso_iap_disconnect(iap_name, app_data);
  
  ===>
  
  con_ic_connection_connect(connection, CON_IC_CONNECT_FLAG_NONE);
  con_ic_connection_disconnect(connection);
  
  

• Request statistics with con_ic_connection_statistics() instead of osso_iap_get_statistics().
• List all available IAPs with con_ic_connection_get_all_iaps() instead of osso_iap_get_configured_iaps().
• Configure autoconf to use Libconic instead of OSSO IC API:

  PKG_CHECK_MODULES(OSSOIC, osso-ic)
  AC_SUBST(OSSOIC_CFLAGS)
  AC_SUBST(OSSOIC_LIBS)
  
  ===>
  
  PKG_CHECK_MODULES(CONIC, conic)
  AC_SUBST(CONIC_CFLAGS)
  AC_SUBST(CONIC_LIBS)
  
  

• In debian/control file "Build-Depends" section, depend on libconic0-dev instead of osso-ic-dev.