[PATCH 1/2] Fix: Username and Password must be set after context is created.
From: Sjur Brændeland
---
drivers/stemodem/gprs-context.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index 6743aba..c178fb6 100644
--- a/drivers/stemodem/gprs-context.c
+++ b/drivers/stemodem/gprs-context.c
@@ -416,7 +416,7 @@ static void ste_gprs_activate_primary(struct
ofono_gprs_context *gc,
{
struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
struct cb_data *cbd = cb_data_new(cb, data);
- char buf[AUTH_BUF_LENGTH];
+ char buf[2*AUTH_BUF_LENGTH];
int len;
if (!cbd)
@@ -425,19 +425,17 @@ static void ste_gprs_activate_primary(struct
ofono_gprs_context *gc,
gcd->active_context = ctx->cid;
cbd->user = gc;
- /* Set username and password */
- sprintf(buf, "AT*EIAAUW=%d,1,\"%s\",\"%s\"", ctx->cid,
- ctx->username, ctx->password);
-
- if (g_at_chat_send(gcd->chat, buf, none_prefix, NULL, NULL, NULL) == 0)
- goto error;
-
len = sprintf(buf, "AT+CGDCONT=%u,\"IP\"", ctx->cid);
if (ctx->apn)
snprintf(buf + len, sizeof(buf) - len - 3, ",\"%s\"",
ctx->apn);
+ /* Set username and password. Must be done after context creation */
+ len = strlen(buf);
+ sprintf(buf+len, ";*EIAAUW=%d,1,\"%s\",\"%s\"", ctx->cid,
+ ctx->username, ctx->password);
+
if (g_at_chat_send(gcd->chat, buf, none_prefix,
ste_cgdcont_cb, cbd, g_free) > 0)
return;
--
1.6.3.3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 2/2] Fix: Check if interface exists before creating it.
From: Sjur Brændeland
---
drivers/stemodem/gprs-context.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index c178fb6..79e697b 100644
--- a/drivers/stemodem/gprs-context.c
+++ b/drivers/stemodem/gprs-context.c
@@ -187,9 +187,11 @@ static gboolean caif_if_create(const char *interface,
unsigned int connid)
return FALSE;
}
- if (ioctl(s, SIOCCAIFNETNEW, &ifr) < 0) {
- ofono_debug("Failed to create IP interface for CAIF");
- return FALSE;
+ if (ioctl(s, SIOCGIFINDEX, &ifr) != 0) {
+ if (ioctl(s, SIOCCAIFNETNEW, &ifr) < 0) {
+ ofono_debug("Failed to create IP interface for CAIF");
+ return FALSE;
+ }
}
return TRUE;
--
1.6.3.3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/2] Fix: Check if interface exists before creating it.
Hi Sjur,
> diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
> index c178fb6..79e697b 100644
> --- a/drivers/stemodem/gprs-context.c
> +++ b/drivers/stemodem/gprs-context.c
> @@ -187,9 +187,11 @@ static gboolean caif_if_create(const char *interface,
> unsigned int connid)
> return FALSE;
> }
>
> - if (ioctl(s, SIOCCAIFNETNEW, &ifr) < 0) {
> - ofono_debug("Failed to create IP interface for CAIF");
> - return FALSE;
> + if (ioctl(s, SIOCGIFINDEX, &ifr) != 0) {
> + if (ioctl(s, SIOCCAIFNETNEW, &ifr) < 0) {
> + ofono_debug("Failed to create IP interface for CAIF");
> + return FALSE;
> + }
> }
>
> return TRUE;
just doing it like this would be better:
/* Check if interface exists */
if (ioctl(s, SIOCGIFINDEX, &ifr) == 0)
return TRUE;
if (ioctl(s, SIOCCAIFNETNEW, &ifr) < 0) {
...
return FALSE;
}
return TRUE;
We are not a big fan complicated if clauses if they can be avoid with a
simple goto or just a return.
Also I think we need to check errno value here. Since potentially the
ioctl can fail for other reasons. And maybe extending CAIF with a proper
way of checking for an existing interface might be better.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/2] Fix: Username and Password must be set after context is created.
Hi Sjur,
> diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
> index 6743aba..c178fb6 100644
> --- a/drivers/stemodem/gprs-context.c
> +++ b/drivers/stemodem/gprs-context.c
> @@ -416,7 +416,7 @@ static void ste_gprs_activate_primary(struct
> ofono_gprs_context *gc,
> {
> struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
> struct cb_data *cbd = cb_data_new(cb, data);
> - char buf[AUTH_BUF_LENGTH];
> + char buf[2*AUTH_BUF_LENGTH];
> int len;
>
> if (!cbd)
> @@ -425,19 +425,17 @@ static void ste_gprs_activate_primary(struct
> ofono_gprs_context *gc,
> gcd->active_context = ctx->cid;
> cbd->user = gc;
>
> - /* Set username and password */
> - sprintf(buf, "AT*EIAAUW=%d,1,\"%s\",\"%s\"", ctx->cid,
> - ctx->username, ctx->password);
> -
> - if (g_at_chat_send(gcd->chat, buf, none_prefix, NULL, NULL, NULL) == 0)
> - goto error;
> -
> len = sprintf(buf, "AT+CGDCONT=%u,\"IP\"", ctx->cid);
>
> if (ctx->apn)
> snprintf(buf + len, sizeof(buf) - len - 3, ",\"%s\"",
> ctx->apn);
>
> + /* Set username and password. Must be done after context creation */
> + len = strlen(buf);
> + sprintf(buf+len, ";*EIAAUW=%d,1,\"%s\",\"%s\"", ctx->cid,
> + ctx->username, ctx->password);
> +
> if (g_at_chat_send(gcd->chat, buf, none_prefix,
> ste_cgdcont_cb, cbd, g_free) > 0)
> return;
this looks pretty much complicated and I prefer we don't use this crazy
concat of AT commands. Also it violates the coding style.
There is no problem to just use g_at_chat_send twice since it will queue
the commands for you properly. However if this really depends on CGDCONT
succeeding, then we better do it in the callback.
And we might wanna check if MBM cards behave similar and ensure that STE
and MBM cards use a similar code flow.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
2010/1/29 João Paulo Rechi Vita : > Hi all, > > I'm trying to add support for the Handsfree Gateway role Gustavo just added > to BlueZ and oFono. The BlueZ patches can be found on [1] and [2] and the > oFono part was just merged upstream. > > But when it comes to integrate them with Pulse, I'm getting a POLLHUP when > trying to write on the fd. Also, it seems different gateways have different > behaviours regarding when they connect the SCO link. Some phone connect > them just after the RFCOMM link (some Nokia phones), when there is no call > going on yet, and others just when a call is started (Android 1.5). > > Also, right now the same property (State) is beeing used to refer when the > RFCOOM link is established (State=Connected) and when the SCO link is > established (State=Playing). Shouldn't this be handled by separate props? > > And last but not least, is the new Media API intended to handle the audio > part of handsfree gateways too? If so, maybe we should use all this work > as a prototype for latter integration with the new API. > > Any help on testing and getting this working together or comments on the > topic would be appreciated. > > [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html > [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html > > -- > João Paulo Rechi Vita > http://jprvita.wordpress.com/ > > Just updating, this patch actually worked when testing with a different adapter (Fujitsu-Siemens CSR-based). The adapter causing problems was a Broadcom 2.1, the internal adapter of a Dell Mini10. Also, suspending the source / sink actually doesn't interfere. I did a small video of the whole stuff: http://www.vimeo.com/9078799 There are still some problems when testing against Nokia N900 and 2660. After the "enable-modem" step, the RFCOMM link is connected and the SCO just after that, leading module-bluetooth-discover to load module-bluetooth-device. Sometimes after that the polling on the stream fd get a POLLHUP and the module-bluetooth-device unloads itself. Other times the POLLHUP doesn't happen and the remaining steps go without any problem. Ideas on how to improve this scenario will be very helpful. -- João Paulo Rechi Vita http://jprvita.wordpress.com/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] hfp: create modem for new devices paired on runtime
It listens the Paired property to create a modem to the recently paired
devices.
---
plugins/hfp.c | 60 -
1 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/plugins/hfp.c b/plugins/hfp.c
index 0e2e359..2141078 100644
--- a/plugins/hfp.c
+++ b/plugins/hfp.c
@@ -594,6 +594,55 @@ static gboolean adapter_added(DBusConnection *connection,
DBusMessage *message,
return TRUE;
}
+static gboolean paired_added(DBusConnection *connection, DBusMessage *message,
+ void *user_data)
+{
+ DBusError err;
+ const char *device, *paired;
+ DBusMessageIter iter, variant;
+ int ret, value;
+
+ dbus_error_init(&err);
+
+ if (dbus_message_get_args(message, &err, DBUS_TYPE_STRING,
+&paired, DBUS_TYPE_INVALID) == FALSE) {
+ if (dbus_error_is_set(&err) == TRUE) {
+ ofono_error("%s", err.message);
+ dbus_error_free(&err);
+ }
+
+ return FALSE;
+ }
+
+ if (strcmp(paired, "Paired"))
+ return TRUE;
+
+ dbus_message_iter_init(message, &iter);
+ if (dbus_message_iter_get_arg_type(&iter) == DBUS_TYPE_STRING) {
+
+ if (!dbus_message_iter_next(&iter))
+ return FALSE;
+
+ dbus_message_iter_recurse(&iter, &variant);
+ dbus_message_iter_get_basic(&variant, &value);
+
+ if (!value)
+ return TRUE;
+ }
+
+ device = dbus_message_get_path(message);
+ ret = send_method_call(BLUEZ_SERVICE, device,
+ BLUEZ_DEVICE_INTERFACE, "GetProperties",
+ get_properties_cb, (void *)device,
+ DBUS_TYPE_INVALID);
+ if (ret < 0) {
+ ofono_error("GetProperties failed(%d)", ret);
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
static void list_adapters_cb(DBusPendingCall *call, gpointer user_data)
{
DBusError err;
@@ -802,6 +851,7 @@ static struct ofono_modem_driver hfp_driver = {
};
static guint added_watch;
+static guint paired_watch;
static int hfp_init(void)
{
@@ -817,7 +867,13 @@ static int hfp_init(void)
"AdapterAdded",
adapter_added, NULL, NULL);
- if (added_watch == 0) {
+ paired_watch = g_dbus_add_signal_watch(connection, NULL, NULL,
+ BLUEZ_DEVICE_INTERFACE,
+ "PropertyChanged",
+ paired_added, NULL, NULL);
+
+
+ if (added_watch == 0 || paired_watch == 0) {
err = -EIO;
goto remove;
}
@@ -832,6 +888,7 @@ static int hfp_init(void)
remove:
g_dbus_remove_watch(connection, added_watch);
+ g_dbus_remove_watch(connection, paired_watch);
dbus_connection_unref(connection);
@@ -841,6 +898,7 @@ remove:
static void hfp_exit(void)
{
g_dbus_remove_watch(connection, added_watch);
+ g_dbus_remove_watch(connection, paired_watch);
ofono_modem_driver_unregister(&hfp_driver);
}
--
1.6.4.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] hfp: create modem for new devices paired on runtime
Hi Gustavo,
> It listens the Paired property to create a modem to the recently paired
> devices.
> ---
> plugins/hfp.c | 60
> - 1 files
changed,
> 59 insertions(+), 1 deletions(-)
>
> diff --git a/plugins/hfp.c b/plugins/hfp.c
> index 0e2e359..2141078 100644
> --- a/plugins/hfp.c
> +++ b/plugins/hfp.c
> @@ -594,6 +594,55 @@ static gboolean adapter_added(DBusConnection
> *connection, DBusMessage *message, return TRUE;
> }
>
> +static gboolean paired_added(DBusConnection *connection, DBusMessage
> *message, + void *user_data)
> +{
> + DBusError err;
> + const char *device, *paired;
> + DBusMessageIter iter, variant;
> + int ret, value;
> +
> + dbus_error_init(&err);
> +
> + if (dbus_message_get_args(message, &err, DBUS_TYPE_STRING,
> + &paired, DBUS_TYPE_INVALID) == FALSE) {
> + if (dbus_error_is_set(&err) == TRUE) {
> + ofono_error("%s", err.message);
> + dbus_error_free(&err);
> + }
> +
> + return FALSE;
> + }
> +
> + if (strcmp(paired, "Paired"))
> + return TRUE;
> +
> + dbus_message_iter_init(message, &iter);
Why can't we do something like?
dbus_message_iter_init();
if (dbus_message_iter_get_arg_type(&iter) != STRING)
return;
dbus_message_iter_get_basic(&iter, &property);
if (g_str_equal(property, "Paired") == FALSE)
return;
I really don't like mixing the two ways of parsing the message and this way
seems cleaner.
> + if (dbus_message_iter_get_arg_type(&iter) == DBUS_TYPE_STRING) {
> +
> + if (!dbus_message_iter_next(&iter))
> + return FALSE;
> +
> + dbus_message_iter_recurse(&iter, &variant);
> + dbus_message_iter_get_basic(&variant, &value);
> +
> + if (!value)
> + return TRUE;
> + }
You might want to check the second argument is indeed a DBUS_TYPE_VARIANT and
the value of the variant is what you're expecting.
We really need to make a function for this in gdbus.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH] hfp: create modem for new devices paired on runtime
It listens the Paired property to create a modem to the recently paired
devices.
---
plugins/hfp.c | 68 -
1 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/plugins/hfp.c b/plugins/hfp.c
index 0e2e359..92b6be4 100644
--- a/plugins/hfp.c
+++ b/plugins/hfp.c
@@ -594,6 +594,63 @@ static gboolean adapter_added(DBusConnection *connection,
DBusMessage *message,
return TRUE;
}
+static gboolean paired_added(DBusConnection *connection, DBusMessage *message,
+ void *user_data)
+{
+ DBusError err;
+ const char *device, *property;
+ DBusMessageIter iter, variant;
+ int ret, value;
+
+ dbus_error_init(&err);
+
+ if (dbus_message_get_args(message, &err, DBUS_TYPE_STRING,
+&property, DBUS_TYPE_INVALID) == FALSE) {
+ if (dbus_error_is_set(&err) == TRUE) {
+ ofono_error("%s", err.message);
+ dbus_error_free(&err);
+ }
+
+ return FALSE;
+ }
+
+ dbus_message_iter_init(message, &iter);
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_STRING)
+ return FALSE;
+
+ if (g_str_equal(property, "Paired") == FALSE)
+ return TRUE;
+
+ if (!dbus_message_iter_next(&iter))
+ return FALSE;
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_VARIANT)
+ return FALSE;
+
+ dbus_message_iter_recurse(&iter, &variant);
+
+ if (dbus_message_iter_get_arg_type(&variant) != DBUS_TYPE_BOOLEAN)
+ return FALSE;
+
+ dbus_message_iter_get_basic(&variant, &value);
+
+ if (!value)
+ return TRUE;
+
+ device = dbus_message_get_path(message);
+ ret = send_method_call(BLUEZ_SERVICE, device,
+ BLUEZ_DEVICE_INTERFACE, "GetProperties",
+ get_properties_cb, (void *)device,
+ DBUS_TYPE_INVALID);
+ if (ret < 0) {
+ ofono_error("GetProperties failed(%d)", ret);
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
static void list_adapters_cb(DBusPendingCall *call, gpointer user_data)
{
DBusError err;
@@ -802,6 +859,7 @@ static struct ofono_modem_driver hfp_driver = {
};
static guint added_watch;
+static guint paired_watch;
static int hfp_init(void)
{
@@ -817,7 +875,13 @@ static int hfp_init(void)
"AdapterAdded",
adapter_added, NULL, NULL);
- if (added_watch == 0) {
+ paired_watch = g_dbus_add_signal_watch(connection, NULL, NULL,
+ BLUEZ_DEVICE_INTERFACE,
+ "PropertyChanged",
+ paired_added, NULL, NULL);
+
+
+ if (added_watch == 0 || paired_watch == 0) {
err = -EIO;
goto remove;
}
@@ -832,6 +896,7 @@ static int hfp_init(void)
remove:
g_dbus_remove_watch(connection, added_watch);
+ g_dbus_remove_watch(connection, paired_watch);
dbus_connection_unref(connection);
@@ -841,6 +906,7 @@ remove:
static void hfp_exit(void)
{
g_dbus_remove_watch(connection, added_watch);
+ g_dbus_remove_watch(connection, paired_watch);
ofono_modem_driver_unregister(&hfp_driver);
}
--
1.6.4.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH] hfp: create modem for new devices paired on runtime
It listens the Paired property to create a modem to the recently paired
devices.
---
plugins/hfp.c | 56 +++-
1 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/plugins/hfp.c b/plugins/hfp.c
index 0e2e359..05d79cb 100644
--- a/plugins/hfp.c
+++ b/plugins/hfp.c
@@ -594,6 +594,51 @@ static gboolean adapter_added(DBusConnection *connection,
DBusMessage *message,
return TRUE;
}
+static gboolean paired_added(DBusConnection *connection, DBusMessage *message,
+ void *user_data)
+{
+ const char *device, *property;
+ DBusMessageIter iter, variant;
+ int ret, value;
+
+ dbus_message_iter_init(message, &iter);
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_STRING)
+ return FALSE;
+
+ dbus_message_iter_get_basic(&iter, &property);
+ if (g_str_equal(property, "Paired") == FALSE)
+ return TRUE;
+
+ if (!dbus_message_iter_next(&iter))
+ return FALSE;
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_VARIANT)
+ return FALSE;
+
+ dbus_message_iter_recurse(&iter, &variant);
+
+ if (dbus_message_iter_get_arg_type(&variant) != DBUS_TYPE_BOOLEAN)
+ return FALSE;
+
+ dbus_message_iter_get_basic(&variant, &value);
+
+ if (!value)
+ return TRUE;
+
+ device = dbus_message_get_path(message);
+ ret = send_method_call(BLUEZ_SERVICE, device,
+ BLUEZ_DEVICE_INTERFACE, "GetProperties",
+ get_properties_cb, (void *)device,
+ DBUS_TYPE_INVALID);
+ if (ret < 0) {
+ ofono_error("GetProperties failed(%d)", ret);
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
static void list_adapters_cb(DBusPendingCall *call, gpointer user_data)
{
DBusError err;
@@ -802,6 +847,7 @@ static struct ofono_modem_driver hfp_driver = {
};
static guint added_watch;
+static guint paired_watch;
static int hfp_init(void)
{
@@ -817,7 +863,13 @@ static int hfp_init(void)
"AdapterAdded",
adapter_added, NULL, NULL);
- if (added_watch == 0) {
+ paired_watch = g_dbus_add_signal_watch(connection, NULL, NULL,
+ BLUEZ_DEVICE_INTERFACE,
+ "PropertyChanged",
+ paired_added, NULL, NULL);
+
+
+ if (added_watch == 0 || paired_watch == 0) {
err = -EIO;
goto remove;
}
@@ -832,6 +884,7 @@ static int hfp_init(void)
remove:
g_dbus_remove_watch(connection, added_watch);
+ g_dbus_remove_watch(connection, paired_watch);
dbus_connection_unref(connection);
@@ -841,6 +894,7 @@ remove:
static void hfp_exit(void)
{
g_dbus_remove_watch(connection, added_watch);
+ g_dbus_remove_watch(connection, paired_watch);
ofono_modem_driver_unregister(&hfp_driver);
}
--
1.6.4.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/2] Fix: Username and Password must be set after context is created.
Hi Sjur, > >>len = sprintf(buf, "AT+CGDCONT=%u,\"IP\"", ctx->cid); > >> > >>if (ctx->apn) > >>snprintf(buf + len, sizeof(buf) - len - 3, ",\"%s\"", > >> ctx->apn); > >> > >> + /* Set username and password. Must be done after context creation */ > >> + len = strlen(buf); > >> + sprintf(buf+len, ";*EIAAUW=%d,1,\"%s\",\"%s\"", ctx->cid, > >> + ctx->username, ctx->password); > >> + > >>if (g_at_chat_send(gcd->chat, buf, none_prefix, > >>ste_cgdcont_cb, cbd, g_free) > 0) > >>return; > > > > this looks pretty much complicated and I prefer we don't use this > > crazy concat of AT commands. Also it violates the coding style. > > > > There is no problem to just use g_at_chat_send twice since it will > > queue the commands for you properly. However if this really depends > > on CGDCONT succeeding, then we better do it in the callback. > > We originally did send EIAAUW in the callback, but Denis changed this > because MBM did it EIAAUW before CGDCONT. I know that Denis changed it and it makes sense to keep this in sync. We just don't know about these details. And we have to put comments in the source code to remind us. And to be honest, I am not sure if anybody really tested it. I only know of one public network that requires username/password for their APN. I need to get a SIM card from them once I am back in Germany. > > And we might wanna check if MBM cards behave similar and ensure that > > STE and MBM cards use a similar code flow. > > When testing this EIAAUW fails if there are no prior PDP context on the modem. > Most likely this is the case with the MBM module as well, but I have not > tested this. Then we have to do that in the callback in an extra step. I don't really like it, but seems the way to go. Please send a patch that also changes this for MBM devices. We really wanna keep these in sync. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/2] Fix: Username and Password must be set after context is created.
Hi Marcel, > > > And we might wanna check if MBM cards behave similar and ensure that > > > STE and MBM cards use a similar code flow. > > > > When testing this EIAAUW fails if there are no prior PDP context on the > > modem. Most likely this is the case with the MBM module as well, but I > > have not tested this. > > Then we have to do that in the callback in an extra step. I don't really > like it, but seems the way to go. Please send a patch that also changes > this for MBM devices. We really wanna keep these in sync. Actually the easiest way to do this is simply queue the EIAAUW after the CGDCONT in activate_context. If CGDCONT fails then EIAAUW won't have any effect anyway (but will get executed nevertheless). This is better than worrying about strduping username/password and freeing it in all possible code paths. Regards, -Denis > > Regards > > Marcel > ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 2/2] Fix: Check if interface exists before creating it.
Hi Sjur,
> >> diff --git a/drivers/stemodem/gprs-context.c
> >> b/drivers/stemodem/gprs-context.c index c178fb6..79e697b 100644
> >> --- a/drivers/stemodem/gprs-context.c
> >> +++ b/drivers/stemodem/gprs-context.c
> >> @@ -187,9 +187,11 @@ static gboolean caif_if_create(const char
> >>*interface, unsigned int connid)return FALSE; }
> >>
> >> - if (ioctl(s, SIOCCAIFNETNEW, &ifr) < 0) {
> >> - ofono_debug("Failed to create IP interface for CAIF");
> >> - return FALSE;
> >> + if (ioctl(s, SIOCGIFINDEX, &ifr) != 0) {
> >> + if (ioctl(s, SIOCCAIFNETNEW, &ifr) < 0) {
> >> + ofono_debug("Failed to create IP interface for CAIF");
> >> + return FALSE; + }
> >>}
> >>
> >>return TRUE;
> >
> > just doing it like this would be better:
> >
> > /* Check if interface exists */
> > if (ioctl(s, SIOCGIFINDEX, &ifr) == 0)
> > return TRUE;
> >
> > if (ioctl(s, SIOCCAIFNETNEW, &ifr) < 0) {
> > ...
> > return FALSE;
> > }
> >
> > return TRUE;
> >
> > We are not a big fan complicated if clauses if they can be avoid with
> > a simple goto or just a return.
> >
> > Also I think we need to check errno value here. Since potentially the
> > ioctl can fail for other reasons. And maybe extending CAIF with a
> > proper way of checking for an existing interface might be better.
>
> Do you have anything particular in mind here?
> Maybe CAIF could simply return EEXIST from SIOCCAIFNETNEW if the interface
> already exists? In this case we could return TRUE anyway.
if it isn't that doing already, then it should be doing it. And yes,
just returning TRUE in that case seems fine to me.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/2] Fix: Username and Password must be set after context is created.
Hi Denis, > > > > And we might wanna check if MBM cards behave similar and ensure that > > > > STE and MBM cards use a similar code flow. > > > > > > When testing this EIAAUW fails if there are no prior PDP context on the > > > modem. Most likely this is the case with the MBM module as well, but I > > > have not tested this. > > > > Then we have to do that in the callback in an extra step. I don't really > > like it, but seems the way to go. Please send a patch that also changes > > this for MBM devices. We really wanna keep these in sync. > > Actually the easiest way to do this is simply queue the EIAAUW after the > CGDCONT in activate_context. If CGDCONT fails then EIAAUW won't have any > effect anyway (but will get executed nevertheless). This is better than > worrying about strduping username/password and freeing it in all possible > code > paths. sounds good enough to me. Just wanna have STE and MBM in sync here. And of course an extra comment that explain why we do it. Sjur, care to send a patch? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
Hi Jprvita, On 02/02/2010 01:09 AM, João Paulo Rechi Vita wrote: 2010/1/29 João Paulo Rechi Vita: Hi all, I'm trying to add support for the Handsfree Gateway role Gustavo just added to BlueZ and oFono. The BlueZ patches can be found on [1] and [2] and the oFono part was just merged upstream. But when it comes to integrate them with Pulse, I'm getting a POLLHUP when trying to write on the fd. Also, it seems different gateways have different behaviours regarding when they connect the SCO link. Some phone connect them just after the RFCOMM link (some Nokia phones), when there is no call going on yet, and others just when a call is started (Android 1.5). Also, right now the same property (State) is beeing used to refer when the RFCOOM link is established (State=Connected) and when the SCO link is established (State=Playing). Shouldn't this be handled by separate props? And last but not least, is the new Media API intended to handle the audio part of handsfree gateways too? If so, maybe we should use all this work as a prototype for latter integration with the new API. Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html -- João Paulo Rechi Vita http://jprvita.wordpress.com/ Just updating, this patch actually worked when testing with a different adapter (Fujitsu-Siemens CSR-based). The adapter causing problems was a Broadcom 2.1, the internal adapter of a Dell Mini10. Also, suspending the source / sink actually doesn't interfere. I did a small video of the whole stuff: http://www.vimeo.com/907879 Good work! Looks like it works pretty fine. :-). At the last of video, I saw you load loopback module manually. Zheng Huan made a patch to load loopback automatically. I believe Padovan has a copy of that. You may also integrate it with upstream. There are still some problems when testing against Nokia N900 and 2660. After the "enable-modem" step, the RFCOMM link is connected and the SCO just after that, leading module-bluetooth-discover to load module-bluetooth-device. Sometimes after that the polling on the stream fd get a POLLHUP and the module-bluetooth-device unloads itself. Other times the POLLHUP doesn't happen and the remaining steps go without any problem. Ideas on how to improve this scenario will be very helpful. AFAK, the SCO connection request is from AG side and BlueZ will check if no SCO stream comes from AG(??), it will shutdown the connection. In my memory, I don't get POLLHUP event in my original patch. You can turn on debug flag to see more BlueZ output. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] [PATCH 0/2] HFP AG integration with PulseAudio
Hi Jprvita, On 02/02/2010 01:09 AM, João Paulo Rechi Vita wrote: 2010/1/29 João Paulo Rechi Vita: Hi all, I'm trying to add support for the Handsfree Gateway role Gustavo just added to BlueZ and oFono. The BlueZ patches can be found on [1] and [2] and the oFono part was just merged upstream. But when it comes to integrate them with Pulse, I'm getting a POLLHUP when trying to write on the fd. Also, it seems different gateways have different behaviours regarding when they connect the SCO link. Some phone connect them just after the RFCOMM link (some Nokia phones), when there is no call going on yet, and others just when a call is started (Android 1.5). Also, right now the same property (State) is beeing used to refer when the RFCOOM link is established (State=Connected) and when the SCO link is established (State=Playing). Shouldn't this be handled by separate props? And last but not least, is the new Media API intended to handle the audio part of handsfree gateways too? If so, maybe we should use all this work as a prototype for latter integration with the new API. Any help on testing and getting this working together or comments on the topic would be appreciated. [1] http://www.spinics.net/lists/linux-bluetooth/msg04250.html [2] http://www.spinics.net/lists/linux-bluetooth/msg04251.html -- João Paulo Rechi Vita http://jprvita.wordpress.com/ Just updating, this patch actually worked when testing with a different adapter (Fujitsu-Siemens CSR-based). The adapter causing problems was a Broadcom 2.1, the internal adapter of a Dell Mini10. Also, suspending the source / sink actually doesn't interfere. I did a small video of the whole stuff: http://www.vimeo.com/9078799 There are still some problems when testing against Nokia N900 and 2660. After the "enable-modem" step, the RFCOMM link is connected and the SCO just after that, leading module-bluetooth-discover to load module-bluetooth-device. Sometimes after that the polling on the stream fd get a POLLHUP and the module-bluetooth-device unloads itself. Other times the POLLHUP doesn't happen and the remaining steps go without any problem. Ideas on how to improve this scenario will be very helpful. The output from bluetoothd likes below: bluetoothd[21141]: Accepted AG connection from 00:BD:3A:D4:4E:53 for /org/bluez/21141/hci0/dev_00_BD_3A_D4_4E_53 bluetoothd[21141]: Accepted SCO connection from 00:BD:3A:D4:4E:53 bluetoothd[21141]: No matching connection found for handle 6 bluetoothd[21141]: sco connection is released I think you should not load module-bluetooth-device until a voice call is started, no matter incoming or outgoing. Because PA may play music from other device at the same time. And bluetooth-device and loopback module are loaded together. According to HFP v1.5 4.13, there are two cases for incoming call. And outgoing call is simpler than incoming call. If AG and HF both support in band ring tones, we should send a signal from oFono to PA when callsetup=1. If not, we should send it when call=1. I had a patch originally but I cannot find it now. :-(. The basic idea is to add a filter in ciev_notify() to emit signal (CallStarted and CallEnded) to PA. And PA loads module once it got that signal. Maybe the signal name was bad and you could choose better one as you want. ;-) Thanks. Zhenhua ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
How to answer an incoming call
Hi, Now i can use the modem to dial my phone and it can be connected. When I call the modem by my phone, I can't find the path /voicecall01 which has the function answer(). How can I make the path activated to use the answer()? Thanks jasper ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: How to answer an incoming call
On 02/02/2010 02:14 PM, Sun, Yijin wrote: Hi, Now i can use the modem to dial my phone and it can be connected. When I call the modem by my phone, I can’t find the path /voicecall01 which has the function answer(). How can I make the path activated to use the answer() Did you power your modem by ofono/tests/enable-modem? Thanks jasper ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
