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).
After repeated stress tests on a few Novatel E362 modems and SIM cards,
it is revealed that a 3-second wait after SIM unlock is necessary for
reliably reading ICCID and IMSI through the SIM interface.
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".
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.
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)
