Age | Commit message (Collapse) | Author |
|
(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.
|
|
|
|
|
|
|
|
Or the modem will get stuck completely.
|
|
We'll just skip most SIM info retrieval commands based on AT+CRSM, as they seem
to be unsupported.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This WWAN module came installed in my new HP EliteBook 8570p Laptop.
The patch is generated against the master branch but the same udev
rule should be useful in the 0.5 and 0.6 branches as well.
Signed-off-by: David Härdeman <david@hardeman.nu>
|
|
|
|
|
|
The interfaces usually retrieve objects (e.g. skeletons) from the Modem object
using g_object_get(), but we didn't make sure that these objects were actually
valid before using them.
This should clean up errors happening when the modem gets unplugged and still
some actions are ongoing.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=685933
|
|
|
|
When the modem gets unplugged all ports disappear from the modem, so don't
assume the port is always given.
E.g. if the unplug happens in the middle of the initialization sequence we may
end up with nasty segfaults:
Crash reason: SIGSEGV
Crash address: 0x0
Thread 0 (crashed)
0 ModemManager!mm_qmi_port_peek_client [mm-qmi-port.c : 50 + 0x0]
rbx = 0x00007fbb5c1d8010 r12 = 0x0000000000000003
r13 = 0x00007fbb5c1f9880 r14 = 0x00007fbb59a30980
r15 = 0x00007fbb5c187a60 rip = 0x00007fbb5a1a54c0
rsp = 0x00007fffc6c0f628 rbp = 0x00007fffc6c0f650
Found by: given as instruction pointer in context
1 ModemManager!peek_qmi_client [mm-broadband-modem-qmi.c : 109 + 0x24]
rbx = 0x00007fbb5c1d8010 r12 = 0x0000000000000003
r13 = 0x00007fbb5c1f9880 r14 = 0x00007fbb59a30980
r15 = 0x00007fbb5c187a60 rip = 0x00007fbb5a193851
rsp = 0x00007fffc6c0f630 rbp = 0x00007fffc6c0f650
Found by: call frame info
2 ModemManager!ensure_qmi_client [mm-broadband-modem-qmi.c : 132 + 0x4]
rbx = 0x00007fbb5c1d8010 r12 = 0x00007fbb5a165140
r13 = 0x00007fbb5c1f9880 r14 = 0x00007fbb59a30980
r15 = 0x00007fbb5c187a60 rip = 0x00007fbb5a1938e4
rsp = 0x00007fffc6c0f650 rbp = 0x00007fffc6c0f690
Found by: call frame info
...
Reported by: Ben Chan <benchan@chromium.org>
|
|
It really may get worse than 10s, specially if the modem changes access
technologies after getting registered.
|
|
Specifying 'none' is really not exclusive. We may want to say that the modem can
either authenticate with a given protocol, or otherwise just try without
authentication.
The reality is that 'none' itself is usually always given in the connection
settings.
|
|
|
|
|
|
This is the port to git master of the following commit:
commit ff8c60641aa2ea41080c15f81f633b3f78e07bf8
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Sep 10 17:12:38 2012 -0500
via: new plugin for CBP7-based CDMA and EVDO devices (bgo #683525)
The Via baseband is used in a number of CDMA/EVDO devices, from
ChinaTelecom USB sticks, to the Fusion Wireless/UBlox 2770p, to
various Motorola Android phones.
|
|
|
|
|
|
If no matching found, but there is only one QMI port and only one data port,
assume that is already a valid match.
|
|
Use the new `qmi_utils_set_traces_enabled()' to specify that we want QMI traces
when running with DEBUG logs.
Sync with libqmi:
commit 35dcb4bb6ed2755d968cf97d69faff9ed5f6871f
Author: Aleksander Morgado <aleksander@lanedo.com>
Date: Tue Oct 9 13:44:16 2012 +0200
libqmi-glib: message traces compiled always
Message traces have been very useful when debugging issues in the protocol, and
we should avoid requiring a full recompilation in order to get them enabled.
Instead, we provide two new API methods, `qmi_utils_(get|set)_traces_enabled()',
which allow specifying whether traces should be dumped with g_debug() or not.
|
|
If none of the specified methods is supported, an error is returned.
|
|
|