lp:ofono

Branch merges

Related source package recipes

2 recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

8793. By Richard Röjfors <email address hidden> on 2020-02-14

ublox: network-registration: Handle UREG unsolicited during poll

In the case a unsolicited indication for UREG was received
while the status was polled. The poll response failed to parse.
This since the unsolicited indication only carries one
parameter, while the poll response is expected to carry two.

Update the code to loop until the response is found.

The log below shows a case where this happened.

10:07:55 ofonod[520]: Aux: > AT+UREG?\r
10:07:55 ofonod[520]: Aux: < \r\n+CGREG: 4\r\n\r\n+UREG: 0\r\n\r\n+CIEV: 9,1\r\n
10:07:55 ofonod[520]: src/gprs.c:ofono_gprs_status_notify() /ublox_0 status unknown (4)
10:07:55 ofonod[520]: src/gprs.c:ofono_gprs_detached_notify() /ublox_0
10:07:55 ofonod[520]: Aux: < \r\n+UREG: 1,0\r\n
10:07:55 ofonod[520]: Aux: < \r\nOK\r\n

8792. By Denis Kenzior <email address hidden> on 2020-02-07

allowed-apns: Do not try to unregister unnecessarily

allowed-apns plugin will try to uregister the AllowedAccessPoints
interface whenever the sim state changes, even when not registered.
This results in the (benign) error being printed inside
ofono_modem_remove_interface:

Interface org.ofono.AllowedAccessPoints not found on the interface_list

8791. By Richard Röjfors <email address hidden> on 2020-02-07

Instead of implementing an own copy of requesting and parsing
CREG, reuse the existing one from at-modem.

8790. By Antara Borwankar <email address hidden> on 2019-12-20

sim: handling crash in error scenario for SIM PIN query

In case of error in sim_pin_query_cb function. pin_type is set
to -1. This is causing segmentation fault in function
sim_passwd_name due to invalid index pin_type = -1. Fixing this
issue by handling error case before calling sim_passwd_name
function.

8789. By Antara Borwankar <email address hidden> on 2019-12-20

xmm7xxx: modified handling of XSIM states for xmm modems

+XSIM:7 state as defined in xmm7560 functional AT specification
only indicates ready for attach.

+CPIN: READY is received after SIM is completely initialized.
Also indicating readiness of Phonebook and SMS. Hence moving the
creation of SMS and Phonebook atom to xmm7xxx_post_sim function.

+XSIM:4 PUK needed state was not handled. It must be handled
same as PIN needed state. Added handling of this case to
switch_sim_state_status function.

8788. By Richard Röjfors <email address hidden> on 2019-12-11

gprs: Update attach state on context deactivation for LTE

To be considered attached on LTE a context should be activated.
But in case the context got deactivated we did not update
the attached state, it remained attached.
That caused the connection manager to try to re-activate the
context manually, but for LTE thats done automatically.
In the case of ublox it returns errors, which is passed
on to the connection manager, which tries again and
again, until we get attached again.

It looked like this:
12:03:18 ofonod[547]: Aux: < \r\n+CIEV: 2,3\r\n
12:03:23 ofonod[547]: Aux: < \r\n+CIEV: 2,2\r\n

Deactivated

12:16:01 ofonod[547]: Aux: < \r\n+CGEV: NW PDN DEACT 4\r\n
12:16:01 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgev_notify() cid 4, active cid: 4
12:16:01 ofonod[547]: src/gprs.c:ofono_gprs_context_deactivated() 0x1743e50 0x17424a8 4

Connection manager now try to activate, over and over again
because Attached remains TRUE

12:16:01 ofonod[547]: drivers/ubloxmodem/gprs-context.c:ublox_gprs_activate_primary() cid 1
12:16:01 ofonod[547]: Aux: > AT+CGDCONT=1,"IP","apn"\r
12:16:01 ofonod[547]: Aux: < \r\nOK\r\n
12:16:01 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgdcont_cb() ok 1
12:16:01 ofonod[547]: Aux: > AT+CGACT=1,1\r
12:16:01 ofonod[547]: Aux: < \r\n+CME ERROR: 30\r\n
12:16:01 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgact_enable_cb() ok 0
12:16:01 ofonod[547]: src/gprs.c:pri_activate_callback() 0x17475c0
12:16:01 ofonod[547]: src/gprs.c:pri_activate_callback() Activating context failed with error: No network service
12:16:01 ofonod[547]: drivers/ubloxmodem/gprs-context.c:ublox_gprs_activate_primary() cid 1
12:16:02 ofonod[547]: Aux: > AT+CGDCONT=1,"IP","apn"\r
12:16:02 ofonod[547]: Aux: < \r\nOK\r\n
12:16:02 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgdcont_cb() ok 1
12:16:02 ofonod[547]: Aux: > AT+CGACT=1,1\r
12:16:02 ofonod[547]: Aux: < \r\n+CME ERROR: 30\r\n
12:16:02 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgact_enable_cb() ok 0
12:16:02 ofonod[547]: src/gprs.c:pri_activate_callback() 0x17475c0
12:16:02 ofonod[547]: src/gprs.c:pri_activate_callback() Activating context failed with error: No network service
.
.
.
12:16:14 ofonod[547]: drivers/ubloxmodem/gprs-context.c:ublox_gprs_activate_primary() cid 1
12:16:14 ofonod[547]: Aux: > AT+CGDCONT=1,"IP","apn"\r
12:16:14 ofonod[547]: Aux: < \r\nOK\r\n
12:16:14 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgdcont_cb() ok 1
12:16:14 ofonod[547]: Aux: > AT+CGACT=1,1\r
12:16:14 ofonod[547]: Aux: < \r\n+CME ERROR: 30\r\n
12:16:14 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgact_enable_cb() ok 0
12:16:14 ofonod[547]: src/gprs.c:pri_activate_callback() 0x17475c0
12:16:14 ofonod[547]: src/gprs.c:pri_activate_callback() Activating context failed with error: No network service
12:16:14 ofonod[547]: drivers/ubloxmodem/gprs-context.c:ublox_gprs_activate_primary() cid 1
12:16:14 ofonod[547]: Aux: > AT+CGDCONT=1,"IP","apn"\r
12:16:14 ofonod[547]: Aux: < \r\nOK\r\n
12:16:14 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgdcont_cb() ok 1
12:16:14 ofonod[547]: Aux: > AT+CGACT=1,1\r

The context got activated again

12:16:14 ofonod[547]: Aux: < \r\n+CGEV: ME PDN ACT 4\r\n\r\n+CIEV: 9,2\r\n\r\n+CTZE: +04,0,"19/12/11,13:17:58"\r\n
12:16:14 ofonod[547]: drivers/ubloxmodem/network-registration.c:ctze_notify() tz +04 dst 0 time 19/12/11,13:17:58
12:16:14 ofonod[547]: src/network.c:ofono_netreg_time_notify() net time 2019-12-11 13:17:58 utcoff 3600 dst 0
12:16:14 ofonod[547]: Aux: < \r\n+CME ERROR: 100\r\n
12:16:14 ofonod[547]: drivers/ubloxmodem/gprs-context.c:cgact_enable_cb() ok 0
12:16:14 ofonod[547]: src/gprs.c:pri_activate_callback() 0x17475c0
12:16:14 ofonod[547]: src/gprs.c:pri_activate_callback() Activating context failed with error: Unknown error

8787. By Richard Röjfors <email address hidden> on 2019-12-11

gprs: Don't modify the context if assign fails

There was an issue while running LTE and the connection
manager tried to activate the context with CID 1 while
it got automatically activated at the same time with
CID 4.

When the automatic activation happened ofono_gprs_cid_activated
got called which tried to assign the context, but that failed
since the driver context was considered in use
(by the activation call).
Eventhough it failed, the context was modified,
cid was set to 0 (making cid 1 leak).
Then release_context got called which clear pointers
assigned to the context.

A bit later the activation callback got called, in my case
activation failed. Due to the failure it tries to clean up
by calling context_settings_free, but unfortunately the pointers
where reset above causing ofono to segfault du to null pointer
derefs.

Instead we make sure assign_context does not touch the context
unless it succeeds. Then there is no need to call release_context
if assign fails.
That ensures the context being intact when the activation callback
gets called.

03:23:21 ofonod[545]: Aux: < \r\n+CGEV: ME PDN ACT 4\r\n\r\n+CTZE: +04,0,"19/12/10,04:25:03"\r\n
03:23:21 ofonod[545]: drivers/ubloxmodem/network-registration.c:ctze_notify() tz +04 dst 0 time 19/12/10,04:25:03
03:23:21 ofonod[545]: src/network.c:ofono_netreg_time_notify() net time 2019-12-10 04:25:03 utcoff 3600 dst 0
03:23:22 ofonod[545]: Aux: > AT+CGDCONT?\r
03:23:22 ofonod[545]: drivers/ubloxmodem/gprs-context.c:ublox_gprs_activate_primary() cid 1

Connection manager requests activation, will mark the context in use and assign
it cid 1.

03:23:22 ofonod[545]: Aux: < \r\n+CGDCONT: 1,"IP","m2m.tele2.com","",0,0,0,0,0,0\r\n
03:23:22 ofonod[545]: Aux: < +CGDCONT: 4,"IP","m2m.tele2.com.mnc003.mcc248.gprs","100.69.174.133",0,0,0,0,0,0\r\n
03:23:22 ofonod[545]: Aux: < \r\nOK\r\n
03:23:22 ofonod[545]: drivers/atmodem/gprs.c:at_cgdcont_read_cb() ok 1
03:23:22 ofonod[545]: src/gprs.c:ofono_gprs_cid_activated() cid 4
03:23:22 ofonod[545]: Can't assign context to driver for APN.

Since its marked in use above, we fail to assign it cid 4. When that fails
the cid is cleared an all context pointers are set to NULL.

03:23:22 ofonod[545]: Aux: > AT+CGDCONT=1,"IP","m2m.tele2.com"\r
03:23:22 ofonod[545]: Aux: < \r\nOK\r\n
03:23:22 ofonod[545]: drivers/ubloxmodem/gprs-context.c:cgdcont_cb() ok 1
03:23:22 ofonod[545]: Aux: > AT+CGACT=1,1\r
03:23:22 ofonod[545]: Aux: < \r\n+CME ERROR: 100\r\n
03:23:22 ofonod[545]: drivers/ubloxmodem/gprs-context.c:cgact_enable_cb() ok 0
03:23:22 ofonod[545]: src/gprs.c:pri_activate_callback() 0x853480
03:23:22 ofonod[545]: src/gprs.c:pri_activate_callback() Activating context failed with error: Unknown error

Activation callback, and it failed. Will try to clean up, but the pointers are
NULL'ed...

Dec 10 03:23:22 ofonod[545]: Aborting (signal 11) [/usr/sbin/ofonod]

8786. By Jimmy Gysens <email address hidden> on 2019-11-22

huawei: Fix infinite loop on modem removal

After unplugging a Huawei USB dongle, the 'atoms' in oFono are removed
via 'flush_atoms'. Every atom has a destruct function pointer, used as
destructor. This includes the gprs_context atom that is currently
active.

The function calls are:
flush_atoms -> destruct -> gprs_context_remove ->
at_gprs_context_remove -> modem_disconnect

Because the device is physically removed, the IO channel for the AT
port is gone. In 'at_gprs_context_remove', there is an attempt to
resume communication over that AT port, but that is not possible. This
is detected, and 'io_disconnect' (pointer to 'modem_disconnect') is
called. 'modem_disconnect' has the same atom and tries to remove it
again, so it calls the same destructor. This continues infinitely.

This patch moves the GPRS context removal so that it only happens if the
modem port could be re-opened successfully. If the port cannot be
re-opened (in the case of modem removal), the atom is already in the
process of being removed by the process kicked off in flush_atoms.

This fix is limited to Huawei devices and has been tested using the
following devices:

- E3531i-2
- E3372
- E3531s-2
- E369
- E1552

8785. By David Lechner on 2019-11-18

test: make all files executable

This sets the executable bit on the only two files in the test directory
that do not already have it set.

8784. By Denis Kenzior <email address hidden> on 2019-11-13

atutil: Add missing va_end