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.
This reverts commit e2f3034f6e.
The report of current access technologies is supposed to give which is the
*current* access technology being active. We allow reporting more than one for
the cases where several access technologies are given simultaneously (e.g.
cdma1x + evdo + lte). For example, we shouldn't be giving 4 different
technologies like "umts, hsdpa, hsupa, hspa" when the modem reports
"3G-HSDPA-HSUPA". Just giving HSPA in that case is enough and more accurate.
Aleksander Morgado
Martyn Russell
Dan Williams
Ben Chan