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.
Don't blindly try '+CMER=3,0,0,1' to enable and '+CMER=0' to disable
Mobile Equipment Event Reporting. We now query the device for the
supported formats and use that info to build commands that will work.
The whitelist made all platform TTYs managed by the 'atmel_usart'
kernel driver probed by ModemManager, which isn't something we want,
as most of these aren't broadband modems.
We leave the logic supporting the ID_MM_PLATFORM_DRIVER_PROBE udev tag
as there may be a case where the user does need ModemManager to probe
a given platform TTY.
The user can build the project passing custom CFLAGS to enable the
function location information, e.g.:
$ ./configure --prefix=/usr CFLAGS="-DMM_LOG_FUNC_LOC"
Group together all options that allow configuring the logging output,
and make them have the same --log-[XXX] prefix.
Also rework the --help output so that all option groups are printed by
default (i.e. there is no longer a --help-all option).
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.
Blacklist the default VID:PID for the Linux USB Serial Gadget in ACM
mode:
{LINUX}/drivers/usb/gadget/legacy/serial.c
#define GS_VENDOR_ID 0x0525 /* NetChip */
#define GS_CDC_PRODUCT_ID 0xa4a7 /* ... as CDC-ACM */
This should never be reused for real products by hardware
manufacturers, but anyway...
Patch actually ported from downstream Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1105352
If going directly e.g. from "Searching" to "Connecting", just setup
the signal quality retrieval logic right away, don't assume we always
go through "Registered" state before starting a connection.
Reported-by: <colin.helliwell@ln-systems.com>
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>
Commit 26ee94ec28 introduced a bug, where we would be completing
the client allocation task *before* tracking the new client allocation
info in the private tracking list.
This meant that if mm_port_qmi_peek_client() was called in the task
completion handler, the client object wouldn't be returned, as it
wasn't found in the private tracking list.
The fix is just to defer the task completion until after the private
tracking list is updated.
Reported-by: Salvador Penalva <salvador.penalva@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.
During modem initialization we detected the flow control settings
supported by the modem, and selected the best one to use from them,
notifying it to the device via AT+IFC. The device was therefore
instructed to use that flow control setting for data transmission in
the TTY (i.e. not during AT control commands).
The missing thing was to also configure ourselves our end of the
serial port with the same flow control settings when getting into data
mode. By doing it ourselves, we avoid requiring any explicit setting
in pppd for flow control; pppd can assume the flow control settings
are already the expected ones.
Worth noting that all this setup is completely ignored for TTYs
exposed directly via USB.
https://bugs.freedesktop.org/show_bug.cgi?id=100394
Instead of assuming XON/XOFF is supported, we query the supported flow
control modes, and then we set the best one based on that, preferring
hardware flow control over software flow control.
Instead of having the parser return separate list of supported flow
controls for TE and TA, we simplify it by only returning those
settings that apply to both TE and TA.
This logic isn't perfect either, though, as some settings (e.g. '3' in
TE in some modems, specifying a different XON/XOFF behavior) may not
have a corresponding setting in the other end.
The most common cases we care about (i.e. standard XON/XOFF, RTS/CTS)
should be properly reported with this logic.
