This allows MMKernelDevice::cmp to compare two kernel devices
with different object types, which means that subclasses can
continue to only handle comparisons with their own type. The
order may not be stable across builds.
The cellular operator can break the interactive USSD session. In this case, it is necessary
to process this situation otherwise --3gpp-ussd-initiate or --3gpp-ussd-respond will give an error.
Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
Until now, the plugin whitelist rule in the filter would only handle
those plugins that require specific udev tags, and those that had
explicit full vid:pid pairs.
This update makes a new implicit automatic whitelist for all devices
that match any of the vids managed by the different plugins.
Looking at the current list of devices in the blacklist and greylist
maintained by ModemManager, there are no devices falling under the
list of supported plugin vids that would need to be blacklisted;
except for u-blox GPS modules:
huawei -> 0x12d1 -> None in blacklist/greylist
thuraya -> 0x1a26 -> None in blacklist/greylist
telit -> 0x1bc7 -> None in blacklist/greylist
dLink -> 0x2001 -> None in blacklist/greylist
wavecom -> 0x114f -> None in blacklist/greylist
x22x -> 0x1bbb,0x0b3c -> None in blacklist/greylist
anydata -> 0x16d5 -> None in blacklist/greylist
quectel -> 0x2c7c -> None in blacklist/greylist
haier -> 0x201e -> None in blacklist/greylist
novatel -> 0x1410 -> None in blacklist/greylist
dell -> 0x413c -> None in blacklist/greylist
option -> 0x0af0,0x1931 -> None in blacklist/greylist
nokia -> 0x0421 -> None in blacklist/greylist
cinterion -> 0x1e2d,0x0681 -> None in blacklist/greylist
simtech -> 0x1e0e -> None in blacklist/greylist
iridium -> 0x1edd -> None in blacklist/greylist
pantech -> 0x106c -> None in blacklist/greylist
longcheer -> 0x1c9e,0x1bbb -> None in blacklist/greylist
linktop -> 0x230d -> None in blacklist/greylist
sierra -> 0x1199 -> None in blacklist/greylist
ublox -> 0x1546 -------------> GPS chips blacklisted !!!!!
foxconn -> 0x0489 -> None in blacklist/greylist
broadmobi -> 0x2020 -> None in blacklist/greylist
fibocom -> 0x2cb7 -> None in blacklist/greylist
tplink -> 0x2357 -> None in blacklist/greylist
zte -> 0x19d2 -> None in blacklist/greylist
The rules used to blacklist the u-blox GPS chips have already been
moved to the u-blox plugin itself, and now they use the broader
ID_MM_DEVICE_IGNORE tag that applies in all filter modes.
Instead of setting up the ID_MM_TTY_BLACKLIST tag used in 'legacy'
filter mode, tag all known u-blox GPS devices with the broader
ID_MM_DEVICE_IGNORE tag that applies under all filter modes.
Also, make this rules be installed by the plugin itself, because at
the end, it is the u-blox plugin the one attempting to probe all
devices with vid 0x1546.
Running NDISDUP=1,0 on an already disconnected bearer/context will
report ERROR, so we can really ignore the result of the command,
because we're anyway going to get the correct bearer/context status
later on with the NDISSTATQRY checks.
When a network-initiated event is received telling us that a
bearer/context is disconnected, we should handle and process it right
away, without thinking on whether there is going to be a
user-requested disconnect afterwards or not.
This effectively reverts the changes introduced in commit
21a5aaf4fe, which looks like was done to
handle synchronization issues with upper layers (e.g. with
NetworkManager or Shill).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/205
The 'strict' filter policy is less invasive, as it will not touch TTYs
unless there are clear indications that it may be a modem. Under this
mode, the ModemManager-provided blacklist database is not used.
==80079== 104 (40 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 4,761 of 5,232
==80079== at 0x483977F: malloc (vg_replace_malloc.c:309)
==80079== by 0x5025AE9: g_malloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x5006223: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x505B0F4: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x2008A3: firmware_change_current (mm-broadband-modem-qmi.c:8426)
==80079== by 0x1AB5F3: select_auth_ready (mm-iface-modem-firmware.c:225)
==80079== by 0x4E68653: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x4E6DA26: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x17402E: authorize_ready (mm-base-modem.c:1363)
==80079== by 0x4E68653: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x4E6DA26: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x15366D: check_authorization_ready (mm-auth-provider.c:99)
==80079== 1,377 (48 direct, 1,329 indirect) bytes in 1 blocks are definitely lost in loss record 5,200 of 5,232
==80079== at 0x483977F: malloc (vg_replace_malloc.c:309)
==80079== by 0x5025AE9: g_malloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x5006223: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x4FEB59B: ??? (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x4FEE378: g_variant_builder_end (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x48F8314: mm_firmware_properties_get_dictionary (mm-firmware-properties.c:337)
==80079== by 0x1AAF29: load_current_ready (mm-iface-modem-firmware.c:80)
==80079== by 0x4E68653: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x4E68688: ??? (in /usr/lib/libgio-2.0.so.0.6400.2)
==80079== by 0x502B58E: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x502D530: ??? (in /usr/lib/libglib-2.0.so.0.6400.2)
==80079== by 0x502E542: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.6400.2)
