Enum ofono_radio_access_mode has been replaced by unsigned int.
This change allows to move handling of all the modes into
'switch' in the function gemalto_set_rat_mode.
Originally the enum was only meant to signify a single radio access mode
preference, but over time its meaning was overloaded to be a bitfield
with multiple preferences. Switch away from using an enum value to
using an unsigned int to make it clearer that the value is a bitfield.
Gemalto modem reports raw measurements in dBm. Reported values may
include negative numbers. Meanwhile oFono follows ETSI TS 27.007,
so negative numbers do not really exist at the API level.
Modify gemalto netmon driver to report measurements according to
27.007. For this purpose re-scale from what Gemalto firmware
reports into something that 27.007 recommends.
Implement network monitoring driver for gemalto modems that
are able to provide serving cell information and basic
measurements using AT+CQS and AT^SMONI commands.
Implement read_settings function to get configuration for automatic
contexts. AT^SWWAN command activates PDP context unless it has been
already activated automatically, and then starts DHCP server in the
ME. So AT^SWWAN command should be run for automatic context as well
in order to obtain IP settings from the ME.
This commit also fixes the issue uncovered by the added support for
automatic contexts: as per modem specs, AT+CGACT context should not
be reused for AT^SWWAN. Though that worked for some reason when
automatic context was reactivated without proper deactivation.
Note that in both cases success code is reported to the core before
AT^SWWAN response. This is because the ME waits until DHCP negotiation
has finished before sending the "OK" or "ERROR" result code.
GCC 10 warns about this implicit conversion:
drivers/huaweimodem/radio-settings.c: In function ‘band_gsm_from_huawei’:
drivers/huaweimodem/radio-settings.c:107:10: error: implicit conversion from ‘enum ofono_radio_band_umts’ to ‘enum ofono_radio_band_gsm’ [-Werror=enum-conversion]
107 | return OFONO_RADIO_BAND_UMTS_ANY;
Member from the incorrect enum was returned, both had the value 0, so
the code would still work.
../../drivers/qmimodem/network-registration.c: In function
‘extract_ss_info’:
../../drivers/qmimodem/network-registration.c:131:54: warning: ‘%03d’
directive output may be truncated writing between 3 and 5 bytes into a
region of size 4 [-Wformat-truncation=]
131 | snprintf(operator->mcc, OFONO_MAX_MCC_LENGTH + 1, "%03d",
| ^~~~
../../drivers/qmimodem/network-registration.c:131:53: note:
directive argument in the range [0, 65535]
131 | snprintf(operator->mcc, OFONO_MAX_MCC_LENGTH + 1,
"%03d",
|
^~~~~~
The MCC/MNC fields are limited to three digits. Clamp the input to 999
to avoid the warning.
Currently AT+CGEREP=2,1 is sent in case we don't know what the modem
needs. (default case) Not all modems understand this. So, we first query
what the modem supports with AT+CGEREP=? and then use this information
to be nice to the modem. This way modems, like the Quectel M95 that do
only understand AT+CGEREP=1 do also work nicely.
As the default way of getting the signal quality with +CIND is also
unstable on quectel serial modems (the same as on quectel EC21). In fact
the signal quality is only updated on cell changes. Those trigger a
manual AT+CSQ in ofono and get an update this way, but the URCs do not
work.
So we implement a quectelish way here as well. The quectelish way is
very similar to the way ifx modems work. We can reuse their csq_notify
function.
There are at the moment two quectel modems in ofono vendored as
OFONO_VENDOR_QUECTEL_SERIAL: The M95 and the MC60.
Both modems are GSM only modems, and their official documentation does
not mention the AT+CPSB command.
I have a M95 here that gives an error on issuing the AT+CPSB=1 command.
So skip this command for these two modems.
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.
