[RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

Hello

Here is another RFC patchset about implementing automatic provisioning of Internet and MMS GPRS context settings. ("Internet Access Provider database" TODO item).

In case there are no previously configured contexts found during gprs atom registration, this code tries to provision Internet and MMS contexts based on MCC, MNC and SPN (Service Provider Name) values read from SIM. Settings are read from an operator settings database.

Settings database is an XML formatted file (combination of all xml-files in a directory), containing one element per settings for a specific type of GPRS context (internet, mms)
Example:
<?xml version="1.0"?>
<settings>
<access type="internet" mcc="246" mnc="81" spn="oFono" name="Phonesim Internet-GPRS" apn="internet.apn"/>
<access type="mms" mcc="246" mnc="81" spn="oFono" name="Phonesim MMS-GPRS" apn="mms.apn" protocol="ipv4" username="mmsuser" password="mmspass" proxy="10.11.12.13:8080" mmsserver="http://mms.example.com:8000"/>
</settings>


Provisioning logic: first try to find exact match for type,MCC,MNC and SPN. If that fails (or if SPN read from SIM is missing/empty), we select first match for type/MCC/MNC. If also that fails, an empty context is created (as currently).

Patches also add new function ofono_sim_get_mnc_length to SIM atom API
for figuring out MNC value.

--Jukka Saunamäki

[RFC PATCHv2 1/4] sim: add ofono_sim_get_mnc_length

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

---
 include/sim.h |    1 +
 src/sim.c     |    8 ++++++++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/include/sim.h b/include/sim.h
index 7860e24..3d0c6b7 100644
--- a/include/sim.h
+++ b/include/sim.h
@@ -173,6 +173,7 @@ void ofono_sim_set_data(struct ofono_sim *sim, void *data);
 void *ofono_sim_get_data(struct ofono_sim *sim);
 
 const char *ofono_sim_get_imsi(struct ofono_sim *sim);
+int ofono_sim_get_mnc_length(struct ofono_sim *sim);
 enum ofono_sim_phase ofono_sim_get_phase(struct ofono_sim *sim);
 
 enum ofono_sim_cphs_phase ofono_sim_get_cphs_phase(struct ofono_sim *sim);
diff --git a/src/sim.c b/src/sim.c
index 335f611..8210972 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -1913,6 +1913,14 @@ const char *ofono_sim_get_imsi(struct ofono_sim *sim)
 	return sim->imsi;
 }
 
+int ofono_sim_get_mnc_length(struct ofono_sim *sim)
+{
+	if (sim == NULL)
+		return 0;
+
+	return sim->mnc_length;
+}
+
 enum ofono_sim_phase ofono_sim_get_phase(struct ofono_sim *sim)
 {
 	if (sim == NULL)
-- 
1.7.1

Re: [RFC PATCHv2 1/4] sim: add ofono_sim_get_mnc_length

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

Hi Jukka,

>  include/sim.h |    1 +
>  src/sim.c     |    8 ++++++++
>  2 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/include/sim.h b/include/sim.h
> index 7860e24..3d0c6b7 100644
> --- a/include/sim.h
> +++ b/include/sim.h
> @@ -173,6 +173,7 @@ void ofono_sim_set_data(struct ofono_sim *sim, void *data);
>  void *ofono_sim_get_data(struct ofono_sim *sim);
>  
>  const char *ofono_sim_get_imsi(struct ofono_sim *sim);
> +int ofono_sim_get_mnc_length(struct ofono_sim *sim);

actually that value is an unsigned char.

Regards

Marcel

[RFC PATCHv2 2/4] operator-settings: Add GPRS context provisioning sources

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 11215 bytes --]

---
 Makefile.am             |    3 +-
 src/operator-settings.c |  314 +++++++++++++++++++++++++++++++++++++++++++++++
 src/operator-settings.h |   37 ++++++
 3 files changed, 353 insertions(+), 1 deletions(-)
 create mode 100644 src/operator-settings.c
 create mode 100644 src/operator-settings.h

diff --git a/Makefile.am b/Makefile.am
index 8a8555d..d0e47e5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -328,7 +328,8 @@ src_ofonod_SOURCES = $(gdbus_sources) $(builtin_sources) src/ofono.ver \
 			src/nettime.c src/stkagent.c src/stkagent.h \
 			src/simfs.c src/simfs.h src/audio-settings.c \
 			src/smsagent.c src/smsagent.h src/ctm.c \
-			src/cdma-voicecall.c
+			src/cdma-voicecall.c \
+			src/operator-settings.c src/operator-settings.h
 
 src_ofonod_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ @CAPNG_LIBS@ -ldl
 
diff --git a/src/operator-settings.c b/src/operator-settings.c
new file mode 100644
index 0000000..4cc90d6
--- /dev/null
+++ b/src/operator-settings.c
@@ -0,0 +1,314 @@
+/*
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2009-2011 Nokia Corporation and/or its subsidiary(-ies).
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <string.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <glib.h>
+
+#include "ofono.h"
+#include "operator-settings.h"
+
+#define MAX_PROXY_NAME_LENGTH 255
+
+struct parser_data {
+	const gchar *mcc;
+	const gchar *mnc;
+	GSList *candidates;
+};
+
+void gprs_access_settings_free(struct gprs_access_settings *settings)
+{
+	if (settings == NULL)
+		return;
+
+	g_free(settings->name);
+	g_free(settings->apn);
+	g_free(settings->username);
+	g_free(settings->password);
+	g_free(settings->proxy);
+	g_free(settings->mms_server);
+	g_free(settings->spn);
+	g_free(settings);
+}
+
+static enum ofono_gprs_context_type string_to_gprs_context_type(const char *str)
+{
+	if (str) {
+		if (strcasecmp(str, "INTERNET") == 0)
+			return OFONO_GPRS_CONTEXT_TYPE_INTERNET;
+		if (strcasecmp(str, "MMS") == 0)
+			return OFONO_GPRS_CONTEXT_TYPE_MMS;
+	}
+
+	return OFONO_GPRS_CONTEXT_TYPE_ANY;
+}
+
+/*
+ * Parse <access> element.
+ * Mandatory attributes in <access>: mcc, mnc, type, name
+ * If MCC/MNC matches, add entry to candidate setting list.
+ */
+static void settings_start_element_handler (GMarkupParseContext *context,
+						const gchar *element_name,
+						const gchar **attribute_names,
+						const gchar **attribute_values,
+						gpointer user_data,
+						GError **error)
+{
+	int i;
+	struct parser_data *parser = user_data;
+	struct gprs_access_settings *entry;
+	const char *mcc = NULL, *mnc = NULL;
+
+	if (strcasecmp(element_name, "access") != 0)
+		return;
+
+	entry = g_try_malloc0(sizeof(*entry));
+	if (entry == NULL)
+		return;
+
+	for (i = 0; attribute_names[i]; i++) {
+
+		if (strcasecmp(attribute_names[i], "mcc") == 0)
+			mcc = attribute_values[i];
+
+		if (strcasecmp(attribute_names[i], "mnc") == 0)
+			mnc = attribute_values[i];
+
+		if (strcasecmp(attribute_names[i], "spn") == 0)
+			entry->spn = g_strdup(attribute_values[i]);
+
+		if (strcasecmp(attribute_names[i], "type") == 0)
+			entry->type = string_to_gprs_context_type(attribute_values[i]);
+
+		if (strcasecmp(attribute_names[i], "apn") == 0)
+			entry->apn = g_strdup(attribute_values[i]);
+
+		if (strcasecmp(attribute_names[i], "name") == 0)
+			entry->name = g_strdup(attribute_values[i]);
+
+		if (strcasecmp(attribute_names[i], "username") == 0)
+			entry->username = g_strdup(attribute_values[i]);
+
+		if (strcasecmp(attribute_names[i], "password") == 0)
+			entry->password = g_strdup(attribute_values[i]);
+
+		if (strcasecmp(attribute_names[i], "protocol") == 0) {
+			if (strcasecmp(attribute_values[i], "ipv6") == 0)
+				entry->proto = OFONO_GPRS_PROTO_IPV6;
+			else
+				entry->proto = OFONO_GPRS_PROTO_IP;
+		}
+
+		if (strcasecmp(attribute_names[i], "proxy") == 0)
+			entry->proxy = g_strdup(attribute_values[i]);
+
+		if (strcasecmp(attribute_names[i], "mmsserver") == 0)
+			entry->mms_server = g_strdup(attribute_values[i]);
+	}
+
+	/*
+	 * Match MNC as integers, since settings files often do not
+	 * always contain leading zeros in MNC values...
+	 */
+	if (mcc != NULL && strcmp(mcc, parser->mcc) == 0 &&
+		mnc != NULL && atoi(mnc) == atoi(parser->mnc) &&
+		entry->type != 0 && entry->name != NULL) {
+		DBG("Settings candidate: %s", entry->name);
+		parser->candidates = g_slist_append(parser->candidates, entry);
+	} else {
+		gprs_access_settings_free(entry);
+	}
+}
+
+/*
+ * Returns list of candidate settings matching mcc/mnc from operator
+ * settings file
+ */
+static GSList *read_settings_file(const char *filename,
+					const char *mcc, const char *mnc)
+{
+	gchar *contents = NULL;
+	gsize length;
+	GMarkupParseContext *context;
+
+	struct parser_data parser = {0};
+	GMarkupParser settings_parser = {
+		settings_start_element_handler,
+		NULL,
+		NULL,
+		NULL,
+		NULL
+	};
+
+	if (filename == NULL || mcc == NULL || mnc == NULL)
+		return NULL;
+
+	if (g_file_get_contents(filename, &contents, &length, NULL) == FALSE) {
+		DBG("Error reading settings file %s", filename);
+		return NULL;
+	}
+
+	DBG("Reading settings file %s", filename);
+
+	parser.mcc = mcc;
+	parser.mnc = mnc;
+
+	context = g_markup_parse_context_new(&settings_parser, 0,
+						&parser, NULL);
+
+	if (g_markup_parse_context_parse(context, contents,
+						length, NULL) == FALSE) {
+		DBG("Error parsing XML file %s", filename);
+	}
+
+	g_markup_parse_context_free(context);
+	g_free(contents);
+
+	return parser.candidates;
+}
+
+/* Case insensitive match of type and SPN (if provided) */
+static gboolean is_match(struct gprs_access_settings *entry,
+				enum ofono_gprs_context_type type,
+				gchar *spn_casefold)
+{
+	gboolean ret = FALSE;
+	gchar *entryspn_casefold = NULL;
+
+	if (entry->spn != NULL && strlen(entry->spn) > 0)
+		entryspn_casefold = g_utf8_casefold(entry->spn, -1);
+
+	if (type == entry->type) {
+		if (spn_casefold != NULL) {
+			if (entryspn_casefold &&
+					strcmp(spn_casefold,
+						entryspn_casefold) == 0) {
+				ret = TRUE;
+			}
+		} else {
+			ret = TRUE;
+		}
+	}
+
+	g_free(entryspn_casefold);
+	return ret;
+}
+
+/*
+ * Find best match from candidate settings based on type and SPN
+ * If there is no candidate matching SPN, take first one matching type.
+ */
+static GSList *match_entry(GSList * candidates,
+				enum ofono_gprs_context_type type,
+				const char *spn)
+{
+	GSList *ret = NULL;
+	GSList *lp = candidates;
+	gchar *spn_casefold = NULL;
+
+	if (spn != NULL && strlen(spn) > 0)
+		spn_casefold = g_utf8_casefold(spn, -1);
+
+	while (lp) {
+		struct gprs_access_settings *entry = lp->data;
+		if (is_match(entry, type, spn_casefold)) {
+			ret = lp;
+			break;
+		}
+
+		lp = lp->next;
+		if (lp == NULL && spn_casefold != NULL) {
+			/* No SPN matches, retry with only type */
+			g_free(spn_casefold);
+			spn_casefold = NULL;
+			lp = candidates;
+		}
+	}
+
+	g_free(spn_casefold);
+	return ret;
+}
+
+/*
+ * Returns GPRS context settings (internet and mms types) based on
+ * SIM provided MCC,MNC and Service Provider Name values.
+ * Operator settings for Internet and MMS access points are stored
+ * in XML formatted files (*.xml) under $CONDIFDIR/operator-settings
+ */
+GSList *get_operator_settings(const char *mcc, const char *mnc, const char *spn)
+{
+	GSList *ret = NULL;
+	GSList *candidates = NULL;
+	GSList *match;
+	GDir *dir;
+	GSList *files = NULL, *lp;
+	const gchar *filename;
+
+	dir = g_dir_open(CONFIGDIR "/" SETTING_FILE_DIR, 0, NULL);
+	if (dir == NULL) {
+		DBG("Error opening settings directory");
+		return NULL;
+	}
+
+	while ((filename = g_dir_read_name(dir)) != NULL) {
+		if (g_str_has_suffix(filename, ".xml")) {
+			gchar *fn = g_build_filename(CONFIGDIR,
+							SETTING_FILE_DIR,
+							filename, NULL);
+			files = g_slist_append(files, fn);
+		}
+	}
+
+	/* Read files in consistent order */
+	files = g_slist_sort(files, (GCompareFunc) g_strcmp0);
+	for (lp = files; lp != NULL; lp = lp->next) {
+		GSList *entries;
+		gchar *fn = lp->data;
+		entries = read_settings_file(fn, mcc, mnc);
+		candidates = g_slist_concat(candidates, entries);
+		g_free(fn);
+	}
+
+	g_slist_free(files);
+	g_dir_close(dir);
+
+	match = match_entry(candidates, OFONO_GPRS_CONTEXT_TYPE_INTERNET, spn);
+	if (match != NULL) {
+		candidates = g_slist_remove_link(candidates, match);
+		ret = g_slist_concat(ret, match);
+	}
+
+	match = match_entry(candidates, OFONO_GPRS_CONTEXT_TYPE_MMS, spn);
+	if (match != NULL) {
+		candidates = g_slist_remove_link(candidates, match);
+		ret = g_slist_concat(ret, match);
+	}
+
+	g_slist_foreach(candidates, (GFunc) gprs_access_settings_free, NULL);
+	g_slist_free(candidates);
+
+	return ret;
+}
diff --git a/src/operator-settings.h b/src/operator-settings.h
new file mode 100644
index 0000000..9725eb6
--- /dev/null
+++ b/src/operator-settings.h
@@ -0,0 +1,37 @@
+/*
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2009-2011 Nokia Corporation and/or its subsidiary(-ies).
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#define SETTING_FILE_DIR "operator-settings"
+
+struct gprs_access_settings {
+	enum ofono_gprs_context_type type;
+	gchar *name;
+	gchar *apn;
+	gchar *username;
+	gchar *password;
+	enum ofono_gprs_proto proto;
+	gchar *proxy;
+	gchar *mms_server;
+	gchar *spn;
+};
+
+GSList *get_operator_settings(const char *mcc, const char *mnc,
+				const char *spn);
+void gprs_access_settings_free(struct gprs_access_settings *settings);
-- 
1.7.1

[RFC PATCHv2 3/4] gprs: add automatic context settings provisioning

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 6330 bytes --]

---
 src/gprs.c |  176 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 162 insertions(+), 14 deletions(-)

diff --git a/src/gprs.c b/src/gprs.c
index 58166f8..c9d4fb3 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -43,6 +43,9 @@
 #include "common.h"
 #include "storage.h"
 #include "idmap.h"
+#include "util.h"
+#include "simutil.h"
+#include "operator-settings.h"
 
 #define GPRS_FLAG_ATTACHING 0x1
 #define GPRS_FLAG_RECHECK 0x2
@@ -2261,6 +2264,84 @@ static void netreg_watch(struct ofono_atom *atom,
 	gprs_netreg_update(gprs);
 }
 
+static gboolean provision_contexts(struct ofono_gprs *gprs,
+					const char *mcc,
+					const char *mnc,
+					const char *spn)
+{
+	gboolean ret = FALSE;
+	GSList *settings, *sp;
+
+	settings = get_operator_settings(mcc, mnc, spn);
+
+	for (sp = settings; sp != NULL; sp = sp->next) {
+		unsigned int id;
+		struct pri_context *context = NULL;
+		struct gprs_access_settings *ap = sp->data;
+
+		/* Sanity check */
+		if (ap == NULL || ap->name == NULL) {
+			sp = sp->next;
+			continue;
+		}
+
+		if (gprs->last_context_id)
+			id = idmap_alloc_next(gprs->pid_map,
+						gprs->last_context_id);
+		else
+			id = idmap_alloc(gprs->pid_map);
+
+		if (id > idmap_get_max(gprs->pid_map))
+			break;
+
+		context = pri_context_create(gprs, ap->name, ap->type);
+		DBG("Provisioned context %d '%s' %s", id, ap->name,
+			context ? "created" : "creation failed");
+
+		if (context == NULL)
+			continue;
+
+		context->id = id;
+
+		if (ap->username != NULL)
+			strncpy(context->context.username, ap->username,
+				OFONO_GPRS_MAX_USERNAME_LENGTH);
+
+		if (ap->password != NULL)
+			strncpy(context->context.password, ap->password,
+				OFONO_GPRS_MAX_PASSWORD_LENGTH);
+
+		if (ap->apn != NULL)
+			strncpy(context->context.apn, ap->apn,
+				OFONO_GPRS_MAX_APN_LENGTH);
+
+		context->context.proto = ap->proto;
+
+		if (ap->type == OFONO_GPRS_CONTEXT_TYPE_MMS &&
+			ap->proxy != NULL)
+			strncpy(context->message_proxy, ap->proxy,
+				MAX_MESSAGE_PROXY_LENGTH);
+
+		if (ap->type == OFONO_GPRS_CONTEXT_TYPE_MMS &&
+			ap->mms_server != NULL)
+			strncpy(context->message_center, ap->mms_server,
+				MAX_MESSAGE_CENTER_LENGTH);
+
+		if (context_dbus_register(context) == TRUE) {
+			gprs->last_context_id = id;
+			gprs->contexts = g_slist_append(gprs->contexts,
+							context);
+			write_context_settings(gprs, context);
+			ret = TRUE;
+		}
+	}
+
+	g_slist_foreach(settings, (GFunc) gprs_access_settings_free, NULL);
+	g_slist_free(settings);
+
+	return ret;
+}
+
 static gboolean load_context(struct ofono_gprs *gprs, const char *group)
 {
 	char *name = NULL;
@@ -2454,13 +2535,16 @@ remove:
 		storage_sync(imsi, SETTINGS_STORE, gprs->settings);
 }
 
-void ofono_gprs_register(struct ofono_gprs *gprs)
+static void ofono_gprs_finish_register(struct ofono_gprs *gprs)
 {
+
 	DBusConnection *conn = ofono_dbus_get_connection();
 	struct ofono_modem *modem = __ofono_atom_get_modem(gprs->atom);
 	const char *path = __ofono_atom_get_path(gprs->atom);
 	struct ofono_atom *netreg_atom;
-	struct ofono_atom *sim_atom;
+
+	if (gprs->contexts == NULL) /* Automatic provisioning failed */
+		add_context(gprs, NULL, OFONO_GPRS_CONTEXT_TYPE_INTERNET);
 
 	if (!g_dbus_register_interface(conn, path,
 					OFONO_CONNECTION_MANAGER_INTERFACE,
@@ -2475,18 +2559,6 @@ void ofono_gprs_register(struct ofono_gprs *gprs)
 	ofono_modem_add_interface(modem,
 				OFONO_CONNECTION_MANAGER_INTERFACE);
 
-	sim_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_SIM);
-
-	if (sim_atom) {
-		struct ofono_sim *sim = __ofono_atom_get_data(sim_atom);
-		const char *imsi = ofono_sim_get_imsi(sim);
-
-		gprs_load_settings(gprs, imsi);
-	}
-
-	if (gprs->contexts == NULL)
-		add_context(gprs, NULL, OFONO_GPRS_CONTEXT_TYPE_INTERNET);
-
 	gprs->netreg_watch = __ofono_modem_add_atom_watch(modem,
 					OFONO_ATOM_TYPE_NETREG,
 					netreg_watch, gprs, NULL);
@@ -2498,6 +2570,82 @@ void ofono_gprs_register(struct ofono_gprs *gprs)
 				OFONO_ATOM_WATCH_CONDITION_REGISTERED, gprs);
 
 	__ofono_atom_register(gprs->atom, gprs_unregister);
+
+}
+
+static void sim_spn_read_cb(int ok, int length, int record,
+				const unsigned char *data,
+				int record_length, void *userdata)
+{
+	struct ofono_gprs *gprs = userdata;
+	char *spn = NULL;
+
+	struct ofono_atom *sim_atom;
+	struct ofono_sim *sim;
+	const char *imsi;
+
+	unsigned char mnc_length;
+	char mcc[OFONO_MAX_MCC_LENGTH + 1];
+	char mnc[OFONO_MAX_MNC_LENGTH + 1];
+
+	struct ofono_modem *modem = __ofono_atom_get_modem(gprs->atom);
+
+	sim_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_SIM);
+	if (sim_atom == NULL)
+		goto finish;
+
+	sim = __ofono_atom_get_data(sim_atom);
+	imsi = ofono_sim_get_imsi(sim);
+	if (imsi == NULL)
+		goto finish;
+
+	mnc_length = ofono_sim_get_mnc_length(sim);
+	if (mnc_length == 0)
+		goto finish;
+
+	strncpy(mcc, imsi, OFONO_MAX_MCC_LENGTH);
+	mcc[OFONO_MAX_MCC_LENGTH] = '\0';
+	strncpy(mnc, imsi + OFONO_MAX_MCC_LENGTH, mnc_length);
+	mnc[mnc_length] = '\0';
+
+	if (ok)
+		spn = sim_string_to_utf8(data + 1, length - 1);
+
+	/* TODO: if SPN is missing/empty, use operator name mapped from
+	   mcc/mnc (when implemented in oFono) */
+
+	DBG("MCC %s, MNC %s, SPN %s", mcc, mnc, spn);
+	provision_contexts(gprs, mcc, mnc, spn);
+	g_free(spn);
+
+finish:
+	ofono_gprs_finish_register(gprs);
+
+}
+
+void ofono_gprs_register(struct ofono_gprs *gprs)
+{
+	struct ofono_modem *modem = __ofono_atom_get_modem(gprs->atom);
+	struct ofono_atom *sim_atom;
+	struct ofono_sim *sim = NULL;
+
+	sim_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_SIM);
+
+	if (sim_atom != NULL) {
+		const char *imsi = ofono_sim_get_imsi(sim);
+		sim = __ofono_atom_get_data(sim_atom);
+		gprs_load_settings(gprs, imsi);
+	}
+
+	if (gprs->contexts == NULL && sim != NULL) {
+		/* Try reading SPN for automatic context provisioning */
+		ofono_sim_read(sim, SIM_EFSPN_FILEID,
+				OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
+				sim_spn_read_cb, gprs);
+		return;
+	}
+
+	ofono_gprs_finish_register(gprs);
 }
 
 void ofono_gprs_remove(struct ofono_gprs *gprs)
-- 
1.7.1

[RFC PATCHv2 4/4] operator-settings: Example GPRS context settings file

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

---
 examples/example-operator-settings.xml |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)
 create mode 100644 examples/example-operator-settings.xml

diff --git a/examples/example-operator-settings.xml b/examples/example-operator-settings.xml
new file mode 100644
index 0000000..8927656
--- /dev/null
+++ b/examples/example-operator-settings.xml
@@ -0,0 +1,15 @@
+<?xml version="1.0"?>
+<!--
+   Example GPRS access point settings.
+   <access>-element must contain required attributes type="internet"|"mms",
+     mcc, mnc and name.
+   others: spn (Service Provider Name from SIM), apn (GPRS Access Point Name),
+     protocol="ipv4"|"ipv6" (others may be added), username, password, 
+     proxy (as "address:port", for now mms only), mmsserver (as http-url, 
+     mms only).
+-->
+
+<settings>
+<access type="internet" mcc="246" mnc="81" spn="oFono" name="Phonesim Internet-GPRS" apn="internet.apn"/>
+<access type="mms" mcc="246" mnc="81" spn="oFono" name="Phonesim MMS-GPRS" apn="mms.apn" protocol="ipv4" username="mmsuser" password="mmspass" proxy="10.11.12.13:8080" mmsserver="http://mms.example.com:8000"/>
+</settings>
-- 
1.7.1

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Kalle Valo]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

Jukka Saunamaki <jukka.saunamaki@nokia.com> writes:

> Hello

Moi Jukka,

> Settings database is an XML formatted file (combination of all
> xml-files in a directory), containing one element per settings for a
> specific type of GPRS context (internet, mms)

> Example:
> <?xml version="1.0"?>
> <settings>
> <access type="internet" mcc="246" mnc="81" spn="oFono" name="Phonesim Internet-GPRS" apn="internet.apn"/>
> <access type="mms" mcc="246" mnc="81" spn="oFono" name="Phonesim MMS-GPRS" apn="mms.apn" protocol="ipv4" username="mmsuser" password="mmspass" proxy="10.11.12.13:8080" mmsserver="http://mms.example.com:8000"/>
> </settings>

The format here doesn't look very extensible to me, more like csv with
steroids and not proper xml. Any particular reason why you can't use the
same format as in mobile-broadband-provider-info?

http://git.gnome.org/browse/mobile-broadband-provider-info/tree/serviceproviders.xml

-- 
Kalle Valo

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

Hello

On Mon, 2011-01-03 at 10:57 +0200, Kalle Valo wrote:
> Jukka Saunamaki <jukka.saunamaki@nokia.com> writes:
> > Settings database is an XML formatted file (combination of all
> > xml-files in a directory), containing one element per settings for a
> > specific type of GPRS context (internet, mms)
> 
> > Example:
> > <?xml version="1.0"?>
> > <settings>
> > <access type="internet" mcc="246" mnc="81" spn="oFono" name="Phonesim Internet-GPRS" apn="internet.apn"/>
> > <access type="mms" mcc="246" mnc="81" spn="oFono" name="Phonesim MMS-GPRS" apn="mms.apn" protocol="ipv4" username="mmsuser" password="mmspass" proxy="10.11.12.13:8080" mmsserver="http://mms.example.com:8000"/>
> > </settings>
> 
> The format here doesn't look very extensible to me, more like csv with
> steroids and not proper xml. Any particular reason why you can't use the
> same format as in mobile-broadband-provider-info?
> 
> http://git.gnome.org/browse/mobile-broadband-provider-info/tree/serviceproviders.xml

Well, my intention was to make format simple and fast to parse, but
still be extensible enough, which I think my proposed format fulfills. 

These <access>-elements contain just data needed for GPRS context
settings (as attributes), and if there is need for any other operator
specific provisioning information, you can always add separate elements,
this is still proper XML.

--Jukka
 

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Kalle Valo]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

Jukka Saunamaki <jukka.saunamaki@nokia.com> writes:

> Hello

Moro,

> On Mon, 2011-01-03 at 10:57 +0200, Kalle Valo wrote:
>> Jukka Saunamaki <jukka.saunamaki@nokia.com> writes:
>>
>> > <access type="mms" mcc="246" mnc="81" spn="oFono" name="Phonesim MMS-GPRS" apn="mms.apn" protocol="ipv4" username="mmsuser" password="mmspass" proxy="10.11.12.13:8080" mmsserver="http://mms.example.com:8000"/>
>> > </settings>
>> 
>> The format here doesn't look very extensible to me, more like csv with
>> steroids and not proper xml. Any particular reason why you can't use the
>> same format as in mobile-broadband-provider-info?
>> 
>> http://git.gnome.org/browse/mobile-broadband-provider-info/tree/serviceproviders.xml
>
> Well, my intention was to make format simple and fast to parse, but
> still be extensible enough, which I think my proposed format fulfills. 
>
> These <access>-elements contain just data needed for GPRS context
> settings (as attributes), and if there is need for any other operator
> specific provisioning information, you can always add separate elements,
> this is still proper XML.

But IMHO it is really ugly and not a properly designed XML. You could do
the same even with this style of CSV and have the same extensibility:

type="internet",mcc="246",mnc="81",spn="oFono",\
name="Phonesim Internet-GPRS",pn="internet.apn"

If you want to use XML, why not do it properly? XML parsing can't be
that performance critical. And if it is (to my great surprise), then XML
is not the correct choise for this.

Again, why not use mobile-broadband-provider-info DTD? If there's something
missing, I'm sure maintainers are willing to extend it. No need to
reinvent the wheel.

-- 
Kalle Valo

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

Hi Kalle,

On Mon, 2011-01-03 at 13:40 +0200, ext Kalle Valo wrote:
> If you want to use XML, why not do it properly? XML parsing can't be
> that performance critical. And if it is (to my great surprise), then XML
> is not the correct choise for this.

Many experts would claim proper use of XML means avoiding DTD like the
plague. ;)

> Again, why not use mobile-broadband-provider-info DTD? If there's something
> missing, I'm sure maintainers are willing to extend it. No need to
> reinvent the wheel.

That is a slippery slope. Attempting to standardize here is likely to
make things more complicated in the long run. This is after all an oFono
internal data format that really should avoid any hard dependencies to
external projects.

We are likely to add things like MMS access point information. Is that
relevant for mobile-broadband-provider-info?

Thinking about this more, maybe the best approach is to go with whatever
fits oFono best, keep it private, and come up with the suitable style
sheet magic to be able to reuse the database from m-b-p-info if
necessary.

Cheers,
Aki

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

Hello

> > Well, my intention was to make format simple and fast to parse, but
> > still be extensible enough, which I think my proposed format fulfills. 
> >
> > These <access>-elements contain just data needed for GPRS context
> > settings (as attributes), and if there is need for any other operator
> > specific provisioning information, you can always add separate elements,
> > this is still proper XML.
> 
> But IMHO it is really ugly and not a properly designed XML.

Well, to me it looks simple, compact and clean, and most certainly
provides all necessary extensibility any XML format provides.  

> Again, why not use mobile-broadband-provider-info DTD? If there's something
> missing, I'm sure maintainers are willing to extend it. No need to
> reinvent the wheel.

In this format biggest thing that I see missing is type of access point
("internet","mms","lte"), protocol (for IPv6) and mms-server (or
"homepage"). And I assume <name> of <provider> could be interpreted as
SPN for provisioning.

The good point of using mobile-broadband-provider-info is that it would
indeed provide existing database for testing purposes. For product
creation, manufacturers will anyway create their own databases, and
there the format does not matter much.

The problem using this format is, as I mentioned, more complex parsing. 
And also do we want to bind oFono into some externally defined data
format?

--Jukka
 

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

Hi Jukka,

> > > Well, my intention was to make format simple and fast to parse, but
> > > still be extensible enough, which I think my proposed format fulfills. 
> > >
> > > These <access>-elements contain just data needed for GPRS context
> > > settings (as attributes), and if there is need for any other operator
> > > specific provisioning information, you can always add separate elements,
> > > this is still proper XML.
> > 
> > But IMHO it is really ugly and not a properly designed XML.
> 
> Well, to me it looks simple, compact and clean, and most certainly
> provides all necessary extensibility any XML format provides.  
> 
> > Again, why not use mobile-broadband-provider-info DTD? If there's something
> > missing, I'm sure maintainers are willing to extend it. No need to
> > reinvent the wheel.
> 
> In this format biggest thing that I see missing is type of access point
> ("internet","mms","lte"), protocol (for IPv6) and mms-server (or
> "homepage"). And I assume <name> of <provider> could be interpreted as
> SPN for provisioning.
> 
> The good point of using mobile-broadband-provider-info is that it would
> indeed provide existing database for testing purposes. For product
> creation, manufacturers will anyway create their own databases, and
> there the format does not matter much.

I think we need something in between both formats.

The mobile-broadband-provider-info is too much and too complex from my
point of view. It contains too much details that are not really helping
us if you wanna do provisioning. We need to automate this and can not
really ask the user.

On the other hand, I would prefer a little bit more XML style nesting or
we just use key files right away.

Regards

Marcel

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

Moi,

On Mon, 2011-01-03 at 10:57 +0200, ext Kalle Valo wrote:
> Any particular reason why you can't use the
> same format as in mobile-broadband-provider-info?

I think reusing the format here makes sense, actually. If not for
anything else than to be able to use an existing database for testing.

Cheers,
Aki 

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

Hi Aki,

> > Any particular reason why you can't use the
> > same format as in mobile-broadband-provider-info?
> 
> I think reusing the format here makes sense, actually. If not for
> anything else than to be able to use an existing database for testing.

my thinking was that we should read the MBPI database if present and use
it as much as possible. Since oFono will not ship a database by default
anyway.

However we do need an extensible way of per-operator overrides at least.
And while MBPI database might work on the desktop, I think it will fail
on a mobile phone. The information in it are too desktop centric.

I also have a small problem on how it tries to solve the problem of
virtual providers and/or different contract details. This part of the
database if more designed for UI usage than for system usage.

Regards

Marcel

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Hi Jukka,

> Here is another RFC patchset about implementing automatic provisioning of Internet and MMS GPRS context settings. ("Internet Access Provider database" TODO item).
> 
> In case there are no previously configured contexts found during gprs atom registration, this code tries to provision Internet and MMS contexts based on MCC, MNC and SPN (Service Provider Name) values read from SIM. Settings are read from an operator settings database.

thinking about this a bit more and with the background that there is
already an existing public database, we might should just enable a
provision driver inside the oFono core.

Meaning that we can have multiple implementations of different databases
with just different priorities. Each nicely separated in their own
plugin and we don't bother the oFono core with where to get the data
from. So my idea would be that the oFono core just asks to provision a
new context. If a plugin feels responsible, then it does so. If not then
it stays empty.

Running oFono on the desktop/netbook etc. it makes sense to use the
current mobile broadband provider database. However on a phone that is a
not so good database. And for you guys it would also be possible to
continue using a CSV based format.

Thoughts?

Regards

Marcel

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

Hello Marcel,

On Mon, 2011-01-03 at 15:03 -0800, ext Marcel Holtmann wrote:
> thinking about this a bit more and with the background that there is
> already an existing public database, we might should just enable a
> provision driver inside the oFono core.
> 
> Meaning that we can have multiple implementations of different databases
> with just different priorities. Each nicely separated in their own
> plugin and we don't bother the oFono core with where to get the data
> from. So my idea would be that the oFono core just asks to provision a
> new context. If a plugin feels responsible, then it does so. If not then
> it stays empty.
>
> Running oFono on the desktop/netbook etc. it makes sense to use the
> current mobile broadband provider database. However on a phone that is a
> not so good database. And for you guys it would also be possible to
> continue using a CSV based format.

This sounds very good to me. Making provisioning modular makes a lot of
sense.

But I am not yet very familiar with oFono plugin architecture. Is there
some pattern in oFono code I could follow when implementing this, or
could you or someone provide some skeleton code how this should go?

In my patch (3/4) for gprs.c, I call get_operator_settings() (in
operator-settings.c), which returns list of gprs_access_settings, that
are then created as contexts. I assume now this  get_operator_settings()
would somehow call registered provisioning modules, that similarly would
return list of gprs_access_settings? Or should these plugins directly
call some new gprs atom interface to create the contexts?

--Jukka

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]

Hi Jukka,

> > thinking about this a bit more and with the background that there is
> > already an existing public database, we might should just enable a
> > provision driver inside the oFono core.
> > 
> > Meaning that we can have multiple implementations of different databases
> > with just different priorities. Each nicely separated in their own
> > plugin and we don't bother the oFono core with where to get the data
> > from. So my idea would be that the oFono core just asks to provision a
> > new context. If a plugin feels responsible, then it does so. If not then
> > it stays empty.
> >
> > Running oFono on the desktop/netbook etc. it makes sense to use the
> > current mobile broadband provider database. However on a phone that is a
> > not so good database. And for you guys it would also be possible to
> > continue using a CSV based format.
> 
> This sounds very good to me. Making provisioning modular makes a lot of
> sense.
> 
> But I am not yet very familiar with oFono plugin architecture. Is there
> some pattern in oFono code I could follow when implementing this, or
> could you or someone provide some skeleton code how this should go?
> 
> In my patch (3/4) for gprs.c, I call get_operator_settings() (in
> operator-settings.c), which returns list of gprs_access_settings, that
> are then created as contexts. I assume now this  get_operator_settings()
> would somehow call registered provisioning modules, that similarly would
> return list of gprs_access_settings? Or should these plugins directly
> call some new gprs atom interface to create the contexts?

the oFono plugins work like kernel modules. They are pretty much
generic. Inside the init function you can a driver register function and
inside the exit function, you call the driver unregister function.

We need to discuss some more details here, but something along these
lines should do it:

struct ofono_gprs_provision_driver {
	const char *name,
	int priorty,
	int (*setup_context) (struct ofono_gprs_primary_context *context),
};

int ofono_gprs_provision_driver_register(const struct ofono_gprs_provision_driver *);
void ofono_gprs_provision_driver_unregister(const struct ofono_gprs_provision_driver *);

I am not 100% sure about the naming here, but something along these
lines seems to be the way to go.

Then your specific plugin would look like this:

static int setup_context(struct ofono_gprs_primary_context *context)
{
	...

	return 0;
}

static const ofono_gprs_provision_driver driver {
	.name =	"test",
	.setup_context = setup_context,
};

static int plugin_init(void)
{
	return ofono_gprs_provision_driver_register(&driver);
}

static void plugin_exit(void)
{
	ofono_gprs_provision_driver_unregister(&driver);
}

OFONO_PLUGIN_DEFINE(myplugin, "My provision plugin", VERSION,
	OFONO_PLUGIN_PRIORITY_DEFAULT, plugin_init, plugin_exit)

Regards

Marcel

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Jukka Saunamaki]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

Hello Marcel,

> the oFono plugins work like kernel modules. They are pretty much
> generic. Inside the init function you can a driver register function and
> inside the exit function, you call the driver unregister function.

Right, that seems clear enough.

> static int setup_context(struct ofono_gprs_primary_context *context)
> {
> 	...
> 
> 	return 0;
> }
> 
> static const ofono_gprs_provision_driver driver {
> 	.name =	"test",
> 	.setup_context = setup_context,
> };

I guess that current struct ofono_gprs_primary_context* is not enough
for provisioning data, it is missing at least name, MMS proxy and server
information. Should those (and whatever might be needed in future) be
added into that struct, or should we define some 
struct ofono_gprs_provisioning_data {
	struct ofono_gprs_primary_context pri;
	char name[MAX_CONTEXT_NAME_LENGTH + 1];
	char message_proxy[MAX_MESSAGE_PROXY_LENGTH + 1];
	char message_center[MAX_MESSAGE_CENTER_LENGTH + 1];	
}
struct pri_context in gprs.c contains everything, but has extra
gprs-internal stuff.  

Also setup_context() needs ofono_gprs_context_type as in-parameter.


And a question about the priorities, if there is more than one
provisioning plugin: would plugins be called in priority order, and
after first returns something, rest would not be called?

--Jukka

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

Hi Jukka,

> > the oFono plugins work like kernel modules. They are pretty much
> > generic. Inside the init function you can a driver register function and
> > inside the exit function, you call the driver unregister function.
> 
> Right, that seems clear enough.
> 
> > static int setup_context(struct ofono_gprs_primary_context *context)
> > {
> > 	...
> > 
> > 	return 0;
> > }
> > 
> > static const ofono_gprs_provision_driver driver {
> > 	.name =	"test",
> > 	.setup_context = setup_context,
> > };
> 
> I guess that current struct ofono_gprs_primary_context* is not enough
> for provisioning data, it is missing at least name, MMS proxy and server
> information. Should those (and whatever might be needed in future) be
> added into that struct, or should we define some 
> struct ofono_gprs_provisioning_data {
> 	struct ofono_gprs_primary_context pri;
> 	char name[MAX_CONTEXT_NAME_LENGTH + 1];
> 	char message_proxy[MAX_MESSAGE_PROXY_LENGTH + 1];
> 	char message_center[MAX_MESSAGE_CENTER_LENGTH + 1];	
> }
> struct pri_context in gprs.c contains everything, but has extra
> gprs-internal stuff.  
> 
> Also setup_context() needs ofono_gprs_context_type as in-parameter.

it is just an example and we most likely need a bit more thinking about
it. To be honest, I just spent only 10 minutes on it to give you a brief
idea on how I think this could be done.

> And a question about the priorities, if there is more than one
> provisioning plugin: would plugins be called in priority order, and
> after first returns something, rest would not be called?

Inside oFono we have not used this concept, but inside ConnMan we just
order the drivers by priority. And then call the function in priority
order. If it returns < 0, then we try the next, if it return = 0 then we
stop calling. First one with highest priority wins ;)

We might need to add a probe() and remove() callback to do some basic
detection of the driver pre-constraints. This needs to be figured out as
well.

Regards

Marcel

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Kalle Valo]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Marcel Holtmann <marcel@holtmann.org> writes:

> thinking about this a bit more and with the background that there is
> already an existing public database, we might should just enable a
> provision driver inside the oFono core.
>
> Meaning that we can have multiple implementations of different databases
> with just different priorities. Each nicely separated in their own
> plugin and we don't bother the oFono core with where to get the data
> from. So my idea would be that the oFono core just asks to provision a
> new context. If a plugin feels responsible, then it does so. If not then
> it stays empty.

I like the idea. Simple to implement and we get maximum extensibility.

Are you willing to take a plugin into ofono git which would use
mobile-broadband-provider-info database? Or should people maintain the plugins
out of tree?

For me the best would be to have all plugins in ofono tree and
enable/disable them with configure switches.

-- 
Kalle Valo

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

Hi Kalle,

> > thinking about this a bit more and with the background that there is
> > already an existing public database, we might should just enable a
> > provision driver inside the oFono core.
> >
> > Meaning that we can have multiple implementations of different databases
> > with just different priorities. Each nicely separated in their own
> > plugin and we don't bother the oFono core with where to get the data
> > from. So my idea would be that the oFono core just asks to provision a
> > new context. If a plugin feels responsible, then it does so. If not then
> > it stays empty.
> 
> I like the idea. Simple to implement and we get maximum extensibility.
> 
> Are you willing to take a plugin into ofono git which would use
> mobile-broadband-provider-info database? Or should people maintain the plugins
> out of tree?

in general I would accept any of such plugins into the tree. However we
need to be a bit careful with the priority. And of course they need to
have some sort of usage.

What I expect to see in long term is that we have two or three different
formats. And they just differ because of the different vertical targets.

> For me the best would be to have all plugins in ofono tree and
> enable/disable them with configure switches.

I wanna use priorities and smart detection to use them. Nothing for the
user to configure. Just installing some extra packages should active its
usage. And yes, I want to make it possible to build all plugins at all
time.

Regards

Marcel

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Kalle Valo]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

Marcel Holtmann <marcel@holtmann.org> writes:

>> For me the best would be to have all plugins in ofono tree and
>> enable/disable them with configure switches.
>
> I wanna use priorities and smart detection to use them. Nothing for the
> user to configure. Just installing some extra packages should active its
> usage. And yes, I want to make it possible to build all plugins at all
> time.

Even better, maybe just a bit trickier to implement. But at least
mobile-broadband-provider-info already supports pkgconfig so the
location of the xml should be easy to detect automatically during
configure.

-- 
Kalle Valo

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

Hi Kalle,

> >> For me the best would be to have all plugins in ofono tree and
> >> enable/disable them with configure switches.
> >
> > I wanna use priorities and smart detection to use them. Nothing for the
> > user to configure. Just installing some extra packages should active its
> > usage. And yes, I want to make it possible to build all plugins at all
> > time.
> 
> Even better, maybe just a bit trickier to implement. But at least
> mobile-broadband-provider-info already supports pkgconfig so the
> location of the xml should be easy to detect automatically during
> configure.

so I assume you take yo the task to add support for it once we have the
rest of framework merged.

Regards

Marcel

Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[Kalle Valo]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

Marcel Holtmann <marcel@holtmann.org> writes:

> Hi Kalle,

Hi Marcel,

>> Even better, maybe just a bit trickier to implement. But at least
>> mobile-broadband-provider-info already supports pkgconfig so the
>> location of the xml should be easy to detect automatically during
>> configure.
>
> so I assume you take yo the task to add support for it once we have the
> rest of framework merged.

Sure. But I can't promise when I get the task finished :)

-- 
Kalle Valo

[RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings

[manju krishna]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

Hello,

  This is Manju Krishna working for mPortal.I was going through your
internet uploads regarding the GPRS provisioning.

I would like to have complete code snippnet for activation of GPRS.This
particular information will be great help to me in project.


Regards,
Manju Krishna

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 388 bytes --]