Telit LTE modems use #PSNT: 4 for LTE access technology,
and #PSNT: 5 for unknown access technology, while HSDPA
modems use #PSNT: 4 for unknown access technology.
This patch fixes those #PSNT values interpretation according
to the modem capabilities.
If the modem supports ^SIND psinfo reporting, we enable the URC and
flag the access technology polling unsupported, so that we only update
access technology via the +CIEV URCs.
E.g.:
(ttyACM1): --> 'AT^SIND="psinfo",1<CR>'
(ttyACM1): <-- '<CR><LF>^SIND: psinfo,1,10<CR><LF><CR><LF>OK<CR><LF>'
Reporting initial access technologies...
Modem /org/freedesktop/ModemManager1/Modem/0: access technology changed (unknown -> hsdpa, hsupa)
...
(ttyACM1): <-- '<CR><LF>+CIEV: psinfo,4<CR><LF>'
Modem /org/freedesktop/ModemManager1/Modem/0: access technology changed (hsdpa, hsupa -> edge)
...
We also remove the explicit refresh request from the Cinterion plugin,
as this is a generic action applicable to all modems that require
polling for signal quality and/or access technology.
Plugins have two ways to update signal quality and access technology
values: via unsolicited messages or via polling periodically.
Instead of keeping separate contexts for polling signal quality and
access technology values, we setup a common timeout to trigger
both. This allows us to simplify in which case the explicit update is
required, whenever one is needed to be explicitly updated, the other
one should also be.
The logic now also allows plugins to return an UNSUPPORTED error in
either load_signal_quality() and/or load_access_technologies() to tell
the interface logic that the polling of the specific item shouldn't be
performed (e.g. if the updates are expected via unsolicited messages).
If both signal quality and access technology polling is flagged as
disabled, we totally disable the polling logic internally.
The new SignalCheckContext is bound to the lifetime of the object so
that we can keep the value of the supported flags until the object is
destroyed.
When the async method starts we store already the primary and the
optional secondary port objects in the method context, keeping a full
reference for each.
When we parse the response for the enabling command, we just reuse the
stored port objects, instead of re-querying the modem to get them, and
this makes sure that the port objects where we want to set the
unsolicited message handlers are still valid. If the ports are gone
in the middle of the enabling operation, the handlers will be set
without errors, even if the ports may likely get completely disposed
when this async method context is disposed.
Additionally, we make sure that we return an error also for the case
where there is no secondary port and the enabling on the primary port
failed.
This patch also fixes the use of the at_command_full_finish() method to
complete the at_command_full() async operation, to keep consistency.
Given that the MMTelitQssStatus enums are mapped directly to the
values read from the #QSS response, we need to make sure that we never
return a value for which we don't have an enum defined.
Also, use set_error() instead of the propagate_error() + error_new()
combo.
Currently, Telit's SIM swap implementation is stateless and
based on #QSS unsolicited messages 0/1 (SIM_REMOVED/SIM_INSERTED).
However, the user might have configured the modem in order to provide a
more detailed information, with #QSS values 2/3 (SIM UNLOCKED/SIM READY).
In this case and with current implementation, even receiving "#QSS: 3" will
trigger the "SIM swap" logic. The same issue might occur in other use cases
too, i.e. with SIM locked or when the message is received from both USB
ports.
This patch makes SIM swap implementation stateful, and it considers as an
actual SIM swap, only transitions from #QSS: 0 to #QSS: 1/2/3 and vice
versa.
This modem ends up exposing a cdc-wdm port and a WWAN network
interface, but the cdc-wdm port is totally unusable, it won't reply to
any AT command or anything.
Instead this modem can do NDISDUP via TTY, which is what the Windows
drivers are also doing.
The default setup with 100ms between GPS commands doesn't seem to be
always enough for the Engine activation step:
[1495016625.392972] (ttyACM1): --> 'AT^SGPSC="NMEA/Output","on"<CR>'
[1495016625.503885] (ttyACM1): <-- '<CR><LF>^SGPSC: "Nmea/Output","on"<CR><LF><CR><LF><CR><LF>OK<CR><LF>'
[1495016625.607650] (ttyACM1): --> 'AT^SGPSC="Power/Antenna","on"<CR>'
[1495016625.697862] (ttyACM1): <-- '<CR><LF>^SGPSC: "Power/Antenna","on"<CR><LF><CR><LF>OK<CR><LF>'
[1495016625.809393] (ttyACM1): --> 'AT^SGPSC="Engine","1"<CR>'
[1495016625.895970] (ttyACM1): <-- '<CR><LF>+CME ERROR: 767<CR><LF>'
We now setup up to 3 retries for the Engine activation step before
returning an error, and we also update to 2000ms the wait time before
the Engine activation command is run.
The AT^SGPSS command provides an easy way to just start/stop GPS, but
unfortunately it isn't supported by all Cinterion modems.
The AT^SGPSC command instead is more widely available but it requires
several steps to start and stop the different elements of the GPS
receiver.
Implement support for both, preferring AT^SGPSSS if available and
falling back to AT^SGPSC otherwise.
When checking for location capabilities, we will make sure AT^SGPSS is
supported and if it isn't we won't report GPS capabilities.
The location enable and disable paths are refactored to make it easier
to add possible new GPS commands to use instead of AT^SGPSS, if this
isn't supported (e.g. in the PLS8 devices).
The Altair, Option HSO and Samsung plugins all use the send-delay=0
setting once the modem object has been created. For consistency, use
the same setting during port probing.
Currently Dell plugin implements a retry logic of three commands
(AT+GMI, AT+CGMI, ATI1I2I3) to detect modem's vendor string.
Moreover, since Telit modems always reply to the first command, to speed
the probing time up, those modem are tagged with an Udev rule so that we
can avoid sending the other two commands at all.
However, the retry logic is in case a port needs some time to reply, so
it makes sense to apply it only to the first command. Then if the port still
does not respond with any kind of reply, that probably means that it is not
AT capable and we can skip the other AT commands as well.
Then, this patch:
- sets a maximum number of timeouts for AT+GMI to 3. After this
timeouts, the port is considered not AT-capable.
- sets AT+CGMI and ATI1I2I3 to be sent only once.
- removes Dell udev rule for tagging Telit Modems.
Currently, Telit plugin depends on ID_MM_TELIT_PORTS_TAGGED
environment variable, set by udev, for tagging modems that
support dynamic port config (#PORTCFG)
To remove this dependency from udev, Telit plugin now relies
only on the error management of the command AT#PORTCFG? itself
in order to see whether the modem supports it or not.
Add the vendor string, so it can be probed via AT commands. This allows
to support modems that are connected to a serial port.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
- Refactored mm_telit_parse_csim_response in order to correctly
recognize the following +CSIM error codes:
* 6300 - Verification failed
* 6983 - Authentication method blocked
* 6984 - Reference data invalidated
* 6A86 - Incorrect parameters
* 6A88 - Reference data not found
- Updated correspondent tests.
- Finally, some minor changes in other files for better error logging
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100374
When the GCancellable is added to the GTask, we can use a single
method call to check for the task being cancelled, and complete it
right away if so.
This patch also clears up the logic in the Novatel plugin, where the
code was trying to return "TRUE" when the task was cancelled, but
wouldn't work as the check-cancellable flag in the GTask is TRUE by
default (i.e. when completing the GTask, if it was cancelled, a
G_IO_ERROR_CANCELLED would be returned by default, regardless of any
other return value set).
This patch also introduces a small variation of the logic in the
Cinterion plugin: instead of running SWWAN=0 before completing the
async action, the command is now sent just after completion of the
async action. This shouldn't be an issue, as the SWWAN result itself
is ignored.
Allocate the results instead of passing them back on the stack, which removes
the "can't complete in idle" restriction. Also always open the QCDM port
since we can't assume it will be open already at this point.
Instead of mixing the QCDM Novatel Snapshot code directly into the
access technology checking code, split it out with its own async
result. At the same time, make sure to open the QCDM port when
it's needed, instead of assuming its already open. Since it won't
always be.
Some modems do not support CSIM lock/unlock, but they do support
querying SIM unlock retries through +CSIM command.
If CSIM lock returns with "unsupported command" do not propagate
the error and continue with the other CSIM queries instead, moreover the
CSIM lock feature is signed as FEATURE_UNSUPPORTED in Telit modem
private structure to prevent being sent again (e.g. calling CSIM
unlock AT command).
The MMPortProbe object is already referenced by the GTask object for
custom init. Instead of keeping another reference of MMPortProbe in the
CustomInitContext, this patch changes the code to simply obtain it from
the source object of GTask.
See https://lists.freedesktop.org/archives/modemmanager-devel/2017-April/004420.html
Looks like a C&P error from the AT#PSNT codepath; all the docs
I can find indicate that AT+SERVICE returns only an integer and
no commas:
<debug> (ttyUSB2): --> 'AT+SERVICE?<CR>'
<debug> (ttyUSB2): <-- '<CR><LF>+SERVICE: 3<CR><LF><CR><LF>OK<CR><LF>'
<debug> Couldn't refresh access technologies: 'Failed to parse +SERVICE response: '+SERVICE: 3''
Commit f9c63bfa0 "build,plugins: update build rules" accidentally
changed the Novatel LTE plugin from 'libmm-plugins-novatel-lte.so' to
'libmm-plugins-novatel_lte.so'. The name becomes inconsistent with other
plugin names.
The operator code (MCCMNC) may also be given encoded in the current
charset (e.g. UCS2).
Based on a patch from Colin Helliwell <colin.helliwell@ln-systems.com>
The method doing the operator name normalization takes as input the
current configured modem charset. If this is UCS2, we will now just
assume this is a hint: the string may or may not come in hex/UCS2.
This logic makes the custom operator name loading in Huawei unneeded,
if the modem is configured in UCS2, we still properly process operator
names coming in plain ASCII.
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
Vendor specific plugins that support QMI or MBIM based devices need to
handle the creation of these modems themselves.
https://bugs.freedesktop.org/show_bug.cgi?id=100372
Original patch by Aleksander Morgado.
The vendor id/string based rules should already be enough to get the
telit plugin bind telit devices.
This simplifies support for future Telit devices, as we wouldn't need
any additional change in the plugin. It also helps when working with
RS232 devices as the user wouldn't need to add the explicit tag to get
the devices bound to this plugin.
https://bugs.freedesktop.org/show_bug.cgi?id=100373
There are 2 main types of udev properties: device-specific and
port-specific.
The port-specific properties are set independently per port (e.g. port
type hints set per interface number for a given vid:pid).
The device-specific properties apply to all ports in the device. Some
of these properties are currently expected in the physical device
(e.g. ID_MM_PLATFORM_DRIVER_PROBE) while some others are expected in
each port (e.g. the plugin udev tag filters).
This patch tries to simplify the logic and just assume that the device
specific tags may be given in either the physical device or the port
device, by providing separate APIs to retrieve port-specific or
device-specific (global) properties. If the same tag is given in both
the device and the port, the one in the device takes preference.
For the generic backend, these new APIs are really useless, as all
device-specific and port-specific properties are always stored in the
port object themselves (there is no 'tree' of devices in the generic
backend, no 'physdev' device).
For the udev backend, though, there really is a difference, as the
tags may be set in port or device.
https://bugs.freedesktop.org/show_bug.cgi?id=100156
