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.
(port of a similar patch for MM_06 by heiher <admin@heiher.info>)
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)
The 'hso' driver tags Icera-based modems' proprietary protocol port
as a DIAG port, but since they aren't Qualcomm-based, it's not
a DIAG port. Just turn off AT probing and let QCDM probing
fail the port instead of assuming it's a DIAG port.
If we read a response that indicates the port is definitely not an
AT capable port, stop AT probing. Certain ports that use proprietary
protocols or other non-AT protocols tend to spew data at us, so when
this happens we can cut probing short.
If a response processor closed the port, don't try to read any
more data from it. Move the priv->watch_id check to the
while condition so the loop terminates before calling
g_io_channel_read_chars() again, which caused a warning since
the underlying file descriptor was already closed.
Also, bytes_read will never be less than zero (it's unsigned),
so skip the bytes_read > 0 check and just assert that this
condition is true.
Sierra devices often have limited AT parsers on their APP ports
which reply with OK to any command they don't understand, and
thus we need to actually check for a valid IPSYS reply instead of
just checking whether the IPSYS request completed without error.
Previously MM would detect Icera capability on devices that
didn't actually have it.
We can skip additional UTF-8 validity check when parsing operator.
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.
Based on 219424a6e2d017491a05ecbed661bccde3f991ef (MM_06 branch)
The logic gets completely stuck when this happens:
Stack trace below:
#0 0x77661424 in __kernel_vsyscall ()
#1 0x77337c3c in pthread_cond_wait ()
#2 0x773cebaa in g_cond_wait () from /usr/lib/libglib-2.0.so.0
#3 0x774c03cc in g_cancellable_disconnect () from /usr/lib/libgio-2.0.so.0
#4 0x76955d36 in connect_cancelled_cb (cancellable=0x78e055a0, self=0x78e0b590)
#5 0x77460982 in g_cclosure_marshal_VOID__VOIDv () from /usr/lib/libgobject-2.0.so.0
#6 0x7745ed8a in ?? () from /usr/lib/libgobject-2.0.so.0
#7 0x77478435 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#8 0x77478eb3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#9 0x774c01eb in g_cancellable_cancel () from /usr/lib/libgio-2.0.so.0
#10 0x776a0eab in mm_bearer_disconnect (self=0x78e0b590, callback=0x776c5980 <disconnect_ready>,
#11 0x776c57de in disconnect_next_bearer (ctx=0x78e12870) at mm-iface-modem-simple.c:898
#12 0x776c58d2 in disconnect_auth_ready (self=0x78df3048, res=0x78e06210, ctx=0x78e12870)
#13 0x774fed25 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0
#14 0x776a8c4e in authorize_ready (authp=0x78db68d0, res=0x76801638, simple=0x78e06210)
#15 0x774fed25 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0
#16 0x774fee3e in ?? () from /usr/lib/libgio-2.0.so.0
#17 0x7738a7a2 in ?? () from /usr/lib/libglib-2.0.so.0
#18 0x7738ce83 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#19 0x7738d248 in ?? () from /usr/lib/libglib-2.0.so.0
#20 0x7738d6eb in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#21 0x77696a7d in main (argc=2, argv=0x7fbb1f04) at main.c:158
http://code.google.com/p/chromium-os/issues/detail?id=36448
In order to have a proper conversion between DBus error names and GErrors for
our known domains, the associations need to be registered before any DBus
call attempt.
Given that the high-level API of libmm-glib has its entry point always in the
MMManager, just register them as soon as the first such object is created.
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.
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
Instead of getting the port type hints while grabbing each probed port, we now
run a custom init operation in the probing which already gives us the port type,
and therefore allows us to completely skip port probings.
Also now added hints for 'Diag' (QCDM) ports and AT/'Modem' ports (I guess it's
the one for PPP if we don't have a net port, which is unlikely anyway in HSO).
This makes the probing of an Option/HSO modem almost instant.
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.
This is the port to git master of the following commit, for which we
don't need to do #2:
commit 814febe1fd9baacdb33c79f11c140187df36c4f1
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Oct 30 16:16:25 2012 -0500
sierra: fix CFUN power up delay handling
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.
+CNUM may return ERROR when the modem fails to read the own numbers from
the SIM card or when the SIM card hasn't been activated. Use $NWMDN to
read the MDN as a fallback, which distinguishes these two cases.
We will not report 'CS' as a supported mode every time '2G' is supported. This
actually was forcing all plugins to handle a 'CS' fallback when they didn't have
CS-specific mode setup. So, to simplify things, we will only report 'CS' as
supported for those plugins which actually allow to select 'CS' mode (e.g. the
'wavecom' plugin).
