The Quectel EC21 does only work correctly, if the mux channel used for
aux is the first mux channel. It does only put it's URC messages in the
first mux channel, so this has to be the aux channel in our case.
To be flexible on the mux order we introduce two arrays here, that then
contain the initialization data in their needed order.
Initialization data is then applied by for-looping over this array.
This is a change for the EC21. It will require specific handling before
and right after setting up the mux. So this change prepares this. It
queries the modem model before the mux (CMUX) is activated.
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
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
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.
+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.
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]
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
The intent here was to find the contents of the 3 low order bits
according to Table 11-5 in ETSI 102.221. However, the mask ended up
only grabbing the contents of the 2 low order bits.
There was a race condition where a context might be
registered before the netreg status updates to LTE.
The code took for granted the context is activated after
the technology update. With this change, any order is
is accepted.
Use at_util_sim_state_query_new() to query the sim inserted state. Once
that returns, the locked state is queried by issuing a AT+CPIN? command.
If not locked, a timer is started to query the quectel init status of
the sim. Once the init status is ready, the sim atom is created, and the
modem is set to powered, and the sim is signaled both inserted, and
initialized.
If locked, the modem is set to powered, and the sim atom is created.
This allows users to enter the pin to unlock the sim. Once the sim is
unlocked, a +CPIN: READY indication is caught to query the quectel
init status. Once the init status is ready, the sim is signaled
initialized.
All the above is needed, because the modem indicated +CPIN: READY before
the sim is really ready. The only way to be certain, is to wait for the
quectel init status to be ready. Even signaling the sim inserted
prematurely can cause to modem to hang during the initial AT+CRSM
commands.
With the reference in place in received_data(), the address sanitizer
now encounters a use-after-free when the destroy notification is
dispatched for the read watcher (see below).
Fix this by remove the destroy notification callback, as it isn't really
used except in the shutdown function.
==5797==ERROR: AddressSanitizer: heap-use-after-free on address 0x621000ac5904 at pc 0x55c1243b1f14 bp 0x7ffdef001340 sp 0x7ffdef001330
WRITE of size 4 at 0x621000ac5904 thread T0
#0 0x55c1243b1f13 in read_watcher_destroy_notify ../git/gatchat/gatmux.c:660
#1 0x7f08a8676742 (/usr/lib/libglib-2.0.so.0+0x62742)
#2 0x7f08a867e2e4 in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6a2e4)
#3 0x7f08a8680210 (/usr/lib/libglib-2.0.so.0+0x6c210)
#4 0x7f08a8681122 in g_main_loop_run (/usr/lib/libglib-2.0.so.0+0x6d122)
#5 0x55c1243d6703 in main ../git/src/main.c:286
#6 0x7f08a8423152 in __libc_start_main (/usr/lib/libc.so.6+0x27152)
#7 0x55c1241fe1ad in _start (/home/martin/projects/ofono/x86/src/ofonod+0xfd1ad)
0x621000ac5904 is located 4 bytes inside of 4672-byte region [0x621000ac5900,0x621000ac6b40)
freed by thread T0 here:
#0 0x7f08a88cc6b0 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:122
#1 0x55c1243b1ebf in g_at_mux_unref ../git/gatchat/gatmux.c:652
#2 0x55c1243b062c in received_data ../git/gatchat/gatmux.c:276
#3 0x7f08a867e2ce in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6a2ce)
previously allocated by thread T0 here:
#0 0x7f08a88cccd8 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:153
#1 0x55c1243b1bf1 in g_at_mux_new ../git/gatchat/gatmux.c:613
#2 0x55c1243b4b53 in g_at_mux_new_gsm0710_basic ../git/gatchat/gatmux.c:1172
#3 0x55c124386abd in cmux_gatmux ../git/plugins/quectel.c:871
#4 0x55c12438779f in cmux_cb ../git/plugins/quectel.c:1023
#5 0x55c1243a368e in at_chat_finish_command ../git/gatchat/gatchat.c:459
#6 0x55c1243a3bc8 in at_chat_handle_command_response ../git/gatchat/gatchat.c:521
#7 0x55c1243a4408 in have_line ../git/gatchat/gatchat.c:600
#8 0x55c1243a539e in new_bytes ../git/gatchat/gatchat.c:759
#9 0x55c1243ae2f9 in received_data ../git/gatchat/gatio.c:122
#10 0x7f08a867e2ce in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6a2ce)
SUMMARY: AddressSanitizer: heap-use-after-free ../git/gatchat/gatmux.c:660 in read_watcher_destroy_notify
Shadow bytes around the buggy address:
0x0c4280150ad0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280150ae0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280150af0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280150b00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280150b10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c4280150b20:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4280150b30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4280150b40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4280150b50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4280150b60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4280150b70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==5797==ABORTING
When closing down a cmux object, the address sanitizer detects a
use-after-free in gatmux.c (see below).
Avoid this by taking a reference to the mux object during the processing
in received_data().
ofonod[3640549]: ../git/plugins/quectel.c:cfun_disable() 0x610000000b40
ofonod[3640549]: ../git/plugins/quectel.c:close_serial() 0x610000000b40
ofonod[3640549]: ../git/plugins/quectel.c:close_mux() 0x610000000b40
ofonod[3640549]: ../git/examples/emulator.c:powered_watch() Removing modem 0x610000000b40 from the list
ofonod[3640549]: ../git/examples/emulator.c:powered_watch() Removing server watch: 106
ofonod[3640549]: ../git/src/modem.c:modem_change_state() old state: 0, new state: 0
=================================================================
==3640549==ERROR: AddressSanitizer: heap-use-after-free on address 0x62100073dd28 at pc 0x5566b6402a21 bp 0x7ffe7a2db0e0 sp 0x7ffe7a2db0d0
READ of size 8 at 0x62100073dd28 thread T0
#0 0x5566b6402a20 in debug ../git/gatchat/gatmux.c:109
#1 0x5566b6404bd7 in channel_close ../git/gatchat/gatmux.c:525
#2 0x7fa0516e44a6 in g_io_channel_shutdown (/usr/lib/libglib-2.0.so.0+0x774a6)
#3 0x7fa0516e4644 in g_io_channel_unref (/usr/lib/libglib-2.0.so.0+0x77644)
#4 0x5566b64048a4 in watch_finalize ../git/gatchat/gatmux.c:474
#5 0x7fa0516d6f6f (/usr/lib/libglib-2.0.so.0+0x69f6f)
#6 0x7fa0516ac6a7 in g_slist_foreach (/usr/lib/libglib-2.0.so.0+0x3f6a7)
#7 0x7fa0516b277b in g_slist_free_full (/usr/lib/libglib-2.0.so.0+0x4577b)
#8 0x5566b6403413 in dispatch_sources ../git/gatchat/gatmux.c:224
#9 0x5566b64039ea in received_data ../git/gatchat/gatmux.c:268
#10 0x7fa0516d727e in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6a27e)
#11 0x7fa0516d91c0 (/usr/lib/libglib-2.0.so.0+0x6c1c0)
#12 0x7fa0516da0d2 in g_main_loop_run (/usr/lib/libglib-2.0.so.0+0x6d0d2)
#13 0x5566b6429b1b in main ../git/src/main.c:286
#14 0x7fa05147fee2 in __libc_start_main (/usr/lib/libc.so.6+0x26ee2)
#15 0x5566b62531ad in _start (/home/martin/projects/ofono/x86/src/ofonod+0xfc1ad)
0x62100073dd28 is located 40 bytes inside of 4672-byte region [0x62100073dd00,0x62100073ef40)
freed by thread T0 here:
#0 0x7fa0519256c0 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:122
#1 0x5566b64052d7 in g_at_mux_unref ../git/gatchat/gatmux.c:645
#2 0x5566b63d6d19 in close_mux ../git/plugins/quectel.c:199
#3 0x5566b63d7047 in close_serial ../git/plugins/quectel.c:223
#4 0x5566b63db62a in cfun_disable ../git/plugins/quectel.c:1056
#5 0x5566b63f6ae1 in at_chat_finish_command ../git/gatchat/gatchat.c:459
#6 0x5566b63f701b in at_chat_handle_command_response ../git/gatchat/gatchat.c:521
#7 0x5566b63f785b in have_line ../git/gatchat/gatchat.c:600
#8 0x5566b63f87f1 in new_bytes ../git/gatchat/gatchat.c:759
#9 0x5566b640174c in received_data ../git/gatchat/gatio.c:122
#10 0x5566b64047b4 in watch_dispatch ../git/gatchat/gatmux.c:464
#11 0x5566b640313b in dispatch_sources ../git/gatchat/gatmux.c:183
#12 0x5566b64039ea in received_data ../git/gatchat/gatmux.c:268
#13 0x7fa0516d727e in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6a27e)
previously allocated by thread T0 here:
#0 0x7fa051925ce8 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:153
#1 0x5566b6405009 in g_at_mux_new ../git/gatchat/gatmux.c:606
#2 0x5566b6407f6b in g_at_mux_new_gsm0710_basic ../git/gatchat/gatmux.c:1165
#3 0x5566b63da9ba in cmux_cb ../git/plugins/quectel.c:882
#4 0x5566b63f6ae1 in at_chat_finish_command ../git/gatchat/gatchat.c:459
#5 0x5566b63f701b in at_chat_handle_command_response ../git/gatchat/gatchat.c:521
#6 0x5566b63f785b in have_line ../git/gatchat/gatchat.c:600
#7 0x5566b63f87f1 in new_bytes ../git/gatchat/gatchat.c:759
#8 0x5566b640174c in received_data ../git/gatchat/gatio.c:122
#9 0x7fa0516d727e in g_main_context_dispatch (/usr/lib/libglib-2.0.so.0+0x6a27e)
SUMMARY: AddressSanitizer: heap-use-after-free ../git/gatchat/gatmux.c:109 in debug
Shadow bytes around the buggy address:
0x0c42800dfb50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c42800dfb60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c42800dfb70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c42800dfb80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c42800dfb90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c42800dfba0: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd
0x0c42800dfbb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c42800dfbc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c42800dfbd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c42800dfbe0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c42800dfbf0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==3640549==ABORTING
It turns out that both L2xx and L4xx modems are a bit
buggy when it comes to send CREG URC's when the tech changes.
Try to overcome this by subscribing to both UREG and CREG,
and poll the other when any of the URC's are received.
Protect from doing simultaneous polls though.
uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands. The documentation says to monitor
the 'greeting text' to detect readiness, but this 'greeting text' is not
actually specified for any device other than the TOBY L4.
What seems to work is to probe the device with 'AT' commands until the
device responds, and then to wait an additional second before
proceeding. The TOBY L4 reliably sends its 'greeting text' (+AT: READY)
within this interval.
It would be more rigorous to actually wait for the 'READY' indication
for the TOBY L4, but that would require knowing the device model before
the device model is actually queried. This is doable via the USB
product ID, but overkill when the above heuristic seems to work
reliably.
Before this patch, the ublox plugin was trying to achieve something like
the above with the g_at_chat_set_wakeup_command() function, but that had
some issues:
i) it did not work reliably, in particular failing badly on the TOBY L4
with responses getting out of sync with commands
ii) it was an inappropriate use of the wakeup_command which is intended
for devices that may sleep when there is no communication during some
interval
This patch adds an init sequence that probes the device for readiness
before continuing with initialization.
Just reshuffling the code a bit and the 'disable' path can use the
close_devices() helper to finish up. This also prevents a bug should
the CFUN command fail to disable the modem whereby the 'aux' device
remains open but the 'modem' device has already been closed.
The code for closing all the modem devices and flagging the modem as
unpowered is repeated several times in the driver... this patch puts
this code into a common helper for readability.
Its incorrect to fiddle with the driver attach state when
attaching. When attaching the state is transitioning,
and the correct state will now always be assigned in
the end of the attach process, regardless of result.
Currently there is an issue if the attach state changes and
there are active contexts of which the driver does not
implement the detach_shutdown.
In that case we just release the context (clears CID and
active state), but nothing is signalled on D-Bus or towards
the modem.
Ofono is then out of sync with both the connection manager
and the modem, this manifests itself later on if the modem
changes state of the context, then ofono will not find it
since the CID is cleared, and the connection manager won't
be notified.
Lars Poeschel
Denis Kenzior
JongSeok Won
joey@joeyhewitt.com
Richard Röjfors
Antara Borwankar
Jimmy Gysens
David Lechner
Marcel Holtmann
Martin Hundebøll
Jonas Bonn