Maemo Connectivity Architecture

This document is released under GPL license.

Maemo Connectivity Architecture


This guide is written for maemo 2.2 software release and Nokia 770 Internet Tablet. Connectivity parts are subject to change in future releases, so full compatibility can not be guaranteed. In fact, it is very likely that GConf settings and D-BUS messages will change in future releases, so please note this warning.

This chapter briefly presents the clients, the major dependencies and the public interfaces of the maemo connectivity subsystem. The internal structure and all of the interfaces of connectivity are presented in the subsequent chapters.

The maemo Connectivity subsystem is implemented by using known Linux conventions. It resides in the user mode area of Linux and relies on 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.

Figure below shows the parts of maemo connectivity and the licenses of these packages. The names of specific Debian packages are inside parenthesis.


Different pieces of the figure are explained below. Understanding these is essential to be able to follow this tutorial, so please take the time to familiarize yourself with them.

maemo connectivity API (IC) - Interface for setting up Internet connections. This is the main API to the Internet Connectivity. Internet Connectivity is a shared library. It has functions for requesting the activation and deactivation of Internet Access Points and statistics about the usage of them.

maemo connectivity UI - User Interfaces parts of the connectivity. This includes Connection manager, Control panel applets and several different dialogs.

maemo connectivity daemon (ICd) - IC API works together with ICd which handles 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. See more information about OpenOBEX from:

Bluetooth connectivity tools - Bluetooth related helper applications and tools. These include btsearch, btsdp and btcond.

BlueZ Bluetooth stack - The de-facto implementation of Bluetooth for Linux. See more information about BlueZ from:

WLAN connectivity daemon - The daemon which controls 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, which binds the binary to 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 the user will define according to her needs. An IAP is local to maemo and 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 providers modem, among other characteristics.

Connectivity Subsystem

This section describes the system decomposition of the Connectivity subsystem. The diagram below shows the logical entities of the subsystem, dependencies between them, provided interfaces and required external interfaces. External dependencies are shown with dotted arrows.

The Phone Access subsystem is responsible for the local connections to the phone. The Internet Access subsystem manages the remote connections using the IP protocol. The Connection Manager has the user interface for monitoring the connections and shutting them down. Internet Access contains the user interface for configuring the settings for Internet Access Points.

Maemo applications can open Internet connections by using the IC API or its socket counterpart IC socket. The Internet Access subsystem will take care of the connection to the phone, if it is 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 (at least the latter) must not be active. The Device System Management Entity (DSME) of maemo provides information about the transitions to and from the flight mode.


Figure 1. Decomposition of maemo connectivity subsystem

Name Connection Manager
Purpose Provides the UI for managing phone and Internet connections. Available as Control Panel applet and from Status Bar.
Responsibilities and additional requirements
  • Displays active connections with statistics
  • Updates status indicators
  • Provides dialogs for changing and disconnecting connections.
Concurrent usage (Not relevant)

Name Phone Access
Purpose Provides connections to phones with different Bluetooth profiles.
Responsibilities and additional requirements
  • Searches for phones and inquires their services.
  • Keeps phone register.
  • Provides status of the phone connections for Connection Manager
  • Binds RFCOMM devices to DUN and FTP services on the phone.
  • Provides easy access to OpenOBEX.
Concurrent usage Number of clients not limited by maemo. However, some phones may not support more than one Bluetooth profile at a time.

Name Internet Access
Purpose Provides Internet connections over WLAN and cellular systems.
Responsibilities and additional requirements
  • Provides means for configuration and management of IAP settings
  • Provides API for Internet connections both with WLAN and with dial-up/PPP
  • Provides status of Internet connections for Connection Manager
Concurrent usage Number of clients not limited but only one connection to the Internet can exist at a time.

Phone and Internet connections are quite different from their nature and behavior. The next chapters will introduce these some more.

Phone access

Phone Access is the subsystem that handles 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-damand basis, that is, 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 done with GnomeVFS layer to get transparent access to phone 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.


Figure 2. Decomposition of maemo phone access

Name Phone selection UI
Purpose User interface for managing phone operations. Supports Connection Manager.
Responsibilities and additional requirements
  • Keeps a list of phones
  • Stores the Bluetooth device addresses of phones to GConf
  • Invokes device search and capability query.
Concurrent usage N/A

Name BT search
Purpose Searches for available Bluetooth devices.
Responsibilities and additional requirements
  • Bluetooth inquiry
  • Checks on flight mode state
Concurrent usage N/A

Name BT service discovery
Purpose Checks if a found Bluetooth device is sufficient.
Responsibilities and additional requirements
  • Bluetooth service discovery (SDP)
Concurrent usage Not limited (but used by Phone selection UI and Phone connection daemon only).

Name BT connection daemon
Purpose Manages the phone connections.
Responsibilities and additional requirements
  • Binds the device to the selected phone with the selected Bluetooth profile
  • Keeps book about the existing connections between applications and the phone, which is based on the events received from the Bluetooth HCI
  • Knows if the phone is reachable
  • Checks on flight mode state.
Concurrent usage Not limited.

Name GW OBEX library
Purpose Provides access to OpenOBEX library for the File selector (Gnome VFS) on a higher abstraction level than OpenOBEX itself supports.
Responsibilities and additional requirements
  • Handles OBEX requests.
Concurrent usage Not limited

Purpose Obtains session keys for EAP-SIM authentication from the phone.
Responsibilities and additional requirements
  • SIM/PIN entry
  • Connects to the phone with SIM Access Profile
  • Delivers the session keys to EAP.
Concurrent usage N/A

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 some 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.


Figure 3. Decomposition of maemo Internet Access

Name IC daemon
Purpose IC daemon establishes Internet connections over WLAN and Bluetooth DUN on the request of IC library.
Responsibilities and additional requirements
  • Provides the IC library with means to activate/deactivates IAPs.
  • Controls that only one Internet connection (one active IAP) can exist at a time
  • Uses Phone Access for getting a character device for a dial-up connection and WLAN connection daemon for getting a network device and getting the connection authenticated.
  • Starts IP level services like PPP and DHCP
  • Provides statistics about the usage of IAPs to any application.
Concurrent usage Has only one client and limits the connections to one at a time.

Name IC library
Purpose IC library is a shared library that handles requests about activating and deactivating IAPs and provides statistical information about them.
Responsibilities and additional requirements
  • Provides the IC API for requesting activation and deactivation of Internet connections, getting statistical information of them and a list of available IAPs. An application shall obtain an IAP before opening sockets for a network connection.
  • Provides counterparts of BSD socket functions for applications that do not know (have not been modified to use) the IC API. This is implemented as a preloaded library. The library first activates an IAP and then opens a socket.
  • Disconnects an IAP once the last socket associated to it has been closed.
Concurrent usage Not limited.

Name Internet Connectivity GUI
Purpose This package has the GUI applications for configuring Internet Access Points and WLAN settings. Note that the Connection Manager is a separate application.
Responsibilities and additional requirements
  • Provides the UI for configuring an IAP
  • Provides the UI for WLAN settings
  • Scans for available WLAN networks (on request)
  • Saves IAP and WLAN settings (excluding EAP settings) to GConf
  • Opens up dialogs and displays notifications
Concurrent usage N/A

Name WLAN connection daemon
Purpose Manages WLAN network connections.
Responsibilities and additional requirements
  • Starts WLAN driver with the settings provided; stops WLAN
  • Requests authentication when necessary
  • Relays WLAN IAP settings from IC daemon to WLAN drivers and authentication requests to EAP
  • Relays WLAN events from WLAN drivers
  • Provides WLAN status information
Concurrent usage Not limited.

Purpose User interface for EAP authentication
Responsibilities and additional requirements
  • Invokes a dialog for an authentication password
  • Shows authentication status
Concurrent usage N/A

Name EAP
Purpose Provides WLAN security excluding basic WEP settings, which are in Wireless Extensions.
Responsibilities and additional requirements
  • Takes care of the authentication process for the active IAP
  • Delivers progress events to IC daemon
  • As a special case, controls the EAP-SIM authentication using the SIM Access Profile
  • Provides authentication status
Concurrent usage N/A

Internet Connectivity Daemon

This chapter describes how the Internet Connectivity daemon works internally. The following subchapters explain the behavior and the decomposition of this component in detail. It also covers the interfaces that this component realizes.


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. The following two chapters explain the actions to be taken in each case.

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 has 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 atomatically to 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, for example, will be always up to date. The device will also be always ready for online usage, for example, incoming VoIP call 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 IAP's and tries to connect atomatically connect 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 do "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, being of each application the responsability of keeping its data updated and then providing the always online feature.

While writing an application which makes use of the ICd system, you should keep the folowing points in mind:

  • Your application must always use the existing connection available.
  • As it was done in former versions, if device is not connected but a connection is required by user interaction, your application must require connection creation using the IC API.
  • Keep the user aware making visible when your data was last updated.
  • Your application must always listen to signals emmited by ICd (Connection Created, Lost and Changed) and behave as following:
    • Connection Created: Use the connection and update all data.
    • Connection Lost: Go to an idle state silently and wait untill a new connection is created.
    • Connection Changed: Use this new connection.
  • Automatic data updates must run in background and silently:
    • Avoid alarming the user with unnecessary banners or bocking dialogs.
    • Save usernames and passwords so that automatic updates can be done without prompts.
    • In this case, all failures must not show error notification dialogs.
  • The connectivity infrastructure takes care of error situations in a centralized way.

Automatic connetion 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 flight mode. Also Bluetooth connections are normally disabled in 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, etc., 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 interested applications to indicate that the IAP has been established.

If the previous 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



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 sets security keys for the WLAN network, which will result 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 standalone independent program, it is started 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.

Disconnecting a WLAN IAP performs the same tasks but in opposite order:

  • The DHCP client (udhcpc) is sent a SIGUSR2 and SIGTERM signals whereby the network interface is deconfigured and the DHCP client exits. If the IP address was configured statically, it's the responsibility of ICd to deconfigure it.
  • EAP authentication software is notified allowing it to deauthenticate gracefully from the WLAN network.
  • Wlancond is signalled to disassociate from the WLAN network and the WLAN interface is powered off.

Post-activation/deactivation tasks

When the network device activation has been successful, but no dynamic IP address configuration has taken place, it is the task of the ICd to apply the IAP-specific statically configured IP address and DNS addresses. ICd will accomplish this by executing the DHCP client postconfig script with the static configuration data, since this provides an uniform method of network configuration.

Proxy servers, if any, are configured in the standard GConf location required by GNOME. When these tasks have been completed, a success reply will be sent over D-BUS to the IC library. If a previous IAP using the other interface is active, it will be brought down at this point. This is to ensure as robust operation of IAPs as possible, meaning that if the new connection cannot be established, the old one will still be usable with no loss of service.

Post-deactivation tasks include removing any previously configured proxy and DNS servers. When these tasks have completed successfully, a success reply will be sent via D-BUS to the IC library.

Every time an IAP has been activated or deactivated, a D-BUS state change signal is emitted so that interested applications are able to show the current status of the Internet Access Point.

Below is the state machine explaining the different states.

Transition # State before State after Triggered by
1 No IAP active Connecting IAP D-BUS request
2 Connecting IAP IAP active Succesful activation of an IAP
3 IAP active Disconnecting IAP 1. D-BUS message from the last application using the IAP
2. D-BUS message
4 Disconnecting IAP No IAP active Clean up of previously active IAP has been performed
5 Connecting IAP No IAP active Failure in IAP activation
6 IAP active Switching IAP D-BUS request to activate a new IAP
7 Switching IAP IAP active 1. IAP has been switched succesfully
2.Attempt to activate the new IAP has failed, but the previous IAP is still active
8 Switching IAP Disconnecting IAP Attempt to activate the new IAP failed and the previously active IAP has been already disconnected


D-BUS interface of ICd

The Internet Connectivity daemon (ICd) provides a D-BUS API for setting up specific IAPs. The IC library uses the ICd D-BUS API to activate and deactivate IAPs. Applications should use the ICd D-BUS API only for statistics querying (get_statistics) and receiving IAP state change information (status_changed). The ICd is responsible for setting up Bluetooth DUN and WLAN interfaces, and starting IP level services such as PPP and DHCP. In establishing IP connections, ICd relies on btcond, wlancond and EAP authentication software components. As only one IAP can be active at a time, ICd will deactivate the previous IAP when a request for another one is made. When required ICd will also show UI dialogs requesting confirmation from the user.

Object paths        /com/nokia/icd
Method:            connect
Parameters:        1. string - Name of the IAP
                   2. uint32 - Whether this is a timed event (e.g. automatic
                               fetching of emails) or a user requested event
                               (all others).
                   3. uint32 (optional) - Process ID of the application,
                               supplied only by the preloaded library
Return Parameters: nothing
                   The specific IAP does not exist
                   Activation of the specific IAP failed

Description:       Activates or changes the active IAP and records the D-BUS
                   base service name of the caller. If requested IAP is
                   different from currently active IAP then the current IAP
                   will be first deactivated.
Method:            disconnect
Parameters:        string - Name of the IAP
Return Parameters: none
                   The IAP was not disconnected since other applications are
                   still using it.

Description:       Removes the D-BUS base service name of the caller from list
                   of applications using the IAP. Deactivates the IAP if the
                   disconnecting application is the last one using the IAP.
Method:            get_statistics
Parameters:        none
Return Parameters: 1. string - Name of the current IAP
                   2. uint32 - Active time of IAP
                   3. uint32 - Signal strength of the wireless medium.
                   4. uint32 - Number of packets received
                   5. uint32 - Number of packets sent
                   6. uint32 - Number of bytes reveiced
                   7. uint32 - Number of bytes sent.
Errors:            none

Description:       Gets the statistics of currently active IAP.
Method:            get_ipinfo
Parameters:        none
Return Parameters: 1. string - Name of the current IAP
                   2. string - IP address of the interface
                   3. string - Netmask
                   4. stinrg - IP address of the default gateway
Errors:            none

Description:       Gets the IP address of the currently active IAP.

FThere is also one useful signal emitted from interface:

Signal:            status_changed
Parameters:        1. string - Name of the current active IAP or empty
                   2. string - Type of IAP, same as in GConf or empty
                   3. string - Status of the IAP connection:
                               IDLE, CONNECTING, CONNECTED,
                               DISCONNECTING, SWITCHING.

Description:       Status of the currently active IAP.

See osso-ic-dbus.h for all the D-BUS macros of ICd.

Code clock below demonstrates the usage of 'status_changed' D-BUS message. For monitoring and maintaining in our application the connection's state, we shall add a signal handler for 'status_changed' (ICD_STATUS_CHANGED_SIG) D-BUS signal emitted by ICd.

/* Callback for the internet connection 'status_changed' signal sent by icd */
static DBusHandlerResult
get_connection_status_signal_cb ( DBusConnection *connection,
                                  DBusMessage *message,
                                  void *user_data )
  /* check signal */
  if (!dbus_message_is_signal ( message,
                                ICD_STATUS_CHANGED_SIG ))

   * get args:
   *   iap_name:    name of the current active IAP or empty
   *   iap_nw_type: type of IAP
   *   iap_state:   status of the IAP connection
  dbus_error_init (&dbus_error);
  if ( !dbus_message_get_args ( message, &dbus_error,
                                DBUS_TYPE_STRING, &iap_name,
                                DBUS_TYPE_STRING, &iap_nw_type,
                                DBUS_TYPE_STRING, &iap_state,
                                DBUS_TYPE_INVALID ) )

  switch ( new_state )
    case INET_IDLE:
/* add D-BUS signal handler for 'status_changed' */
filter_string = g_strdup_printf ("interface=%s", ICD_DBUS_INTERFACE,);

/* add match */
dbus_error_init (&error);
dbus_bus_add_match(dbus_connection, filter_string, &error);

g_free (filter_string);
if (dbus_error_is_set(&error))
  /* handle the error */

/* add the callback */
if (dbus_connection_add_filter( dbus_connection,
                                NULL ) == FALSE)
  /* handle the error */

Settings and configuration data is shared with ICd. See next chapter for details on the GConf settings.

D-BUS interface of PPP and DHCP

The following D-BUS signal is used to relay address configuration information from PPP and the DHCP client. The signal can be emitted due to successful, unsuccessful and changing network configuration. Changes to network configuration can happen if a DHCP server decides to allocate a new IP address to the device. The signals are received only by ICd.

Object paths       /com/nokia/icd/autoconf

Signal:            autoconf_changed
Parameters:        1. string - Name of the interface used
                   2. string - Name of the autoconfiguration program i.e. ppp
                               or udhcpd.

Description:       Report from the autoconfiguration program on the status of
                   the IAP.

Connectivity daemon Settings

Each IAPs' connection configuration (connection type, authentication information, etc.) are stored in GConf under the path /system/osso/connectivity/IAP/<name of IAP>. These configuration variables are set and mostly used by ICd, so we can easily reconnect to an already configured IAP any other time. Although by default all configuration variables are readable and writable by all applications unless otherwise stated, if an application needs information about the currently connected IAP, first it should try to get it through D-BUS method call to the ICd and if it's not available there it shall read them out from the GConf.

Changing the values of the these variables by any other application is not recommended, since it will most probably lead to inconsistent states.

The full list of connectivity GConf settings can be found from Appendix 1, separated to subsections based on their usage. Below is an example of how to use GConf to read these settings, it shows how to get the proxy settings for our application:

The gconf keys set by icd are:
  /system/proxy/mode: (string) values are none, manual or auto
  /system/proxy/ftp_host: (string)
  /system/proxy/ftp_port: (int)
  /system/proxy/secure_host: (string)
  /system/proxy/secure_port: (int)
  /system/proxy/socks_host: (string)
  /system/proxy/socks_port: (int)
  /system/proxy/autoconfig_url: (string)
  /system/http_proxy/use_http_proxy: (bool)
  /system/http_proxy/host: (string)
  /system/http_proxy/port: (int)
  /system/http_proxy/ignore_hosts: (list of strings)

static void get_proxy_settings(GConfClient *gc_client, ProxySettings *pset) {
	gchar *p_str;

	/* should we use proxy at all? */
 	p_str = gconf_client_get_string(gc_client,
				/system/proxy/mode, NULL);

	if (strcmp(p_str, none) == 0)
		/* there's no proxy settings */
	else if (strcmp(p_str, auto) == 0) {
		/* get autoconfiguration url */
		pset->auto_url =
				     /system/proxy/autoconfig_url, 				     NULL);
	} else {
		/* manual */
		pset->ftp_host =
				     /system/proxy/ftp_host, 				     	     NULL);
		pset->port =
				    /system/proxy/ftp_port, 				     	    NULL);
		.../* get the rest */ ...


	/* we can get the same way the http_proxy settings from GConf*/
/* Get the proxy settings to ProxySettings struct */
get_proxy_settings (gc_client, &pset);

Internet Connectivity library

This chapter describes how the Internet Connectivity library works internally. The following subchapters explain the behavior and the decomposition of this component in detail. It also covers the interfaces that this component realizes.

Connectivity methods

The IC library can be invoked in two separate ways to activate an IAP. The first method preloads C library socket functions and is described in Automatic connectivity. The second method involves calling explicit functions for requesting an activation or deactivation of an IAP, which is described in Internet Connectivity API. IAPs can also be set to connect without asking. The setting can apply to either WLAN, phone or both. The device can also be set to close all connection when the cover is closed.

Automatic connectivity

Since all applications cannot be modified to follow the IC library API, the IC library also provides socket creation and manipulation functions identical in syntax to those provided by the system C library. Because the shared IC library is loaded before the system C library, symbols and functions from the IC library take precedence over those located in the system C library. When the IAP activation has taken place and completed successfully, the intended system C library function is called. This activation sequence is shown in Figure 4.


The way to get it working is to set a special environmental variable before launching the application. We need to set LD_PRELOAD environment variable so that is loaded before starting the application. Easiest way to do this is to start the application with a shell script instead of starting the application binary directly. In this shell script we first run, which will load the After this the script runs the application binary. The script is an example how to do this.

source /usr/bin/

This is then started from the desktop file where the runnable binary is normally specified.

Internet Connectivity API

The IC API provides explicit functions for requesting an activation or deactivation of an IAP. These functions are merely convenience functions providing a C library API wrapping for the ICd D-BUS API. Timed events requesting IAPs are to be differentiated from user driven actions since timed events are not allowed to turn on an IAP or change the active one. Applications should use the IC library API instead of accessing the ICd D-BUS API directly whenever possible, so that programming errors and unnecessary duplication of source code is minimized.

For the full API reference see /usr/include/osso-ic.h header file.

Connectivity API functionality

Creating the connection

For requesting an Internet connection in our application we shall use the osso_iap_connect function provided by IC API. This will forward our request by sending the connect D-BUS method call to ICd. The detailed IAP activation sequence is shown in Figure 5.


Figure 5. IAP activation using IC API

The function itself:

gint osso_iap_connect (const char *iap, dbus_uint32_t  flags, void *arg);

const char *iap

The name of the IAP. Also OSSO_IAP_ANY (for using any kind of already available connection) and OSSO_IAP_ASK (asking the user to choose an IAP from a list [see]) IAP meta names can be used.

dbus_uint32_t flags

Flags used with the connection, it is either OSSO_IAP_REQUESTED_CONNECT or OSSO_IAP_TIMED_CONNECT.

void *arg

The Parameter passed for callback function (user_data)

The function returns OSSO_OK for success or OSSO_ERROR for an error. Successful invocation of this function will always generate an event. It can be either OSSO_IAP_CONNECTED or OSSO_IAP_ERROR.

Before invoking connection we shall register a

typedef void (*osso_iap_cb_t)(struct iap_event_t *event, void *arg);

callback function for handling IAP events like OSSO_IAP_CONNECTED, which indicates that the connection established successfully or OSSO_IAP_DISCONNECTED, which shows that the IAP connection has been torn down for some reason.

An example of requesting for Internet connection in an application:

static void iap_callback(struct iap_event_t *event, void *arg)
/* Register a callback function for IAP related events. */
if (osso_iap_cb(iap_callback) != OSSO_OK) {
      printf("osso_iap_cb failed");
/* establish Internet connection. */
if (osso_iap_connect(OSSO_IAP_ANY, OSSO_IAP_REQUESTED_CONNECT, &user_data)
            != OSSO_OK) {
                printf("osso_iap_connect failed");

Using the connection

After successfully setting up a connection we can use it like any other socket based connection.

struct addrinfo *addrinfo;

fd = socket(addrinfo->ai_family, addrinfo->ai_socktype,
if (fd == -1) {
   perror("socket error");

if (connect(fd, addrinfo->ai_addr, addrinfo->ai_addrlen) == -1) {
   perror("could not connect");


Testing the connection

If we have an already existing connection we can retrieve basic statistical information about the connection with the osso_iap_get_statistics function.

gint osso_iap_get_statistics (const char *iap, void *arg)

Request statistics from an IAP.

const char *iap - The name of the IAP whose statistics are asked for.

void *arg - Parameter passed for callback function (user_data).

It returns OSSO_OK for success and OSSO_ERROR for an error. The statistics will be reported in an OSSO_IAP_STATISTICS event. For asynchronous errors OSSO_IAP_ERROR event will be sent.

Example code in our case would be:

 * Callback for IC API events.
 * @param ev Event data.
 * @param arg Data to associate events for specific requests.
static void iap_callback(struct iap_event_t *ev, void *arg)
	if( (long) arg == 0xF00BA4)
	     printf("Callback for our statistics request: ");

	/* check for the event type and print out the statistics */
	if( ev->type == OSSO_IAP_STATISTICS)
                printf(", time_active=%d, signal_strength=%d"
                       ", rx_packets=%d, tx_packets=%d"
                       ", rx_bytes=%d, tx_bytes=%d",

    /* after making the connection successfully
       we call this function in our code somewhere for basic statistics.
       0xF00BA4 is an example parameter pointer which in real case would be
       something more sensible.
    osso_iap_get_statistics(iap_name, (void*) 0xF00BA4);

Closing the connection

When an application using the IC library API stops using the network it calls osso_iap_disconnect() to inform the IC subsystem that the network can be disconnected. The preloaded library providing socket functions used by unmodified applications will track active sockets, and when the last socket is closed the IAP will be disconnected. Closing the network connection is described in Figure 6 and Figure 7.

If the IAP is disconnected forcefully from the Connection Manager, the device moves outside the network range, or an idle timeout has been reached, sockets associated with the disconnected IAP need to be closed as well. Applications using the IC library API will be notified of the IAP disconnection via their registered callback functions. Sockets of unmodified applications that activated the IAP network connection via the preloaded functions of the IC library will be forcefully shut down by the IC library when the library receives D-BUS messages indicating IAP disconnection. If the unmodified application at any later time tries to read or write data from or to the socket, it will receive a socket error from the C library. It is then up to the logic of the unmodified application to decide on how to proceed with a disconnected network socket. This action sequence is illustrated in Figure 6.


Figure 6. IAP disconnection activated by the IC preloaded library


Figure 7. IAP deactivation initiated by Connection Manager, network error/loss or idle timeout

Bluetooth libraries

This chapter explains how maemo Bluetooth libraries work internally. The following subchapters explain the behavior and the decomposition of the Bluetooth library components in detail.


Libgwobex provides access to libopenobex functionality by providing a helper/wrapper interface to it. Libopenobex is explained in detail in the following chapter.

The interface (doxygen generated documentation) to libgwobex can be found at

Creating the connection

The connection with libgwobex is established using the gw_obex_setup_dev -function, which setups the connection.

#define OBEX_FTP_UUID \
#define OBEX_FTP_UUID_LEN 16

GwObex* gw_obex_setup_dev (const gchar * device, const gchar * uuid, gint uuid_len, GMainContext * context, gint * error )

The following code snippet illustrates how to open a handle using gw_obex_setup_dev.

if (ctx->rfcomm_dev) {
	if (ctx->use_ftp)
		ctx->obex = gw_obex_setup_dev(ctx->rfcomm_dev,
			NULL, &err);
		ctx->obex = gw_obex_setup_dev(ctx->rfcomm_dev, NULL,
			0, NULL, &err);

	if (ctx->obex == NULL)
		printf("OBEX setup failed: %s\n", response_to_string(err));

In this example ctx->rfcomm_dev points to a string containing the device node name (e.g. /dev/rfcomm0). ctx->use_ftp dictates whether standard folder browsing services should be set up. If use_ftp is untrue then we connect to INBOX.

Closing the connection

For closing a gwobex connection you can use the

void gw_obex_close ( GwObex * ctx )

function. The following code demonstrates this usage.

if (ctx->obex) {
	ctx->obex = NULL;

If ctx->obex is not NULL we simply pass it as an argument to gw_obex_close().

Using the connection

The libgwobex library provides general file handling functionality including reading directory structure, browsing in different folders, getting files etc.

For reading entries from an opened directory you can use the function

gboolean gw_obex_read_dir (GwObex * ctx, const gchar * dir, gchar ** buf, gint * buf_size, gint * error )

gw_obex_read_dir reads an entry from the selected folder and returns the result in the buf argument given to the function.

gboolean ret;
ret = gw_obex_read_dir(ctx->obex, dir, buf, buf_size, err);

This reads an entry from the directory dir (char *) and returns it in buf (char **).

For changing the current directory, use function:

gboolean gw_obex_chdir (GwObex * ctx, const gchar * dir, gint * error )

which changes the directory of the FTP connection. Below is a code example of using this function.

/* Ignore parent dir pointers */
if (g_str_equal(name, ".."))
	return TRUE;

if (!gw_obex_chdir(ctx->obex, name, err)) {
	printf("Could not chdir to %s\n", name);
	return FALSE;

To retrieve files over the OBEX connection we can use the gw_obex_get_file function.

gboolean gw_obex_get_file (GwObex * ctx, const gchar * local, const gchar * remote, gint * error)

gw_obex_get_file uses the ctx context for retriving the remote file to local file.

gboolean ret;

ret = gw_obex_get_file(ctx->obex, name, name, err);

There are a lot more what can be done by using libgwobex wrapper directly, for full list of functions and their usage please see the API document:


LibOpenOBEX library implements a generic OBEX Session Protocol. It does not implement the OBEX Application Framework. OBEX is a protocol designed to allow interchanging of data between different kinds of connections (for example Bluetooth, IrDA). Specific information about the OBEX protocol can be found at, by selecting the Developer->Specifications category. OBEX is similar to HTTP protocol expect for a few differences:

  • Transports: While HTTP is normally layered above a TCP/IP connection, OBEX is usually transported over IrLAP/IrLMP/Tiny TP (on IrDA) or over Baseband/Link Manager/L2CAP/RFCOMM (on Bluetooth).
  • Binary transmissions: OBEX communicates using binary transmissions as HTTP is transmitted in a human readable XML-based format.
  • Session support: HTTP is stateless while OBEX maintains the connection.

A pretty good overlook of OBEX can be found at

Code examples for libopenobex can be obtained from from the example apps package.


Osso-gwconnect provides a D-BUS interface to different parts of Bluetooth functionality:

  • Bluetooth Connection Daemon (btcond)
  • Bluetooth SDP (btsdp)
  • Bluetooth Search (btsearch)

The interface is a well defined D-BUS message API. Details on the provided interface can be found from osso-gwconnect howto:

Using Bluetooth Connection Daemon

This daemon is responsible for controlling connections to Bluetooth devices as well as messaging related information through the system D-BUS. The daemon listens for messages assigned to it on the system D-BUS as well as broadcasts status signals to the system D-BUS.

For checking whether btcond is available you can send a D-BUS message to it and get a reply. The following code snippet illustrates how to send the message.

Btcond D-BUS services are as follows:



Object paths:

With gwconnect one should use general D-BUS messages instead of the libosso library versions for sending the messages, because libosso does not provide enough functionality for such an operation.

gboolean ret;
DBusConnection *c;

c = dbus_bus_get(DBUS_BUS_SYSTEM, NULL);
if (c == NULL) {
	fprintf(stderr, "Unable to connect to the system D-BUS\n");
	return FALSE;

ret = dbus_bus_service_exists(c, BTCOND_SERVICE, NULL);
if (!ret)
	printf("btcond is not connected to the system D-BUS\n");

return ret;

The code is pretty much self-explanatory.

btcond provides an interface to make RFCOMM connections via D-BUS. In order to connect to a RFCOMM service you can send the rfcomm_connect D-BUS message to btcond. The service names and paths are explained in earlier section. The BDA of the desired bluetooth device is given as an argument to rfcomm_connect.

rfcomm_disconnect is a D-BUS message that disconnects a given RFCOMM connection. If no specific RFCOMM connection is defined in the call then the default RFCOMM connection will be disconnected.

Both rfcomm_connect and rfcomm_disconnect will send back an error message in case the operation could not be completed.

Using Bluetooth SDP

This application provides the Bluetooth SDP (Service Discovery Protocol) service over D-BUS. Bluetooth SDP provides an D-BUS interface through:



Object paths:

By sending btsdp an D-BUS message get_rfcomm_services you can retrieve a list of the RFCOMM services of a given BDA. The D-BUS message takes as argument a BDA for which all available RFCOMM services are returned in a list format. The supported services are:

"DUN"  (Dialup Networking Profile)
"FTP"  (OBEX File Transfer Profile)
"NFTP" (Nokia OBEX Filetransfer Profile)
"OPP"  (OBEX Object Push Profile)
"SAP"  (SIM Access Profile)
"SPP"  (Serial Port Profile)

For more complete information on using get_rfcomm_services please consult the gw-connect documentation available at

Using Bluetooth Search

This application is the backend to the Bluetooth Inquiry UI which is used to search Bluetooth devices. The UI sends a "start_search" message to this backend and the backend commences a Bluetooth inquiry. Every time a new device is found the backend sends a "dev_found" signal to the UI. When inquiry is finished a "search_complete" signal is sent to the UI.

If the Bluetooth Search doesn't get a "start_search" request within 5 seconds after startup it will automatically exit. This works since it is designed to be launched through D-BUS activation so D-BUS starts it automatically always when it gets a message destined for the "" service.

See more information about Bluetooth Search service from:

Connectivity UI

UI components

Connectivity UI contains different dialogs and other components used to control the connectivity. The different UI parts are:

  • Connection manager
  • Connectivity dialogs
  • Status bar applets
  • Control panel applet
  • Bluetooth UIs

The connectivity dialogs are invoked by D-BUS method calls so for example ICd is using these D-BUS method calls for showing dialogs when they are needed. Next chapter specifies the D-BUS API of maemo connectivity UI

D-BUS Connectivity UI interface

If we need some information from the user about the IAP we are about to connect we can use the below mentioned ones for this purpose.

Object paths:      /com/nokia/icd_ui

The Internet Connectivity UIs implements the following D-BUS API used by ICd and EAP.

Method:            show_conn_dlg
Parameters:        none
Return parameters: none
                   Flight mode enabled, dialog not shown
Description:       Shows the Connect Dialog where the user can choose an IAP.
Method:            show_disconnect_dlg
Parameters:        none

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Show the disconnect dialog.
Method:            show_retry_dlg
Parameters:        1. string  Bluetooth address of the device used with SAP
                   2. string  Name of the connection attempt error which
                               selects the retry dialog type.

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Shows the retry dialog.
Method:            show_change_dlg
Parameters:        1. string  Name of the currently active IAP
                   2. string  Name of the IAP to be activated

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Shows the Change IAP Dialog
Method:            show_passwd_dlg
Parameters:        1. string  Username supplied by ICd
                   2. string  Password supplied by ICd
                   3. string  Name of the IAP

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Shows the username/password dialog.
Method:            show_gtc_dlg
Parameters:        1. string  GTC challenge string

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Show EAP GTC challenge dialog.
Method:            show_mschap_change_dlg
Parameters:        1. string  Supplied username
                   2. string  Old password that is to be changed
                   3. string  Name of the IAP

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Show EAP MSCHAPv2 change password dialog.
Method:            show_private_key_passwd_dlg
Parameters:        1. uint32  The private key ID

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Show EAP private key password dialog
Method:            show_server_cert_dlg
Parameters:        1. string  Certificate name
                   2. string  Certificate serial
                   3. boolean  TRUE if certificate is expired, FALSE otherwise
                   4. boolean  TRUE if root CA is unknown or self-signed
                                certificate, FALSE otherwise

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Show server certificate error and expiration dialogs.
                   If both boolean arguments are false, the error dialog is
                   shown. If either or both boolean arguments are TRUE, the
                   expiration dialog is shown instead.
Method:            strong_bt_req
Parameters:        1. string  Bluetooth address of the device to pair with
                   2. boolean  TRUE if strong authentication enabled, FALSE
                                if strong authentication is disabled

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Request strong (16 digit) BT PIN dialog for a BT device
Method:            show_sim_pin_dlg
Parameters:        1. string  Bluetooth address of the device used with SAP
                   2. boolean  TRUE if PIN was incorrect and retry dialog
                                should be displayed before asking PIN. FALSE
                                if this is the first PIN request.

Return Parameters: none
                   Flight mode enabled, dialog not shown

Description:       Show SIM PIN dialog

Example code for our application to show the connect dialog using show_conn_dlg is following. Please note the usage of macro for doing this.

/* in our code somewhere, where we need the Connect Dialog*/
DBusMessage *uimsg;

/* construct the message for Connect Dialog request*/
uimsg =
			 /*macro for show_conn_dlg */

/* send the message */
reply =

if (reply == NULL) {
    DLOG_ERR("Failed to show connect dialog: %s", uierror.message);


The signals emitted from interface are listed below.

Signal:        disconnect
Parameters:    1. boolean  TRUE if "disconnect" pressed, FALSE if "cancel"

Description:   Signal emitted from UI when disconnect dialog has been closed.
Signal:        retry
Parameters:    1. string  The IAP that is to be retried
               2. boolean  TRUE if "retry" pressed, FALSE if "cancel"

Description:   Signal emitted from UI when retry dialog has been closed.
Signal:        change
Parameters:    1. string  Old IAP to change from
               2. string  New IAP to change to
               3. boolean  Change to the new IAP If TRUE, keep old if FALSE

Description:   Signal emitted from UI when change connection dialog has
                been closed.
Signal:        passwd
Parameters:    1. string  Username supplied or modified by the user
               2. string  Password supplied or modified by the user
               3. string  IAP name
               4. boolean  TRUE if "ok" pressed, FALSE if "cancel"

Description:   Signal emitted from UI when the username/password dialog has
               been closed
Signal:        gtc_response
Parameters:    1. string  Response to the given challenge or empty string
                           if cancelled
               2. boolean  TRUE if "ok" pressed, FALSE if "cancel"

Description:   Signal emitted from UI when the EAP GTC challenge dialog has
               been closed.
Signal:        mschap_change
Parameters:    1. string  Supplied username
               2. string  The new password or empty string if cancelled
               3. string  IAP name
               4. boolean  TRUE if "ok" pressed, FALSE if "cancel"

Description:   Signal emitted from UI when the MSCHAPv2 password has been
Signal:        private_key_passwd
Parameters:    1. uint32  The id of the private key
               2. string  Password for the private key or empty string if none
               3. boolean  TRUE if "ok" pressed, FALSE if "cancel"

Description:   Signal emitted from UI when the private key password dialog
               has been closed
Signal:        server_cert
Parameters:    1. boolean  TRUE if strong PIN entered, FALSE if strong
                            PIN dialog was cancelled

Description:   Signal emitted from UI when the server certificate error
               dialog has been closed
Signal:        strong_bt
Parameters:    1. boolean  TRUE if strong PIN entered, FALSE if strong
                            PIN dialog was cancelled

Description:   Signal emitted from UI when the strong (16 digit) BT PIN
               has been entered
Signal:        sim_pin
Parameters:    1. string  SIM PIN code or empty string if  cancelled
               2. boolean  TRUE if "ok" pressed, FALSE if "cancel"

Description:   Signal emitted from UI when the SIM PIN has been entered.

APPENDIX 1: Connectivity daemon GConf settings

The following table lists top level connectivity configuration variables under the GConf path. /system/osso/connectivity/IAP/:

Variable Type Default value Description
current String None The name of the currently active IAP. Writable only by the ICd.
last_used_iap string None The last used iap set by the UIs
auto_connect String None The connection type to be connected automatically (None, WLAN, Any, Phone).
search_interval Integer 0 (Never) The interval in minutes for auto connecting to a saved IAP (0, 5, 10, 30, 60).
disconnect_on_cover Boolean False Whether to disconnect on cover close or not
flightmode_wlan Boolean True Whether WLAN is allowed in flight mode
timeout_wlan Integer Timeout for WLAN connections
timeout_dun_ps Integer Timeout for PS DUN connections
timeout_dun_cs Integer Timeout for CS DUN connections
wlan_tx_power Integer None WLAN transmit power.
Syntax 4 | 8
4: 10mW, (WLANCOND_TX_POWER10 from wlancond.h)
8: 100mW (WLANCOND_TX_POWER100 wlancond.h)

The following table lists the common IAP settings stored under the GConf path /system/osso/connectivity/IAP/<name of IAP>:

Variable Type Default value Description
type String None The type of IAP used.
ask_password boolean False True if the user is always asked for a password, False if configured passwords are automatically supplied for this IAP when needed

The possible values for the type variable above are described by the following table:

Possible values Description
DUN_GSM_CS GSM Circuit Switched connection over Bluetooth Dial-Up network
DUN_GSM_PS GSM GPRS connection over Bluetooth Dial-Up network
WLAN_ADHOC Wireless LAN network in ad-hoc mode
WLAN_INFRA Wireless LAN network in infrastructure mode
DUN_CDMA_CSD CDMA CSD circuit switched connection over Bluetooth Dial-Up Network
DUN_CDMA_QNC CDMA QNC circuit switched connection over Bluetooth Dial-Up Network
DUN_CDMA_PSD: CDMA packet data connection over Bluetooth Dial-Up Network
DUN_UMTS_CS UMTS circuit switched connection over Bluetooth Dial-Up Network
DUN_UMTS_PS CDMA packet data (GPRS) connection over Bluetooth Dial-Up Network

Network settings

The following table lists the Internet Protocol settings for each IAP listed under the GConf path /system/osso/connectivity/IAP/<name of IAP>:

Variable Type Default value Description
ipv4_type String AUTO The address configuration method
AUTO: address is fetched dynamically via DHCP or PPP
STATIC: address is configured statically using the below ipv4_ variables
ipv4_address <IPv4 address> none The statically configured IPv4 address
Syntax: <ip address>
ipv4_netmask <IPv4 address> none The statically configured IPv4 netmask Syntax: <ip address>
ipv4_gateway <IPv4 address> none The statically configured address of the IPv4 gateway
  • ipv4_dns1
  • ipv4_dns2
  • ipv4_dns3
<IPv4 address> none The statically configured IPv4 DNS proxy servers.
Syntax: <ip address>

Bluetooth settings

The following table lists the Bluetooth DUN settings for each IAP listed under the GConf path /system/osso/connectivity/IAP/<name of IAP>:

Variable Type Default value Description
dun_username string none Dial-up user name
dun_password string none Dial-up password
dun_phonenumber <phone number> none The phone number
dun_at_commands string none Optional modem initialization string, min. 200 characters
dun_ppp_pap boolean true Allow PAP plaintext passwords for ppp
dun_ppp_compression boolean true Allow PPP compression
dun_ps_accespointname string none PDP acces point name used by DUN_GSM_PS connections
dun_cs_calltype string None The type of DUN_GSM_CS connection
Syntax: normal | HSCSD
normal:: normal speed CS data
HSCSD: high speed CS data
dun_cs_remote string None The remote modem type for DUN_GSM_CS connections
Syntax: analog | v110 | v120
analog: analog remote modem
v110: ISDN v.110 remote modem
v120: ISDN v.120 remote modem
dun_cs_speed String None The data speed for DUN_GSM_CS connection type
Syntax: 9.6 | 14.4 | 28.8 | 43.2 | 57.6
values in kilobits/second
dun_operator string None The name of the operator

Note that settings prefixed with dun_ps_ and dun_cs_ are only applicable to that specific connection type, other settings are shared by all dial-up connection types. Currently no specific settings exist for CDMA connection types.

In addition the following items are added to /system/bluetooth/<BT address>:

Variable Type Default value Description
dun boolean none Whether the BT device supports DUN
dun_gsm boolean none Whether GSM is supported
dun_umts boolean none Whether UMTS is supported
dun_cdma boolean none Whether CDMA is supported
ftp boolean none Whether the BT device supports FTP
sap boolean none Whether the BT device supports SAP
strong_pin_pairing boolean none Whether the device has been paired with a 16-digit strong PIN

WLAN settings

The following table lists the WLAN settings for each IAP listed under the GConf path /system/osso/connectivity/IAP/<name of IAP>:

Variable Type Default value Description
wlan_ssid string none The SSID or network name for this WLAN
wlan_security string none The security method used in this network
NONE: no authentication
WEP: WEP security, EAP key update messages may be used
WPA_PSK: WPA with pre-shared key
WPA_EAP: WPA with EAP authentication
  • wlan_wepkey1
  • wlan_wepkey2
  • wlan_wepkey3
  • wlan_wepkey4
string none WEP keys 1-4 valid when WEP security is chosen (WEP standard specifies up to four keys per network, usually only one is used)
wlan_wepdefaultkey Integer none Default WEP encryption key.

Additional configuration entries for EAP authentication software. Note that the TLS and PEAP settings are named the same way. The selected EAP type chooses whether the settings are TLS or PEAP settings.

Variable Type Default Value Description
EAP_default_type Int32 0 This is the default EAP type
EAP_wpa_preshared_key List<Integer> 0 This is the WPA preshared key, length 32 bytes
EAP_use_manual_username Integer 0 Use manual username (yes/no)
EAP_manual_username String Manual username (e.g.
EAP_MSCHAPV2_username String NULL MSCHAPv2 user name, must be in Unicode format
EAP_MSCHAPV2_password String NULL MSCHAPv2 password, must be in Unicode format
EAP_MSCHAPV2_password_prompt Integer 0 Ask MSCHAPV2 password?
EAP_GSMSIM_use_manual_realm Integer 0 Use manual realm (yes/no)
EAP_GSMSIM_manual_realm String default@example.realm SIM auth realm
EAP_GSMSIM_use_pseudonym_identity Integer 0 Use identity privacy (yes/no)
EAP_GSMSIM_max_reauth_count Integer 100 Max reauthentication count (e.g. 100)
EAP_GTC_identity String NULL GTC identity
EAP_TLS_PEAP_version Integet 0 TLS PEAP version (0,1,2)
EAP_TLS_PEAP_use_manual_realm Integer 0 Use PEAP manual realm (yes/no)
EAP_TLS_PEAP_manual_realm String NULL Manual realm
EAP_TLS_PEAP_verify_certificate_realm Integer 0 Verify server certificate realm (yes/no)
EAP_TLS_PEAP_server_authenticates_client Integer 0 Require client authentication (yes/no)
EAP_TLS_PEAP_max_count_of_session_resumes Integer 0 Maximum session resume count
EAP_TLS_PEAP_accepted_PEAP_versions String 0:1:2 List of allowed PEAP versions
EAP_PEAP_tunneled_eap_type Integer 0 This is the tunneled PEAP type we accept
EAP_TLS_PEAP_cipher_suite Integer 50 TLS_DHE_DSS_WITH_AES_128_CBC_SHA, this is the cipher suite to use
EAP_TLS_PEAP_client_certificate_file String NULL Selected User Certificate
Eap Type Value
TLS 13

Proxy settings

The following table lists the proxy settings for each IAP listed under the GConf path /system/osso/connectivity/IAP/<name of IAP>:

Variable Type Default value Description
proxytype string NONE The proxy configuration method used for this IAP Syntax: NONE | AUTOCONF | MANUAL NONE: direct connection without proxies AUTOCONF: autoconfiguration url is specified in the autoconf_url variable MANUAL: proxies are defined manually using the below proxy_<url> variables
autoconf_url <URL> empty The autoconfiguration url to use
  • proxy_http
  • proxy_https
  • proxy_ftp
  • string
empty The DNS name or IP address of the proxy. Note that protocols (ftp, http and socks) can be supported by prepending proxy_ in front of the protocol specifier. See UI for supported protocols.
  • proxy_http_port
  • proxy_https_port
  • proxy_ftp_port
Integer empty The port number of the above proxy..
omit_proxy <list of strings> empty The domains that are not proxied, one per list item.

The application should not read directly the proxy settings from here, the ICd will set them automatically in /system/http_proxy and /system/proxy after establishing the connection with the selected IAP.

Improve this page