After repeated stress tests on a few Novatel E362 modems and SIM cards,
it is revealed that a 3-second wait after SIM unlock is necessary for
reliably reading ICCID and IMSI through the SIM interface.
Some Sierra modems trigger a reset of the modem when sending +cfun=1.
All sierra modems supports a second parameter to indicate that no
reset is to be done: "+cfun=1,0".
For each port, we will construct the list of plugins to test with. In that list
we will include those plugins which are likely to handle a given port, so we
will skip all those which aren't.
To see if a plugin is likely or not, we will run the pre-probing filters before
adding them to the list, with the new `mm_plugin_discard_port_early()'. This
method will return one of these hints:
* UNSUPPORTED: The plugin will not be able to handle this port.
* MAYBE: The plugin may handle this port.
* LIKELY: The plugin may (very likely) handle this port.
* SUPPORTED: If any plugin should support the port, this is it.
Plugins reported to be 'likely' supporting the port will be probed before the
ones reported just as 'maybe'.
If a plugin reports 'supported' only that one and the fallback generic ones will
be tried.
Logging which are the reasons for a plugin to filter a given port really help
when trying to debug user issues. Some other general logging improvements also
done.
It is not the Modem interface the one notifying about the 'enabling->enabled'
transition, it's the BroadbandModem directly doing it, covering all the enabling
sequences of all the interfaces.
It is not the Modem interface the one notifying about the 'disabling->disabled'
transition, it's the BroadbandModem directly doing it, covering all the
disabling sequences of all the interfaces.
If the modem is currently disabling, we need to wait to get fully disabled
before starting with the new connection sequence.
If the modem is currently disconnecting, we need to wait to get fully
disconnected before starting with the new connection sequence.
If we are requested to cancel the connection, we first need to wait for the
connection attempt to finish before issuing the disconnect command, as otherwise
the modem just returns an error saying that it cannot perform the operation and
at the end we end up with the modem connected but ModemManager thinking that it
isn't.
If we are requested to cancel the connection, we first need to wait for the
connection attempt to finish before issuing the disconnect command, as otherwise
the modem just returns an error saying that it cannot perform the operation and
at the end we end up with the modem connected but ModemManager thinking that it
isn't.
Tries to fix https://bugzilla.gnome.org/show_bug.cgi?id=685578
Before the change, the client application loses all new property change
notifications in the interface object:
$ sudo mmcli -m 0 -w
/org/freedesktop/ModemManager1/Modem/0: Initial state, 'locked'
/org/freedesktop/ModemManager1/Modem/0: State changed, 'locked' --> 'initializing' (Reason: None or unknown)
After the change, it doesn't:
$ sudo mmcli -m 0 -w
/org/freedesktop/ModemManager1/Modem/0: Initial state, 'locked'
/org/freedesktop/ModemManager1/Modem/0: State changed, 'locked' --> 'initializing' (Reason: None or unknown)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'initializing' --> 'disabled' (Reason: None or unknown)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'disabled' --> 'enabling' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'enabling' --> 'registered' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'registered' --> 'disabling' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'disabling' --> 'disabled' (Reason: User request)
In QMI modems the logic behind supported and current bands is completely
separated in different services (DMS vs NAS). Actually, the list reported by NAS
as current band preferences seems to include more values than the ones reported
by DMS as supported bands (e.g. CDMA bands are reported even if the firmware
image is GSM/HSPA only).
So, just clean up the list of current preferred bands so that no more than those
given as supported is used.
The $NWQMISTATUS command sometimes replies an ERROR shortly after
calling the $NWQMICONNECT command, but then replies the proper QMI
status if we retry it. This behavior is observed on an E362 modem with
4.08 firmware.
(ttyUSB0): --> 'AT$NWQMICONNECT=,,,,,,"",,,"",""<CR>'
(ttyUSB0): <-- '<CR><LF>OK<CR><LF>'
(ttyUSB0): --> 'AT$NWQMISTATUS<CR>'
(ttyUSB0): <-- '<CR><LF>ERROR<CR><LF>'
Got failure code 100: Unknown error
QMI connection status failed: Unknown error
In firmware 4.08, the $NWQMISTATUS command returns different values for
QMI state to indicate the current connection state. This patch modifies
the code to handle $NWQMISTATUS responses in firmware 1.41 and 4.08.
We do need to specify which is the primary port being used for controlling the
modem. This allows us to match the device with an already existing bluetooth
device in NetworkManager.
