[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
1 month, 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, 4 months
[PATCH 0/2] *** code puk fix ***
by Florent Beillonnet
*** The issue was that the puk code was not accepted by ofono.
First, it appears that the properties were not updated after entering pin code.
For instance, after a wrong pin code, the Retries property was still at 3.
The first patch fixes this issue.
Then, entering a correct puk code caused ofono to crash.
The second patch fixes this issue. ***
Florent Beillonnet (2):
Adding the ofono_sim_initialized_notify function after
ofono_sim_inserted_notify, as suggested by Denis Kenzior in this
commit : 54d56d763e40bc44c99a9b24aa0477bd373ea085
Rework at_pin_send_puk It seems that the function at_pin_send_puk
should have been changed along with at_pin_send, because it's also
refering to the at_pin_send_cb callback See this commit :
ba9f126716db3ae0bf6a3139088d9657cfb8b851
drivers/atmodem/sim.c | 4 ++--
plugins/gemalto.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
--
1.9.1
3 years, 8 months
[PATCH] ussd: Cancel pending requests when unregistering
by Slava Monich
And reset state to idle before unregistering the D-Bus interface.
This may occur e.g. when we receive REFRESH from STK.
---
src/ussd.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/src/ussd.c b/src/ussd.c
index f5dd9d9..23b3323 100644
--- a/src/ussd.c
+++ b/src/ussd.c
@@ -810,6 +810,22 @@ static void ussd_unregister(struct ofono_atom *atom)
DBusConnection *conn = ofono_dbus_get_connection();
struct ofono_modem *modem = __ofono_atom_get_modem(atom);
const char *path = __ofono_atom_get_path(atom);
+ DBusMessage *reply;
+
+ if (ussd->pending) {
+ reply = __ofono_error_canceled(ussd->pending);
+ __ofono_dbus_pending_reply(&ussd->pending, reply);
+ }
+
+ if (ussd->cancel) {
+ reply = dbus_message_new_method_return(ussd->cancel);
+ __ofono_dbus_pending_reply(&ussd->cancel, reply);
+ }
+
+ if (ussd->req)
+ ussd_request_finish(ussd, -ECANCELED, 0, NULL, 0);
+
+ ussd_change_state(ussd, USSD_STATE_IDLE);
g_slist_free_full(ussd->ss_control_list, ssc_entry_destroy);
ussd->ss_control_list = NULL;
--
1.9.1
3 years, 8 months
[PATCH] udevng: remove vendor ID to make it generic for intel modem
by Varun Gargi
---
plugins/udevng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/plugins/udevng.c b/plugins/udevng.c
index cd56fd5..3bd6ffa 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1671,8 +1671,8 @@ static struct {
{ "gemalto", "cdc_ether", "1e2d", "0061" },
{ "telit", "cdc_ncm", "1bc7", "0036" },
{ "telit", "cdc_acm", "1bc7", "0036" },
- { "xmm7xxx", "cdc_acm", "8087", "0930" },
- { "xmm7xxx", "cdc_ncm", "8087", "0930" },
+ { "xmm7xxx", "cdc_acm", "8087" },
+ { "xmm7xxx", "cdc_ncm", "8087" },
{ }
};
--
1.9.1
3 years, 8 months
[PATCH] plugins: fixed crash in udevng
by James Prestwood
The return value from ofono_modem_register was not being checked. If this fails
the modem object is not setup and causes a crash. This was specifically seen
when using the mbim driver without having configured with mbim support.
Now the modem object gets destroyed properly if the modem registration fails.
---
plugins/udevng.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/plugins/udevng.c b/plugins/udevng.c
index cd56fd56..f4bf61cf 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1802,7 +1802,11 @@ static gboolean create_modem(gpointer key, gpointer value, gpointer user_data)
if (driver_list[i].setup(modem) == TRUE) {
ofono_modem_set_string(modem->modem, "SystemPath",
syspath);
- ofono_modem_register(modem->modem);
+ if (ofono_modem_register(modem->modem) < 0) {
+ DBG("could not register modem '%s'", modem->driver);
+ return TRUE;
+ }
+
return FALSE;
}
}
--
2.17.0
3 years, 8 months
Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4
by Harald Welte
Hi Stanislav,
On Fri, May 18, 2018 at 10:07:47PM +0200, Stanislav Sinyagin wrote:
> Simcom seems to be quite consistent in their support for this feature:
> it's available in 3 latest models, the 7100, 7500, and 7600 series,
> and they share the same AT command set for this.
Thanks a lot for pointing this out. This is definitely good to know.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3 years, 8 months
Incoming sms problem on Motorola Droid 4
by Pavel Machek
Hi!
I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
... unfortunately, with that configuration no messages are comming to
ofono and the other phone sees them as "delievery failed".
I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
PDU) messages. That works well enough for me.
Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
work well, either.
Any ideas how to debug this / what to try?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
3 years, 8 months
Re: Voice calls over qmi was Re: Incoming sms problem on Motorola Droid 4
by Harald Welte
Hi Stanislav,
On Wed, May 16, 2018 at 05:15:07PM +0200, Stanislav Sinyagin wrote:
> also most mPCIE modems deliver PCI voice over dedicated wires on their
> mPCIE socket. These wires are standardized as "reserved" and most
> standard boards with mPCIE don't connect them anywhere.
This is the "PCM" interface I was referring-to. This means you need
a PCM slave interface to interface with it, as the modems typically all
insist on being a PCM master. The intention here is that you attach
some external audio codec IC that converts from the PCM to analog audio.
This means you cannot interface this PCM interface e.g. with standard
USB-Audio bridge ICs, as all those USB-Audi bridge ICs (basically "USB
soundcard" ICs) all also only implement the "master" of the PCM
interface and not the slave.
See http://laforge.gnumonks.org/blog/20170902-cellular_modems-voice/
In the end, you have to use something like the SSC (synchronous serial)
peripheal of Atmel SAM3/SAM4/... devices, or an XMOS device in order to
interface with that audio.
Needless to say, the lack of a standard for where PCM lines are on mPCIe
slots means that you cannot build any base board that will interoperate
with mPCIe modules from different vendors.
> But if you develop your own PCB, you can actually retrieve the voice
> signal. It just needs a bit of hacking.
The fact that a PCM bus is present on the hardware pins of the mPCIe socket
or the pads of a LGA module also still doesn't mean that you actually will
have working audio.
Many modem module maker do not obtain patent licenses for audio/voice, as
they know/expect their modems are typically only used in machine2machine
or other data-only applications.
Finally, even if the firmware and hardware interface is present, in many
cases the modem manufacturers make you sign a declaration that you will
only use the voice interface as some kind of "emergency communication"
only, and not as part of your normal product. Once again, patent
licensing differences for voice vs. data-only use cases are to be blamed
for that.
Oh, and I'm not even touching the question on whether audio will work in
circuit-switched 2G/3G only, or whether it will also work with VoLTE,
and particularly not whether they will do SRVCC, etc. That adds yet
another dimension to the problem.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3 years, 8 months
[PATCH 0/2] Fix AT+COLP=1 stalling VoiceCall creation in SIMCom SIM7100E
by Bob Ham
Setting AT+COLP=1 on the SIMCom SIM7100E causes oFono to stall and not
create a new VoiceCall object. We fix that by adding the SIMCOM
vendor ID to the list for whom we set AT+COLP=0 instead.
Bob Ham (2):
atmodem: Don't set AT+COLP=1 on SIMCom modems
sim7100: Specify vendor ID while creating voicecall driver
drivers/atmodem/voicecall.c | 1 +
plugins/sim7100.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
2.11.0
3 years, 8 months
