This reverts commit 27113dae.

It's now included upstream in the broadmobi plugin.

Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/228

  T:  Bus=01 Lev=02 Prnt=04 Port=01 Cnt=01 Dev#= 40 Spd=480 MxCh= 0
  D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
  P:  Vendor=1e2d ProdID=005d Rev=17.30
  S:  Manufacturer=Cinterion Wireless Modules
  S:  Product=PLSx
  C:  #Ifs=12 Cfg#= 1 Atr=e0 MxPwr=100mA
  I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm
  I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
  I:  If#=0xa Alt= 1 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
  I:  If#=0xb Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
  I:  If#=0x2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm
  I:  If#=0x3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
  I:  If#=0x4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm
  I:  If#=0x5 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
  I:  If#=0x6 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm
  I:  If#=0x7 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
  I:  If#=0x8 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm
  I:  If#=0x9 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm

Like the mPLS62-w when setup to be controlled in MBIM mode instead of
plain AT commands.

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.

When the device goes from LTE to UMTS, we must make sure we also
always update the EPS registration state as unknown, or the built
consolidated state will be wrong.

Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/225

Maxim Anisimov authored Jun 05, 2020 and Aleksander Morgado committed Jun 05, 2020

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>

Maxim Anisimov authored Jun 05, 2020 and Aleksander Morgado committed Jun 05, 2020

We need to change json output escaping according to this
https://bugzilla.gnome.org/show_bug.cgi?id=730425



Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>

So that the limited iconv() in OpenWRT supports the conversion properly.

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.

We're using QMI over MBIM to perform the reset if the device is QMI
based.

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
21a5aaf4, 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.

The old 'default' policy is renamed to 'legacy', and is considered now
deprecated.

Which must be the minimum set of supported messages required by
ModemManager.