[PATCH_v4 0/5] Private network request to ConnMan
by Guillaume Zajac
Hi,
Changelog from v3 is:
- Add private-network source/include
- ConnMan plugin is independant from emulator
- Each application that need VPN will pass a callback as argument
when private network is requested. This callback will contain the
private network settings.
Guillaume Zajac (5):
gatppp: Add new contructor to use external fd
private-network: add callback typedef drivers and settings
private-network: add request/release functions and new feature to
Makefile.am
emulator: add request/release private network calls
connman: add plugin in oFono to request request/release private
network
Makefile.am | 10 +-
gatchat/gatppp.c | 33 +++++-
gatchat/gatppp.h | 1 +
gatchat/ppp.h | 2 +-
gatchat/ppp_net.c | 40 ++++---
include/private-network.h | 59 +++++++++
plugins/connman.c | 297 +++++++++++++++++++++++++++++++++++++++++++++
src/emulator.c | 49 ++++++--
src/ofono.h | 6 +
src/private-network.c | 89 ++++++++++++++
10 files changed, 556 insertions(+), 30 deletions(-)
create mode 100644 include/private-network.h
create mode 100644 plugins/connman.c
create mode 100644 src/private-network.c
3 months, 1 week
[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
3 years, 1 month
no connection after ofono restart while huawei modem connected
by Christophe Ronco
Hi,
I use a Huawei MS2372h-607. It is a classical AT+PPP modem. I have a
problem when I stop ofono while context is activated. When I restart
ofono (without unplugging the modem), I am not able to send any AT
command on Modem channel because this channel is still in data mode.
I made a patch to send escape sequence when gprs-context atom is
removed. It fixes the problem but I don't know if this is the right
thing to do.
Attached to this mail:
I/ reconnectError_01: traces of complete test (with debug and AT debug).
Test done:
1) board boot
2) Connection (success), start at line 1058:
connmanctl connect cellular...
3) stop ofono, start at line 1109:
/etc/init.d/ofono stop
4) start ofono, start at line 1348:
/etc/init.d/ofono start
5) Connection (error), start at line 2018:
connmanctl connect cellular...
I don't have PPP debug in this trace but here is what happens at PPP
level when Ofono is stopped:
ofonod[944]:
../ofono-1.24/drivers/atmodem/gprs-context.c:at_gprs_detach_shutdown() cid 0
ofonod[944]: PPP: lcp: pppcp_generate_event: current state 9:OPENED
ofonod[944]: PPP: event: 3 (Close), action: 8224, new_state: 4 (CLOSING)
ofonod[944]: PPP: lcp: pppcp_initialize_restart_count: current state
9:OPENED
ofonod[944]: PPP: lcp: pppcp_send_terminate_request: current state 9:OPENED
ofonod[944]: PPP: ipcp: pppcp_generate_event: current state 9:OPENED
ofonod[944]: PPP: event: 1 (Down), action: 201, new_state: 1 (STARTING)
ofonod[944]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_enter_phase() 5
ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_context_unregister()
0xc10ed0, 0xc10d90
ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_context_remove() atom: 0xc10ef0
ofonod[944]:
../ofono-1.24/drivers/atmodem/gprs-context.c:at_gprs_context_remove()
ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_unregister() 0xc10d90
Terminate request is sent and then gprs-context atom is removed before
Terminate Ack is received.
II/ 0001-PPP-send-escape-sequence-when-ofono-dies.patch
The patch I made to fix the problem. The idea is to immediately send
escape sequence when removing gprs-context atom. This patch is not ready
to be sent (at least it must be split in two patches). Can you tell me
what you think about this patch?
Best Regards,
Christophe Ronco
3 years, 3 months
[PATCH] plugin: Don't unload external plugins too early
by Slava Monich
Plugins may reference data structures allocated by each other.
They all need to be deinitialized first, only then it should be
safe to unload the libraries.
---
src/plugin.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/plugin.c b/src/plugin.c
index 2c9c619..924a45e 100644
--- a/src/plugin.c
+++ b/src/plugin.c
@@ -190,17 +190,26 @@ void __ofono_plugin_cleanup(void)
DBG("");
+ /*
+ * Terminate the plugins but don't unload the libraries yet.
+ * Plugins may reference data structures allocated by each other.
+ */
for (list = plugins; list; list = list->next) {
struct ofono_plugin *plugin = list->data;
if (plugin->active == TRUE && plugin->desc->exit)
plugin->desc->exit();
+ }
+
+ /* Second pass - unload the libraries */
+ for (list = plugins; list; list = list->next) {
+ struct ofono_plugin *plugin = list->data;
if (plugin->handle)
dlclose(plugin->handle);
-
- g_free(plugin);
}
- g_slist_free(plugins);
+ /* Finally, free the memory */
+ g_slist_free_full(plugins, g_free);
+ plugins = NULL;
}
--
1.9.1
3 years, 3 months
[PATCH 1/1] gprs: store APN in settings for auto-discovered contexts
by Christophe Ronco
APN has to be stored in settings file after it is modified in
ofono_gprs_cid_activated function.
---
src/gprs.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/gprs.c b/src/gprs.c
index 377eced..22d5e36 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -2063,6 +2063,13 @@ void ofono_gprs_cid_activated(struct ofono_gprs *gprs, unsigned int cid,
strcpy(pri_ctx->context.apn, apn);
+ if (gprs->settings) {
+ g_key_file_set_string(gprs->settings, pri_ctx->key,
+ "AccessPointName", apn);
+ storage_sync(gprs->imsi, SETTINGS_STORE,
+ gprs->settings);
+ }
+
ofono_dbus_signal_property_changed(conn, pri_ctx->path,
OFONO_CONNECTION_CONTEXT_INTERFACE,
"AccessPointName",
--
2.7.4
3 years, 3 months
[qmimodems] gprs context provisioning versus automatically discovered contexts in LTE
by Christophe Ronco
Hi,
I am doing a test with a 4G SIM card with APN set in provisionning. I
've recently upgraded my Ofono version to 1.23.
My card gets LTE attach quickly, before it gets ServiceProviderName from
SIM card.
So ofono_gprs_cid_activated is called by get_lte_attach_param_cb
(drivers/qmimodem/gprs.c) and a context is created with APN discovered
in get_lte_attach_param_cb.
Then SIM ServiceProviderName is discovered and provision_contexts is
called. Another context is created with APN from provisioning file.
I end up with 2 contexts using same APN or different APNs, depending on
what I wrote in my provisioning file. I attached logs with same APN case.
In messages_02.txt:
- ofono_gprs_cid_activated is called at line 681
- __ofono_gprs_provision_get_settings is called at line 753
I end up with two contexts (properties summary in gsmdiag_02.txt).
Another strange thing in ofono gprs file for this SIM card:
root@klk-lpbs-06029C:~ # cat /etc/network/ofono/208013004789734/gprs
[Settings]
Powered=true
RoamingAllowed=false
[context1]
Name=orange-mib
AccessPointName=
Username=
Password=
AuthenticationMethod=chap
Type=internet
Protocol=ip
[context2]
Name=Internet
AccessPointName=orange-mib
Username=
Password=
AuthenticationMethod=chap
Type=internet
Protocol=ip
Context 1 has no APN. I don't know what would happen if I restart Ofono
and gets attached on 3G. I don't know if this is a bug or not.
Here are the "problems" I saw. And I don't know what to do in this case.
I mean I don't know what result I should have.
What should happen if context information are the same in provisioning
and from network discovery? Maybe only one context?
What should happen if context information are different in provisioning
and from network discovery? Creation of 2 contexts and 1 gets
automatically connected? Disconnection of the automatically connected
context and creation of context using information from provisionning?
Provisionning ignored?
Best Regards,
Christophe
3 years, 3 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
3 years, 3 months