Age | Commit message (Collapse) | Author |
|
|
|
3 seconds isn't always enough to set up the context with the network.
|
|
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".
|
|
Sync with libqmi:
commit 2835a53732fdae32478dd954a9ee3fa8afd93cab
Author: Aleksander Morgado <aleksander@lanedo.com>
Date: Tue Oct 30 15:02:24 2012 +0100
libqmi-glib: define library G_LOG_DOMAIN
|
|
|
|
|
|
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.
|
|
|
|
Don't require vendor/product string probing if the plugin already had
vendor/product ID filters and we actually passed those.
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
(aleksander) I messed up the integration of commit bc49794848, this should fix
it.
|
|
|
|
|
|
|
|
All addresses are given as machine byte order, and thus must be converted
to network byte order (BE) before passing to inet_ntop().
|
|
|
|
Only force disconnection of the bearer if not registered in any network or if
registered in both 3GPP and CDMA roaming networks.
|
|
|
|
Just expose the list of supported bands when the current bands is set to 'any'.
|
|
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.
|
|
If the band isn't actually given, don't try to enable it.
|
|
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.
|
|
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=686217
|
|
|
|
This reverts commit e2f3034f6e2c79062c095be0bc4278907b32ec8f.
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.
|
|
|