This facility cannot be retrieved via 'DMS UIM Get CK Status' and seems
currently unimplemented for mm-broadband-modem-qmi. The SIM enabled
status is however available via 'DMS UIM Get PIN Status'.
Using this message to add the retrieval of PIN status just after the
other facilities were queried.
Succesfully tested with Gobi2000 (05c6:9205), both retrieval of 3gpp
SIM lock status and enabling/disabling the PIN.
Bluetooth serial devices are weird. They begin life being bound with
RFCOMMCREATEDEV ioctl() and then move around the sysfs tree when they are
connected and disconnected. The connection is estabilished upon the first
open() and torn down upon last close(), their first user virtually being
"owner" of the connection. We don't want to be that process, we're only
interested in actually connected modems. However, currently we have no
knowledge of that and therefore we connect and disconnect multiple times while
probing.
This patch marks unconnected RFCOMM devices as uninteresting to us.
The actual connection and disconnection will be handled by NetworkManager.
For certain devices the name changes with their status. Notably, RFCOMM
devices move from /devices/virtual/ to underneath the HCI that is used
for the connection as the session is estabilished, and return back when
it's torn down.
My modem (Samsung GI B3740) responded "IPV4" to "CGDCONT=?". This was
not handled in mm-modem-helpers.c. The obvious fix was to return
MM_BEARER_IP_FAMILY_IPV4.
When the MBIM modem unexpectedly loses connection the port state never
gets set as disconnected thus when trying to reestablish a new
connection the bearer cannot find a port in the disconnected state.
Signed-off-by: Greg Suarez <gpsuarez2512@gmail.com>
b28230411 moved up the self->priv->forced_close = TRUE, which
caused mm_port_serial_close() to just return without actually
closing the port and cleaning up.
Also, cancel the reopen separately from closing the port since
the two operations are actually independent of each other.
This patch fixes the registration reporting/checking when ModemManager is
built with --with-newest-qmi-commands. apply_cs and apply_ps were not
properly initialised and may never be true. Also fixes a CnP error for
mm_ps_registration_state.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
This patch fixes the signal strength values when using ModemManager built
with --with-newest-qmi-commands.
It was never getting a valid signal strength because the default (0) is
always greater than a valid signal strength, and the rssi_max handling
was completely wrong.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
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.
Torsten Hilbrich
Lubomir Rintel
Aleksander Morgado
Oskar Enoksson
Greg Suarez
Dan Williams
David McCullough
Ben Chan
kuonirat
Prathmesh Prabhu