[PATCH] qmimodem: fix roaming status report
by Christophe Ronco
Hi,
With a MC7304 modem and a roaming SIM card, Status in org.ofono.NetworkRegistration
properties ends up in "registered" instead of roaming.
Both AT command and qmicli indicates we are roaming.
What's happening is the following:
1) first QMI_NAS_SS_INFO_IND indicating we are registered contains a QMI_NAS_RESULT_ROAMING_STATUS parameter.
Parameter inside says we are roaming and qmimidem driver correctly reports status NETWORK_REGISTRATION_STATUS_ROAMING.
2) other QMI_NAS_SS_INFO_IND arrive, saying we are registered without QMI_NAS_RESULT_ROAMING_STATUS parameter.
Driver reports NETWORK_REGISTRATION_STATUS_REGISTERED.
Extract of traces with QMI binary debug interpreted (as far as I can...):
a) first "searching" indication
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 3b 00 80 03 01 04 00 00 24 00 2f 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
22 05 00 01 02 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_LIMITED, QMI_NAS_NETWORK_SERVICE_DOMAIN_PS, ...
15 03 00 01 08 01 LTE, no roaming
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 01 00 00
10 01 00 01 No roaming
01 06 00 02 02 02 02 01 08 QMI_NAS_REGISTRATION_STATE_NOT_REGISTERED_SEARCHING, CS detached, PS detached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_LTE
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=47 [client=1,type=4,tid=0,len=59]
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=41,len=5} {type=34,len=5} {type=21,len=3} {type=18,len=5}
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=17,len=1} {type=16,len=1} {type=1,len=6}
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 2 lac -1 cellid -1 tech 7
b) second "searching" indication
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 21 00 80 03 01 04 00 00 24 00 15 00
22 05 00 03 03 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_LIMITED_REGIONAL, CS_PS, ...
11 01 00 00
01 06 00 02 02 02 02 01 08 QMI_NAS_REGISTRATION_STATE_NOT_REGISTERED_SEARCHING, CS detached, PS detached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_LTE
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=21 [client=1,type=4,tid=0,len=33]
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=34,len=5} {type=17,len=1} {type=1,len=6}
c) First indication while "registered"
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 5e 00 80 03 01 04 00 00 24 00 52 00
2a 01 00 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
28 02 00 15 01 UMTS Primary Scrambling Code
26 08 00 03 00 00 00 03 00 00 00 CS: all calls allowed, PS: all calls allowed
22 05 00 02 03 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_AVAILABLE, CS_PS, ...
1e 04 00 f7 00 95 04 CID 3GPP
1d 02 00 fb 50 LAC 3GPP
15 03 00 01 05 00 UMTS: roaming
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 04 00 03 03 04 05
10 01 00 00 ROAMING ON
01 06 00 01 01 01 02 01 05 QMI_NAS_REGISTRATION_STATE_REGISTERED, CS attached, PS attached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_UMTS
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=82 [client=1,type=4,tid=0,len=94]
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=42,len=1} {type=41,len=5} {type=40,len=2} {type=38,len=8}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=34,len=5} {type=30,len=4} {type=29,len=2} {type=21,len=3}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=18,len=5} {type=17,len=4} {type=16,len=1} {type=1,len=6}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_gprs_status_notify modem /sierra_0 status 1
==================> ROAMING status reported <==========================
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 5 lac 20731 cellid 76873975 tech 2
d) second indication while "registered"
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 31 00 80 03 01 04 00 00 24 00 25 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
28 02 00 15 01 UMTS Primary Scrambling Code
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 04 00 03 03 04 05
01 06 00 01 01 01 02 01 05 QMI_NAS_REGISTRATION_STATE_REGISTERED, CS attached, PS attached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_UMTS
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=37 [client=1,type=4,tid=0,len=49]
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=41,len=5} {type=40,len=2} {type=18,len=5} {type=17,len=4}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=1,len=6}
==================> ROAMING information lost <==========================
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 1 lac -1 cellid -1 tech 2
I don't know if this is a problem specific to MC7304 or even to my firmware version or if this is a normal behavior to have ROAMING_STATUS parameter only when status change from anything to registered.
Best Regards,
Christophe
Christophe Ronco (1):
qmimodem: fix roaming status report
drivers/qmimodem/network-registration.c | 50 ++++++++++++++++++++++++++++-----
1 file changed, 43 insertions(+), 7 deletions(-)
--
2.7.4
2 years, 7 months
[PATCH 1/2] include: Add ofono_modem_get_voicecall
by Slava Monich
---
include/modem.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/modem.h b/include/modem.h
index 005a42e..bed46c2 100644
--- a/include/modem.h
+++ b/include/modem.h
@@ -31,6 +31,7 @@ extern "C" {
struct ofono_modem;
struct ofono_gprs;
struct ofono_sim;
+struct ofono_voicecall;
enum ofono_modem_type {
OFONO_MODEM_TYPE_HARDWARE = 0,
@@ -84,6 +85,7 @@ void ofono_modem_remove_interface(struct ofono_modem *modem,
const char *ofono_modem_get_path(struct ofono_modem *modem);
struct ofono_sim *ofono_modem_get_sim(struct ofono_modem *modem);
struct ofono_gprs *ofono_modem_get_gprs(struct ofono_modem *modem);
+struct ofono_voicecall *ofono_modem_get_voicecall(struct ofono_modem *modem);
void ofono_modem_set_data(struct ofono_modem *modem, void *data);
void *ofono_modem_get_data(struct ofono_modem *modem);
--
1.9.1
2 years, 9 months
HE910-G - Can't activate context
by Jason Tribe
Hi all,
I apologize in advance for the long email.
We are attempting to use Connman/Ofono to setup a data connection with a
Telit HE910-G modem. The modem is on a Telit development kit which plugs
into our embedded hardware via the USB port.
Using version 1.17 of ofono, we were able to pickup and power/enable the
modem.
Using version 1.24 of ofono, the first problem we had was that ofono would
generate a /telit_0 interface, but any attempt to enable the mode would
fail with a dbus timeout. Eventually we tracked this down to the +GMM
command ofono uses to get the model_variant string. We saw that ofono
expects "HE910-G" from the modem, but the modem was only responding with
the model and not the variant "HE910". Hard coding the model_varaint string
to "HE910-G" solved the problem and we were able to enable/power the modem
through ofono and even register the SIM on the network. From what I can
tell, this bug seems to be present in all ofono versions that don't use the
he910.c plugin.
I looked through the AT commands data sheet for the HE910 family and the
closest command I could find that would give us the model and variant was
..., but unfortunately this echos the command back which is a bit messy. So
for now I have left it hard coded.
The current problem we are having is that we cannot activate the context
with ofono or connman. Any attempt fails with:
Error activating /telit_1/context1: org.ofono.Error.NotImplemented:
Implementation not provided.
I have seen some old (2015) posts with the same problem, but these have all
been with the older versions of ofono that use the he910.c plugin, and non
of the solutions worked for us. I am currently stuck at this point and have
been unsuccessful at debugging this any further. Is there anyone who has
had a similar problem or have any ideas on how I can debug this?
Any help with our problem would be greatly appreciated.
Kind regards
Jason
2 years, 9 months
[PATCH 1/3] include: Add OFONO_ERROR_TYPE_ERRNO
by Slava Monich
---
include/types.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/types.h b/include/types.h
index 2c64b20..90d8c2c 100644
--- a/include/types.h
+++ b/include/types.h
@@ -56,6 +56,7 @@ enum ofono_error_type {
OFONO_ERROR_TYPE_CEER,
OFONO_ERROR_TYPE_SIM,
OFONO_ERROR_TYPE_FAILURE,
+ OFONO_ERROR_TYPE_ERRNO
};
enum ofono_disconnect_reason {
--
1.9.1
2 years, 9 months
[PATCH] dbus: Make cme_errors_mapping static const
by Slava Monich
---
src/dbus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/dbus.c b/src/dbus.c
index 3e1e162..cadf5c6 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -37,7 +37,7 @@ struct error_mapping_entry {
DBusMessage *(*ofono_error_func)(DBusMessage *);
};
-struct error_mapping_entry cme_errors_mapping[] = {
+static const struct error_mapping_entry cme_errors_mapping[] = {
{ 3, __ofono_error_not_allowed },
{ 4, __ofono_error_not_supported },
{ 16, __ofono_error_incorrect_password },
@@ -422,7 +422,7 @@ DBusMessage *__ofono_error_network_terminated(DBusMessage *msg)
DBusMessage *__ofono_error_from_error(const struct ofono_error *error,
DBusMessage *msg)
{
- struct error_mapping_entry *e;
+ const struct error_mapping_entry *e;
int maxentries;
int i;
--
1.9.1
2 years, 9 months
[PATCH] dbus: Add D-Bus mapping for generic errors
by Slava Monich
This allows plugins/drivers to be a bit more specific about
what went wrong.
---
src/dbus.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/dbus.c b/src/dbus.c
index 3e1e162..7ea86ed 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -24,6 +24,7 @@
#endif
#include <glib.h>
+#include <errno.h>
#include <gdbus.h>
#include "ofono.h"
@@ -37,7 +38,7 @@ struct error_mapping_entry {
DBusMessage *(*ofono_error_func)(DBusMessage *);
};
-struct error_mapping_entry cme_errors_mapping[] = {
+static const struct error_mapping_entry cme_errors_mapping[] = {
{ 3, __ofono_error_not_allowed },
{ 4, __ofono_error_not_supported },
{ 16, __ofono_error_incorrect_password },
@@ -47,6 +48,14 @@ struct error_mapping_entry cme_errors_mapping[] = {
{ 50, __ofono_error_invalid_args },
};
+static const struct error_mapping_entry generic_errors_mapping[] = {
+ { EACCES, __ofono_error_access_denied },
+ { EOPNOTSUPP, __ofono_error_not_supported },
+ { ENOSYS, __ofono_error_not_implemented },
+ { ETIMEDOUT, __ofono_error_timed_out },
+ { EINPROGRESS, __ofono_error_busy }
+};
+
static void append_variant(DBusMessageIter *iter,
int type, const void *value)
{
@@ -422,15 +431,14 @@ DBusMessage *__ofono_error_network_terminated(DBusMessage *msg)
DBusMessage *__ofono_error_from_error(const struct ofono_error *error,
DBusMessage *msg)
{
- struct error_mapping_entry *e;
+ const struct error_mapping_entry *e;
int maxentries;
int i;
switch (error->type) {
case OFONO_ERROR_TYPE_CME:
e = cme_errors_mapping;
- maxentries = sizeof(cme_errors_mapping) /
- sizeof(struct error_mapping_entry);
+ maxentries = G_N_ELEMENTS(cme_errors_mapping);
for (i = 0; i < maxentries; i++)
if (e[i].error == error->error)
return e[i].ofono_error_func(msg);
@@ -439,6 +447,18 @@ DBusMessage *__ofono_error_from_error(const struct ofono_error *error,
return __ofono_error_failed(msg);
case OFONO_ERROR_TYPE_CEER:
return __ofono_error_failed(msg);
+ case OFONO_ERROR_TYPE_FAILURE:
+ if (error->error) {
+ int err = error->error;
+
+ if (err < 0) err = -err;
+ e = generic_errors_mapping;
+ maxentries = G_N_ELEMENTS(generic_errors_mapping);
+ for (i = 0; i < maxentries; i++)
+ if (e[i].error == err)
+ return e[i].ofono_error_func(msg);
+ }
+ break;
default:
return __ofono_error_failed(msg);
}
--
1.9.1
2 years, 9 months
[PATCH 01/12] include: Expose voicecall related enums to plugins
by Slava Monich
---
include/types.h | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/include/types.h b/include/types.h
index 2c64b20..a562bfe 100644
--- a/include/types.h
+++ b/include/types.h
@@ -49,6 +49,37 @@ enum ofono_clir_option {
OFONO_CLIR_OPTION_SUPPRESSION,
};
+/* 27.007 Section 7.6 */
+enum ofono_clip_validity {
+ OFONO_CLIP_VALIDITY_VALID = 0,
+ OFONO_CLIP_VALIDITY_WITHHELD,
+ OFONO_CLIP_VALIDITY_NOT_AVAILABLE
+};
+
+/* 27.007 Section 7.18 */
+enum ofono_call_status {
+ OFONO_CALL_STATUS_ACTIVE = 0,
+ OFONO_CALL_STATUS_HELD,
+ OFONO_CALL_STATUS_DIALING,
+ OFONO_CALL_STATUS_ALERTING,
+ OFONO_CALL_STATUS_INCOMING,
+ OFONO_CALL_STATUS_WAITING,
+ OFONO_CALL_STATUS_DISCONNECTED
+};
+
+/* 27.007 Section 7.18 */
+enum ofono_call_direction {
+ OFONO_CALL_DIRECTION_MOBILE_ORIGINATED = 0,
+ OFONO_CALL_DIRECTION_MOBILE_TERMINATED
+};
+
+/* 27.007 Section 7.30 */
+enum ofono_cnap_validity {
+ OFONO_CNAP_VALIDITY_VALID = 0,
+ OFONO_CNAP_VALIDITY_WITHHELD,
+ OFONO_CNAP_VALIDITY_NOT_AVAILABLE
+};
+
enum ofono_error_type {
OFONO_ERROR_TYPE_NO_ERROR = 0,
OFONO_ERROR_TYPE_CME,
--
1.9.1
2 years, 9 months
[PATCH 1/2] include: Add ofono_voicecall_get_modem
by Slava Monich
---
include/voicecall.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/voicecall.h b/include/voicecall.h
index 5b3da6a..a704b65 100644
--- a/include/voicecall.h
+++ b/include/voicecall.h
@@ -160,6 +160,8 @@ void ofono_voicecall_disconnected(struct ofono_voicecall *vc, int id,
*/
void ofono_voicecall_mpty_hint(struct ofono_voicecall *vc, unsigned int ids);
+struct ofono_modem *ofono_voicecall_get_modem(struct ofono_voicecall *vc);
+
int ofono_voicecall_driver_register(const struct ofono_voicecall_driver *d);
void ofono_voicecall_driver_unregister(const struct ofono_voicecall_driver *d);
--
1.9.1
2 years, 9 months
[PATCH] voicecall: Handle voicecall_dbus_register() return value
by Slava Monich
FALSE means that struct voicecall passed in as a parameter
has been deallocated.
---
src/voicecall.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/voicecall.c b/src/voicecall.c
index e4f6a4c..194b75f 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -1391,7 +1391,9 @@ static struct voicecall *synthesize_outgoing_call(struct ofono_voicecall *vc,
v->detect_time = time(NULL);
DBG("Registering new call: %d", call->id);
- voicecall_dbus_register(v);
+
+ if (!voicecall_dbus_register(v))
+ return NULL;
vc->call_list = g_slist_insert_sorted(vc->call_list, v, call_compare);
--
1.9.1
2 years, 9 months
[BUG] plugins: sim900 support broken for tty port users
by poeschel＠lemonage.de
Hi!
I think I found a bug.
Commit 1d63b1d35 essentially breaks the sim900 driver for serial port
users.
It adds a new entry in plugins/udevng.c driver_list with name "sim900".
There are two entries with the same name then: The new one which calls
the new setup_sim900 function and the old one which wants to call
the old setup_serial_modem function. Since driver_list is scanned
by name of the driver from top to button, serial driver users don't
have a chance to reach the entry with setup_serial_modem anymore.
Calling setup_sim900 does not work on a modem that was added through
add_serial_device, because the union serial/devices is written a
struct serial_device_info * that can not be used as GSList *.
Maybe I am missing something, but I think the new driver name in
driver_list should be different from the old one.
Regards,
Lars
2 years, 9 months
