Some gemalto modems provide USB ethernet interfaces for data path.
Implement gprs-context driver for such modems to send data via
USB ethernet rather than fallback to PPP.
The Quectel EC21 modem does not understand the AT+CPSB command, and we
did not find a suitable replacement in the
Quectel_EC25&EC21_AT_Commands_Manual_V1.3.pdf
AT+CPSB gives an error on this modem, so we just skip it.
I had some trouble getting network strengh and access technology the
standard way on Quectel EC21. It does work - but only kind of. I did not
get URCs when I am sure I should. This way through CIEV, CIND and CMER
is also not documented in Quectel documentation, so I suspect this to be
unsupported.
This is now changed to the "quectelish" way of gettings those values and
this does work more fine-grained and reliable on the Quectel EC21.
The distinction between OFONO_VENDOR_QUECTEL and
OFONO_VENDOR_QUECTEL_SERIAL does not suffice for EC21/EC25 in some
places, so introduce and use a new vendor:
OFONO_VENDOR_QUECTEL_EC2X
Commit 6c574ee24a ("huawei: the AT^SYSCFGEX
command supports additional modes") has a mistake for acqorder "0201". It
should be UMTS and GSM preferred.
- LTE and UMTS preferred (acqorder = 0302);
AT^SYSCFGEX="0302",40000000,2,4,40000000
- UMTS and GSM preferred (acqorder = 0201);
AT^SYSCFGEX="0201",40000000,2,4,40000000
For AT^SYSCFG, the modes are not available.
AT^SYSCFGEX must be used on LTE Huawei modems to enable LTE support.
But some modems (or firmwares?) do not support this command and AT^SYSCFG
must be used to get/set radio settings.
This has been introduced in commit:
22adf6402c
There is a bug in this commit and AT^SYSCFGEX commands are used even on
modems not supporting it.
This implements data capability bearer notify to qmi modem.
Since this is included in the serving system response this
just adds a new data extraction for dc.
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
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.
In case a context get deactivated when a AT+CGACT=0 is
not issued, indicate that to gprs core.
This can happen if the device has an auto activated
LTE context and modem switches over to for instance UTRAN.
To detect if a context gets activated before we register
for unsolicited events we need to check if any is
already activated, and flag it auto activated.
The Quectel M95 and MC60 modems respond to AT+CGDATA=? with a single
+CGDATA="PPP", but the callback in gprs-context expects a list of
protocols.
Avoid falling back to the old-style ATD*99 by not expecting a list of
protocols for serial quectel modems.
For uBlox modems, a bit of custom setup is required, but after that the
generic "atmodem" (27.007-compatible) method implementations are
sufficient. This driver, therefore, just puts the custom probe method
into place and defers remaining functionality to the recently exported
atmodem implementations.
An upcoming netreg driver for uBlox modems will need to override the
probe method in order to set itself up, but for further functionality
the "generic" AT implementations are sufficient. The easiest way to do
this is to just set up a vtable with a custom probe implementation and
defer all other methods to the common/generic methods.
The problem is that the AT methods are not actually exported. This
generic AT functionality was not intended to be hooked directly into
other drivers.
This patch exports all the methods of the atmodem network-registration
driver implementation so that they can be used as generic/common
implementations for other drivers.
Lac and cellid information are optional in ss_info notifications.
Remember them in order to give a correct information each time a
notification is received.
CNMA isn't mentioned in the m95 documentation, but trial'n'error has
revealed some details:
* the CSMS query returns the list (0,128) instead of a range
* CNMA is enabled by setting 128 as CSMS service
* once enabled, SMS deliveries are acked by sending AT+CNMA without a
value setting
Add m95 quirks to the atmodem driver, so that CNMA is correctly
detected, configured, and used.
Glib emits a warning when g_hash_table_destroy() is called on a NULL
pointer:
GLib-CRITICAL **: 13:27:40.269: g_hash_table_destroy: assertion 'hash_table != NULL' failed
Add a check to avoid this warning.
Fixes:
../git/drivers/ubloxmodem/gprs-context.c: In function ‘ublox_gprs_activate_primary’:
../git/drivers/ubloxmodem/gprs-context.c:339:2: error: ‘auth’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
snprintf(buf, sizeof(buf), "AT+UAUTHREQ=%u,%u,\"%s\",\"%s\"",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcd->active_context, auth, username, password);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../git/drivers/ubloxmodem/gprs-context.c:324:11: note: ‘auth’ was declared here
unsigned auth;
^~~~
CC drivers/mbimmodem/mbim-message.o
drivers/mbimmodem/mbim-message.c: In function ‘_iter_copy_string’:
drivers/mbimmodem/mbim-message.c:199:18: error: cast increases required
alignment of target type [-Werror=cast-align]
Setting <connect_flag> in AT+XDATACHANNEL set command to 0. This will
disable intermediate result reporting of "CONNECT" and "NO CARRIER"
on control channel.
This resolves the issue of getting failure response for offline-modem
since "NO CARRIER" is received as result of AT+CFUN operation instead
of "OK".
It looks like a previous line was copied and cd->username was re-terminated
instead of password. This also fixes a compiler error when using GCC 9:
In function ‘strncpy’,
inlined from ‘isi_gprs_activate_primary’ at drivers/isimodem/gprs-context.c:546:3:
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ output may be truncated copying 53 bytes from a string of length 255 [-Werror=stringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
xmm7xxx based devices (among others) return 0 as cid for default
pdp context. Fix the atmodem gprs driver logic to work with such
devices by initializing last_auto_context_id to -1 instead of 0
to indicate a deactivated context.
Change message class none configuration from directly delivering a new
message in the event indication to storing it in the modem's NV then
sending an event indication identifying the new message. Also, add
checking for stored, unread messages at boot up.
This fixes a scenario where the modem powers on, automatically
connects to the network, receives a message, and sends an indication
before oFono has fully initialized. Now, the message is saved and
retrieved after initialization.
This also helps with suspend/resume on platforms where the modem,
supports waking the host CPU upon SMS reception. And, the platform
design limitation is that the modem's interfaces (eg, cdc-wdm, wwan,
etc) disconnect on suspend and reconnect on resume. This causes oFono
to re-initialize and miss the message indication because it was sent
before oFono is ready. Now, the wake up message is saved and retrieved
after initialization.
Sergey Matyukevich
Lars Poeschel
JongSeok Won
Jimmy Gysens
Christophe Ronco
Marius Gripsgard
Richard Röjfors
Denis Kenzior
Marcel Holtmann
Antara Borwankar
Martin Hundebøll
Pavel Machek
Jonas Bonn
James Prestwood
Tom Nguyen