| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Allows returning the IP method, prefix, and gateway along with other
information.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need the kernel driver to give a proper value for the 'closing_wait'
variable, but don't assume it will.
This should solve the following kind of issues reported by valgrind:
==8985== Conditional jump or move depends on uninitialised value(s)
==8985== at 0x4409A6: mm_serial_port_close (mm-serial-port.c:932)
==8985== by 0x41A420: disable_all_done (mm-generic-cdma.c:753)
==8985== by 0x4125A4: mm_manager_shutdown (mm-manager.c:1130)
==8985== by 0x40DE35: main (main.c:203)
|
|
|
|
| |
Makes it easier to understand the code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GError passed to simple_reg_callback() is coming from
(MMCallbackInfo *)info->error, and therefore shouldn't be freed.
https://bugzilla.gnome.org/show_bug.cgi?id=689289
For reference, reported by valgrind as:
==8985== Invalid free() / delete / delete[] / realloc()
==8985== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8985== by 0x40ED4B: mm_callback_info_unref (mm-callback-info.c:244)
==8985== by 0x56FB0E7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x56FB6E9: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x56FDADF: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x56FDDC7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x56FE1C1: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x40DE22: main (main.c:199)
==8985== Address 0xa600770 is 0 bytes inside a block of size 16 free'd
==8985== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8985== by 0x40EDD3: callback_info_done (mm-callback-info.c:89)
==8985== by 0x56FB0E7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x56FB6E9: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x56FDADF: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x56FDDC7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x56FE1C1: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.2)
==8985== by 0x40DE22: main (main.c:199)
|
| |
|
|
|
|
|
|
|
|
|
| |
Many Huawei CDMA modems implement vendor commands for 1x and EVDO
signal quality, so use them since they are more accurate than the
generic signal checking.
(dcbw: reorganize a bit; add fallbacks on error; consolidate
signal quality parsing with unsolicited handlers)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two issues:
1) if there was a generic error with the +CIND response, the
code set the callback error, scheduled the callback, but then
continued with +CIND and possibly +CSQ. That could overwrite
the original error (a memory leak) and trigger warning about an
already-scheduled callback. Instead, just ignore the error and
request +CSQ as a fallback.
2) If +CIND parsing failed, the parse error was set on the
callback, but +CSQ was also requested. Thus if +CSQ was
successful, the +CIND error would still be returned. Instead,
just ignore the +CIND parsing error (but log it) and request
+CSQ as a fallback.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
It appears that GIOChannel might also do some flushing, so make sure
our warning captures that delay if there is one. Also be paranoid
and make sure nothing reset our closing_wait value.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=688213
|
|
|
|
|
|
|
|
|
| |
Some devices (e173) appear to lie about NDIS support; GETPORTMODE reports NDIS
is enabled, but that port is actually the MDM port and responds to AT commands.
So, if we get a port reported as NDIS and none reported as MDM, use the one
reported as NDIS for PPP.
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1057186
|
|
|
|
| |
3 seconds isn't always enough to set up the context with the network.
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) all Sierra devices appear to require short delay after powering up,
otherwise subsequent commands may return errors. Older devices need
longer so ensure new devices are penalized just for being new.
2) When the modem is already in full functionality status and no power
up command was sent, there's no need to delay, which was happening
regardless of what state the modem was already in. Detect whether
the power up was actually executed (response and error will be NULL)
and only delay if it was executed.
|
|
|
|
|
|
|
| |
Some Sierra modems trigger a reset of the modem when sending +cfun=1,
which is more likely when +cfun=4 is used for powering down since +cfun=1 is
skipped if mode is already 1. All sierra modems supports a second parameter
to indicate that no reset is to be done: "+cfun=1,0".
|
| |
|
|
|
|
|
|
|
|
|
| |
The flag to get the plugin sorted last allows us to ensure that all plugins
without vendor/product string probing (e.g. vendor/product ID probing) are run
before. We don't want the Via plugin to start probing e.g. Huawei modems.
In git master this flag in the plugin is not needed, it is automatically ordered
last if vendor/product ID probing is set in the plugin.
|
|
|
|
| |
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=686217
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
Some devices say they support +CIND signal reporting, but either
actually don't, or they report signal for a non-current access
technology that we don't care about. So if +CIND reports zero
signal, fall back to +CSQ.
|
|
|
|
| |
Makes the next change clearer.
|
|
|
|
|
|
|
|
| |
If a port finishes probing from the first plugin, and then starts
being probed by a second plugin, and then a different port finishes
probing and creates a Modem object for that device, always let the
Modem object's plugin grab the port and ignore any other plugin.
Only one plugin may control modem ports.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
AT+CAD is fairly unreliable as a registration state detection
mechanism, and apparently devices like the Via CBP7x modems
don't bother to report anything useful here. So let plugins
skip the AT+CAD queries for registration state and just use
their own specific commands.
|
|
|
|
| |
(AT+ZSNT=0,0)
|
|
|
|
|
|
|
|
|
| |
If the returned string in the +CLCK queries doesn't include the "+CLCK:" prefix,
more specifically the ':' character, we were feeding g_regex_match() with a
NULL string (p == NULL). Solve the issue by using mm_strip_tag(), which will
return the original string if the prefix is not found.
Fixes https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1051580
|
|
|
|
| |
should be UCS2 (bgo #683817)"
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix related to the previous e07c2162d.
mm_charset_take_and_convert_to_utf8() already does a UTF-8 validity check
internally before returning the string, so it's pointless to do a new one
on the returned string.
Plus, mm_charset_take_and_convert_to_utf8() may really return NULL, which
would end up in segfaulting as g_utf8_validate() expects always a non-NULL
string.
|
|
|
|
|
|
|
|
| |
Some modems return the +COPS operator name in hex-encoded current
character set (as set with +CSCS). Others return the operator name
in ASCII when set to UCS2, while yet others return the ASCII name
with trash at the end (*cough* Huawei *cough*). Handle that better
by not crashing.
|
|
|
|
|
| |
3G preferred not supported, but use 2G/3G (exclude LTE) mode instead.
2G preferred not supported, so use 2G mode instead.
|
|
|
|
| |
Report EVDO quality to higher layers if we have it.
|
|
|
|
| |
If EVDO is registered return EVDO quality, otherwise CDMA quality.
|
| |
|
| |
|
|
|
|
|
| |
Consolidate code that adds various GValues to a GHashTable of
string:GValue.
|
|
|
|
|
|
|
| |
This is a backport of:
author Marius B. Kotsbak <marius@kotsbak.com> 2012-09-03 16:26:59 (GMT)
commit 9c2a6320a82aa301b2415227741a8bff5a33ea1b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of the following commit:
author Marius B. Kotsbak <marius@kotsbak.com> 2012-09-06 06:36:34 (GMT)
commit 02b71336ae98775c1a613b5a4133515ea7b06c4a
Updates:
AT+ZSNT=6 means LTE only
AT+ZSNT to specify 2G and 3G doesn't support 2G or 3G preference in LTE modems
Tested with a ZTE MF 820D.
|
| |
|
| |
|
| |
|
| |
|
| |
|