GCC10 complains about the following:
src/smsutil.c: In function ‘sms_text_prepare_with_alphabet’:
src/smsutil.c:3594:8: error: implicit conversion from ‘enum sms_alphabet’ to ‘enum gsm_dialect’ [-Werror=enum-conversion]
3594 | alphabet, &used_locking,
smsutil and util has an enum each for representing
the same thing; The SMS alphabet. They share the same
values, so an explicit type cast makes GCC happy.
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.
Current implementation uses a gpio level of 1 for powering on quectel
modems using a gpio and a level of 0 for powering off.
Normally quectel modems are powered on or off by a gpio pulse on their
PWR_KEY pin. They turn on by the first pulse and turn then off by the
next pulse. The pulse length varies between different modems.
For power on the longest I could in the quectel hardware is "more than
2 seconds" from Quectel M95 Hardware Design Manual.
For Quectel EC21 this is ">= 100 ms".
For Quectel MC60 this is "recommended to be 100 ms".
For Quectel UC15 this is "at least 0.1 s".
For power off the four modems in question vary between a minimum pulse
length of 600-700ms.
This implements a 2100ms pulse for power on and 750ms for power off.
If you have some special circuitry that powers your modem by gpio level
and you need the old behaviour, you can switch to gpio level powering
by setting environment variable OFONO_QUECTEL_GPIO_LEVEL. The gpio goes
to high level for the modem to power on and to low level if it should
power off.
More complicated modems emerge and they need longer start-up times. An
EC21 takes about 13 seconds to boot up. This is slightly longer than the
20 * 500 ms we have at the moment. This extends the retries to 30, so we
have 30 * 500 ms and this does successfully power up an EC21 modem.
../../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.
CC plugins/xmm7xxx.o
../plugins/xmm7xxx.c:63:10: fatal error: dbus.h: No such file or directory
63 | #include "dbus.h"
| ^~~~~~~~
compilation terminated.
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, including ELS81x, may provide more than one
USB ethernet interface. Detect and save both network interfaces
rather than only the last one.
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
As there are some more sources of +QIND: activated, do now only update
voltage when we get the
+QIND: "vbatt",-1
but not on things like
+QIND: "act","LTE"
or
+QIND: "csq",20,99
Set the URC port of the Quectel EC21 to uart1 when it is used through
it's serial port. This setting is saved to non-volatile storage by the
modem automatically.
This reverts commit 1868dbf2b3.
Development for this was done on EC21 firmware version
EC21EFAR06A01M4G_BETA0318. It now turns out, that actual release
firmware versions for this modem again need the original mux order with
aux channel as the second mux channel. (We know for sure for firmware
version EC21EFAR06A03M4G.)
We do not know for sure when and for what firmware versions quectel did
the switch back on the mux order, but we suspect that the "BETA"
firmware is the only one with the reversed mux order. This "BETA"
firmware was only given out for development purposes and will not appear
"in the wild", so we revert the patch here and hope for the best.
Commit 6c574ee24a ("huawei: the AT^SYSCFGEX
command supports additional modes") has a mistake for acqorder "0201". It
should be UMTS and GSM preferred.
After a context is detached, the context is not properly cleared. In
addition to releasing the context:
- Reset the context settings (IP, DNS, interface, ...).
- Signal the Active flag as false.
When initializing a Huawei device, send the AT&F0 command to restore the
default AT settings on device restart.
Huawei stores all APN settings, which can cause issues when changing the
APN. The AT&F0 command makes sure the device starts from a clean state.
- 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.
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.