The new 'ID_MM_PORT_IGNORE' tag will tell ModemManager to fully avoid using a
given port.
Note that it is key to not only flag the port probe as ignored, but also to
fully ignore the ports in e.g. mm_port_probe_list_has_qmi_port() as those
methods will be used to decide which kind of modem object to create. We don't
want to create a QMI-based modem which may have all QMI ports blacklisted.
E.g. this would be the result when having ModemManager compiled without QMI
support, and a modem with 2 QMI/WWAN pairs:
$ mmcli -m 2
/org/freedesktop/ModemManager1/Modem/2 (device id '417e4dcff7f232b62cfe6c972e2099701848fd7f')
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7304'
| revision: 'SWI9X15C_05.05.02.00 r19147 carmd-fwbuild1 2013/11/15 13:54:28'
| supported: 'gsm-umts'
| current: 'gsm-umts'
| equipment id: 'unknown'
-------------------------
System | device: '/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7'
| drivers: 'qcserial, qmi_wwan'
| plugin: 'Gobi'
| primary port: 'ttyUSB8'
| ports: 'ttyUSB8 (at), wwp0s29u1u7i8 (unknown), ttyUSB6 (qcdm), wwp0s29u1u7i10 (unknown)'
The /dev/cdc-wdm ports don't even appear (as they were not even probed), but the
newly ignored WWAN ports do appear in the list, but flagged as UNKNOWN type
(instead of NET).
Modems may expose ports that are either just not used (e.g. modems exposing more
than 2 functional AT ports) or explicitly avoided (e.g. WWAN ports when we don't
know how to use them).
Those kind of ports are part of the modem, but not used by ModemManager. Still,
ModemManager should list them in the list of ports available for the modem, with
IGNORED type.
Some newer modems (Huawei E1750, Sierra 73xx) provide what looks like
legitimate static IPv4 configuration through the WDSGetCurrentSettings
call, but when configured the interface does not pass traffic. Running
DHCP on the same interface provides a slightly different IPv4
configuration but does allow traffic to pass.
Since QMI was switched to static originally for consistency with IPv6
and for speed of IP configuration (since DHCP takes a bit of time), but
not for any known problems with modems, let's switch back to DHCP until
we have time to figure out what's actually going on.
We have a report of a modem that switches access technologies frequently,
in this case almost every 10 seconds. While that's unusual, it's not
unexpected depending on the RF environment. We shouldn't spam syslog
with that info; if we need it we can get it with mmcli.
So, we may have modems with multiple /dev/cdc-wdm ports, like Ericsson modems,
where only 1 of them is MBIM. With the previous logic, we would probe all
/dev/cdc-wdm ports for MBIM as soon as one of the ports was handled by the
cdc_mbim driver. That is totally not optimal, as we are already know that they
are not MBIM (not handled by cdc_mbim).
Instead, fix the logic to just probe for MBIM or QMI if the actual driver
managing the port is MBIM or QMI.
It's been observed that some modems occasionally take a long time to
power down (which may be due to some shutdown sequence that involves
communicating with network). This patch increases the timeout for
powering modem up and down from 10s to 20s.
It's been observed that modems may take a long time to disconnect from
the network under certain network conditions. This patch increases the
timeout for the MBIM_CID_CONNECT set command in the disconnect sequence
from 10s to 30s.
VID/PID: 258d:e000
Instead of returning success and the PIN type + PIN status + Remaining attempts,
this modem returns a plain ERROR_PIN_REQUIRED error, so try to handle that...
Standard GPS setup (raw/nmea) will both enable the GPS module and take full
control of the GPS port. This prevents other processes from reading the NMEA
traces from e.g. a tty. In order to handle this, a new 'unmanaged' GPS location
source is introduced, which will just enable/disable the GPS module, without
reading anything from the GPS port. Of course, both raw/nmea and unmanaged
setups cannot be enabled at the same time.
The first case, with no error, needs to check that there was no original error.
Currently, if an error occurs and the resulting NwError is parsed correctly, the
case split treats it as a no-error case.
Commit 55e40ea b1ae81a in libmbim ("libmbim-glib: add additional GMM
cause codes to MbimNwError") added one more GMM cause code to
MbimNwError. This patch maps that to MMMobileEquipmentError.
This patch requires libmbim >= 1.9.0
When trying to disconnect bearer, if the modem responds with
MBIM_STATUS_ERROR_CONTEXT_NOT_ACTIVATED, take it to mean that the bearer has
already been disconnected.
Subclasses may need to know which IP families were used for the setup
so they can return the correct IP configuration. We can't just use
the MMBearer default_ip_family becuase that isn't the family that
was actually used during the connection.
Commit b1ae81a in libmim ("libmbim-glib: add additional GMM cause codes
to MbimNwError") added additional GMM cause codes to MbimNwError. This
patch maps some of those MbimNwError to MMMobileEquipmentError.
This patch requires libmbim >= 1.9.0
Update PCO handling code such that it conforms to the latest VZW network
behavior. This includes updating the way we mark a SIM as provisioned.
In the old network, only provisioned SIMs can attach to the network.
Now, unprovisioned SIMs can attach and connect to the network.
Change-Id: Ie454f6fb6d8764161f167e93a4235bb93fbde59a
If a task is marked as defer-until-suggested (e.g. a wwan port) and there was
already a 'best' plugin set in the parent device, use it to complete the
deferred task.
This may happen in e.g. MBIM devices if the WWAN port arrives later than the
already probed /dev/cdc-wdm character device.
A device like this shows up briefly while the Sierra EM7345 is booting:
P: Vendor=8087 ProdID=0716 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
We do have a driver identifying this as an "Infineon Flashloader"
device. It is not a modem in any case, and should be ignored.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
If the initialization of the Modem3gpp / ModemCdma interface fails, the
modem transitions to the FAILED state. But since the Modem interface is
already initialized and exported over DBus, it is possible to invoke the
Enable method on the Modem interface. This patch changes
MMBroadbandModem to report an error if one tries to enable the modem in
the FAILED state instead of raising an assertion.
Aleksander Morgado
Dan Williams
Ben Chan
kuonirat
Prathmesh Prabhu
Thieu Le
Yegor Yefremov
Bjørn Mork