Since this plugin uses a bitmask to represent bands, we have
to be wary of shifting outside the precision of the bitmask
storage type. In this case, it was possible to generate 1 << 31
in a signed integer type as an intermediate step of B3G_FLAG,
which is undefined behavior (and usually results in INT_MIN,
breaking comparisons with the value).
Bug was reported to the chromium tracker at crbug.com/1019301
Original patch updated by Aleksander Morgado to leave
MM_MODEM_BAND_TELIT_3G_LAST as MM_MODEM_BAND_UTRAN_19, as that is the
highest 3G band supported by the current implementation. Worth noting
that this was not a real bug as the maximum flag we would have been
setting was (1 << 19) anyway.
It was observed that sporadically it may take more than 5 seconds for modem to
respond to AT#REBOOT. Increase the timeout on AT command to not report
unnecessary errors to the user.
And added support for several new things, including:
* Setting "any" band now attempts to set all supported bands.
* Added new 2G band value '5' (egsm+dcs+pcs+g850).
* Setup support for two different 3G band combinations, a default one
plus an alternate one applicable to the LM940/960 models only. The
alternate combination is selected via udev tags.
During the refactor, the following Telit-specific helpers were also
removed and exchanged with more generic counterparts.
* mm_telit_bands_contains() -> mm_common_bands_garray_lookup()
* mm_telit_get_band_flags_from_string() -> mm_parse_uint_list()
We keep the pflags input in mm_base_modem_grab_port() so that plugins
can use other methods to gather port type hints (e.g. querying with AT
commands as in Huawei/Telit or looking at sysfs properties as in HSO).
For standard udev tag port type hints, it will be the base modem
looking them up.
Note that there is no longer any need to ignore non-flagged ports for
those modems that require primary/secondary flags. They will be
implicitly ignored when mm_base_modem_organize_ports() decides which
ports to use, as the flagged ones are preferred over the non-flagged
ones.
We define 3 common udev tag ids to be used by all plugins:
* ID_MM_PORT_TYPE_AT_PRIMARY: the primary modem port. It will be used
for AT control and also as PPP if there is no other port flagged
explicitly to do PPP.
* ID_MM_PORT_TYPE_AT_SECONDARY: the secondary modem port. It will be
used when/if the primary port gets connected to do PPP.
* ID_MM_PORT_TYPE_PPP: the port to be used to do PPP only. This tag
makes sense only when the primary port shouldn't be used for PPP,
i.e. when there is a port dedicated to do PPP and one port
dedicated for control.
When a new USB device is hotplugged, e.g. a USB<->RS232 converter that
exposes a single ttyUSB0, these udev events happen:
add /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
add /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
bind /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
Our udev rules in MM only added tags in the 'add' events, and it looks
like the only ones 'persistent' after this sequence are those of the
last event happening on the specific path.
This meant that all TTY subsystem rules (e.g. ID_MM_CANDIDATE) would
be stored for later check (e.g. if ModemManager is started after these
rules have been applied), which was ok. "udevadm info -p ..." would
show these tags correctly always.
But this also meant that the 'bind' udev event happening for the USB
device didn't get any of our device-specific tags, and so we would be
missing them (e.g. ID_MM_DEVICE_MANUAL_SCAN_ONLY) if MM is started
after the last event has happened. "udevadm info -p ..." would
not show these tags.
Modify all our rules to also run at the 'bind' events.
See, for context:
https://github.com/systemd/systemd/issues/8221
The generic broadband modem provides a common method to load unlock
retries based on CSIM queries. We modify the Telit plugin to use the
generic method but keeping the CSIM locking/unlocking logic in place.
When in low-power mode, some modems will not dispatch unsolicited
notifications, such as for SIM hot swapping. There is code in
MMBroadbandModemTelit to handle this by checking the SIM identifier
during modem power up against the identifier cached in the SIM
D-Bus object. If they're different, the SIM has likely been
swapped while we were powered down.
We can move this code out to MMBroadbandModem because it doesn't
actually rely on any Telit-specific details, and invoke it from
MMIfaceModem via a new method.
Updated to use the non-deprecated MMModemBand values.
Also, use explicit enums for 2G/3G bands when building internal flags,
as relying on UTRAN band 7 (MM_MODEM_BAND_U2600) being greater than
UTRAN bands 8 and 9 is a MM implementation issue.
We were getting the SIM object for all paths, but only using (and
disposing it) in the AFTER_POWER_UP_STEP_GET_SIM_IDENTIFIER step.
Update the logic to only retrieve, use and dispose the SIM object in
the step that is needed, and therefore avoid leaking it in the
remaining steps.
When transitioning between power-low and power-on modes, Telit modems
switch the SIM off/on, which leads to the emission of #QSS unsolicited not
related to actual SIM swaps.
To handle this #QSS unsolicited, this patch:
* disables reacting on #QSS unsolicited when modem_power_down is received
* implements modem_after_power_up that:
- checks whether the SIM has been changed, matching cached SIM
Identifier with the value in the current SIM. If SIM Identifier,
is different, sim hot swap ports detected is called.
- re-enables reacting on #QSS unsolicited
With some modems, the lock/unlock of the SIM-ME interface with +CSIM=1/0
command is followed by #QSS unsolicited messages. With the current
implementation, this messages are mistaken for SIM swap events and so the
modem is first dropped and then re-probed.
With this patch, the plugin takes into account the SIM-ME lock state when
parsing #QSS unsolicited, so that the QSS handler can correctly
elaborate the messages that are not related to SIM swap events.
Currently, when SIM hot swap fails in either mm-iface or plugin, the
ModemManager still opens ports context and prints a message saying that
SIM hot swap is supported and that it's waiting for SIM insertion,
instead of clearly saying that SIM hot swap is not working.
This patch:
1. introduces a new property MM_IFACE_MODEM_SIM_HOT_SWAP_CONFIGURED
which is FALSE by default and set to TRUE only when
setup_sim_hot_swap_finish() succeded.
2. subordinates the completion of SIM hot swap setup (in
mm-broadband-modem) and the related messages to the the value of
MM_IFACE_MODEM_SIM_HOT_SWAP_CONFIGURED
Finally, this patch replaces the MBIM's sim_hot_swap_on private property
with the new property MM_IFACE_MODEM_SIM_HOT_SWAP_CONFIGURED, since they have the
same meaning.
Commit acf101335 ("telit: port mm-broadband-modem-telit to use GTask")
ported most of the modem_set_current_bands code to use GTask, but missed
a few g_simple_async_report_error_in_idle calls, which potentially leads
to an incorrect G_TASK cast in modem_set_current_bands_finish.
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.
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.
Daniele Palmas
Krzysztof Drobinski
Eric Caruso
Aleksander Morgado
Krzysztof Drobinski
Ville Skyttä
Colin Helliwell
Carlo Lobrano
Ben Chan