Instead of deciding in advance which data port to use, we let the dialling
operation gather it. For the generic dialling logic, ATD-based, always an
'AT' port will be used as data port, even if we grabbed a 'net' port. Those
plugins that can work with 'net' ports will grab the specific 'net' port
themselves.
If the primary port is gone (e.g. when going to sleep) and we are just in the
middle of a connection attempt, we won't be able to receive any unsolicited
message regarding the status of the attempt. So, if we detect that the port is
forced to get closed, we'll just treat it as a connection failure.
http://code.google.com/p/chromium-os/issues/detail?id=35391
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
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).
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
This reverts commit e2f3034f6e.
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.
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
Some Icera-based modems (e.g. Samsung/Icera Y3300/Y3400) may take a loong time
to run the power down command (see commit 5f1a1cf8). So, for these modems we
will fully skip the power down command run during initialization.
Some of the IP address items will be 0.0.0.0 depending on what the
other items are, like when the duplicate gateway is set on newer
devices, the first gateway address may be 0.0.0.0. Since that's
not a valid IP address, just don't set that member of the config.
Second, the intent with the duplicate gateway is only to use that
when the first gateway was not given (ie, was 0.0.0.0) so fix the
check for that.
This is the port to git master of the following commit:
commit c8153b1ecdec1995258b114c90b575af1e721d3d
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Aug 28 12:16:26 2012 -0500
icera: handle additional IPv4 configuration options
Newer devices like the ZTE/Vodafone K3805-z have an enhanced
%IPDPADDR command that includes a netmask and gateway, and
these are necessary to configure the device since it uses /24
instead of a /32. Since the device is nice enough to tell
us that, we should probably use that information.
Unfortunately the MM API doens't expose the netmask and gateway
yet, so we'll have to add a GetIP4ConfigEx() method or something
like that, but this commit sets us up to do that.
This is the port to git master of the following commit:
commit fb3187847b9c62d5205962c3c707ac1f44eaddcc
Author: Eric Shienbrood <ers@chromium.org>
Date: Thu Aug 11 16:58:34 2011 -0400
icera: retry configuring PDP context if it fails.
If a connect operation is attempted immediately after a disconnect,
it sometimes fails with CME error 583 - "a profile (CID) is currently
active". Apparently, even though the preceding operation (%IPDPACT)
to deactivate the PDP context returned an OK response, the context
is not really completely available until a fraction of a second
later. This causes the %IPDPCFG operation that is part of the
subsequent connect attempt to fail with error 583. This change
retries the %IPDPCFG after a one second delay.
BUG=chrome-os-partner:4936
TEST=This can be tested from the UI, but I found it easier to produce
the timing needed to trigger the bug by running mm-disconnect and
mm-connect from a shell.
Start out with the modem in the connected state. In the shell, run
sudo /usr/local/lib/flimflam/test/mm-disconnect; sudo /usr/local/lib/flimflam/test/mm-connect --number='*99#' --apn=wap.cingular
modem-manager should emit the log line "Invalid error code: 583".
Prior to this change, the connect operation would fail. Now it should
succeed.
Change-Id: I6ae0e6a9f5405b54b0b465fe91d9542529f365c2
Reviewed-on: http://gerrit.chromium.org/gerrit/5781
Tested-by: Eric Shienbrood <ers@chromium.org>
Reviewed-by: Nathan J. Williams <njw@chromium.org>
Different ports of the same modem may get handled by different drivers. We
therefore need to provide a list of drivers (new `Modem.Drivers' property with
signature 'as') instead of just one (removed `Modem.Driver' property with
signature 's').
$ sudo mmcli -m 0 | grep drivers
| drivers: 'qcserial, qmi_wwan'
This patch modifies MMBroadbandModemIcera as follows:
- Change modem_load_current_bands to report only bands that are
currently enabled
- Change modem_set_bands to handle setting ANY band in a way that no
forbidden bands are activated.
Turns out we can check supported bands by asking the modem what
the enabled state is for the bands it says it supports, and then
setting the enabled state to what it currently is. For bands the
modem actually doesn't support, it'll return an error. Use that
to build up the modem's actual supported band list.
In the connection and disconnection sequences, we make sure that the Bearer
object is valid by keeping a reference in the Dial3gppContext and
Disconnect3gppContext (actually, another one kept by the GSimpleAsyncResult as
well). But we are considering here the case where the context is completed and
freed by an unsolicited message handler before we get the reply to the AT
command, so to properly ensure that the bearer object is still valid when we try
to check if the context is in the priv struct, we need to keep an extra ref
around.
In both the connection and disconnection sequences, we keep the context in the
private info of the Bearer object, so that we can complete and free it when we
receive %IPDPACT unsolicited messages. Now, the reply of the %IPDPACT itself may
get processed as an unsolicited message, so effectively we're processing and
finishing the connection/disconnection context *before* we process the reply of
the AT command.
This patch ensures that we do not try to re-use the connection/disconnection
context after it has been processed by the unsolicited messages handler.
