==252789== Process terminating with default action of signal 11 (SIGSEGV): dumping core
    ==252789==  Access not within mapped region at address 0x28
    ==252789==    at 0x7D17D22: connect_reset_ready (mm-broadband-bearer-icera.c:419)
    ==252789==    by 0x4EEC242: g_simple_async_result_complete (gsimpleasyncresult.c:802)
    ==252789==    by 0x17EFC6: at_command_ready (mm-base-modem-at.c:538)
    ==252789==    by 0x4EEC242: g_simple_async_result_complete (gsimpleasyncresult.c:802)
    ==252789==    by 0x259423: serial_command_ready (mm-port-serial-at.c:393)
    ==252789==    by 0x4EEC242: g_simple_async_result_complete (gsimpleasyncresult.c:802)
    ==252789==    by 0x252B9B: command_context_complete_and_free (mm-port-serial.c:141)
    ==252789==    by 0x254542: port_serial_got_response (mm-port-serial.c:755)
    ==252789==    by 0x254A78: parse_response_buffer (mm-port-serial.c:926)
    ==252789==    by 0x254FFE: common_input_available (mm-port-serial.c:1035)
    ==252789==    by 0x2550DE: iochannel_input_available (mm-port-serial.c:1058)
    ==252789==    by 0x50D3F84: UnknownInlinedFun (gmain.c:3344)
    ==252789==    by 0x50D3F84: g_main_context_dispatch (gmain.c:4062)

As the profile id is not really set in the base bearer object until
after connected.

Some of the AT-based connection methods don't have any way to query
connection status, or we don't have a proper implementation for those
yet. Ignore the reload operation in all those.

By default, fallback to "unknown" mobile equipment error when the
modem gets disconnected by the network and we don't have any way to
know a more detailed reason.

Update the list of mobile equipment error codes according to v17.1.0
of 3GPP TS 27.007 (March 2021).

A lot of the enum values that were prefixed with the 'GPRS_' keyword
have now been flagged as deprecated, and a new enum name given to the
corresponding value.

The deprecated symbol names are kept in the compat support to avoid
breaking API/ABI.

Using AT%IPDPCFG for authentication related profile settings
management (querying, updating), and relying on the parent
implementation for the remaining ones.

And using AT%IPDPACT for activation status management (deactivate),
while relying on the parent implementation for the activated check.

Each different plugin or protocol had a different connection attempt
value. E.g. QMI and MBIM both used 60s max for the connection attempt,
while the u-blox plugin had up to 180s for ECM based connection
setups.

This commit consolidates all plugins and protocols to use the same
timeout values for commands that may take long to respond, e.g. a
connection atempt under low signal quality conditions.

A value of 180s for the connection attempt steps and 120s for a
disconnection attempt step is considered. Note, though, that in some
cases (like a IPv4v6 setup attempt using QMI) we may have more than
one such long step, so this doesn't mean that a connection attempt
will always take less than 180s.

Users of the connection/disconnection APIs should be able to handle
the case where the attempt times out in their side (e.g. with a lower
DBus request timeout), and which would not mean the actual request
they did really failed. E.g. a connection attempt with a DBus timeout
of 30s may fail in the user with a timeout error, but the attempt
would still go on for as much as the plugin/protocol needs.

Fixes #270

CHAP is almost universal nowadays, and so it is a better default
than PAP

Not changed for uBlox, that prefers an error if not specified,
and for Huawei, which uses NONE with user/pwd and has 2 CHAP choices

Ben Chan authored 7 years ago and Aleksander Morgado committed 7 years ago

g_free and g_object_unref are in form of  `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.

A default implementation to monitor the ongoing connection is provided in the
generic MMBroadbandModem, based on AT+CGACT? to check whether the PDP context
of the connection (identified by the cached cid) is active or not.

This commit also disables the connection monitoring logic in those plugins that
have custom connection methods.

If the modem thinks a PDP context is already active it'll return
583 errors from IPDPCFG and IPDPACT until the context is
deactivated.  Deactivation was previously done after authentication,
but needs to be done before any part of the connect process to
ensure the PDP context is inactive.

The previous approach worked only if the context was being
deactivated already (which can take a bit of time) because it would
be deactivated after a few seconds and the connect could continue.
This approach works for more cases (like a MM crash and restart
while the modem is connected).

Just so that we don't have same header names in src/ and /libmm-glib.

Split out the %IPDPADDR parsing into a helper and add testcases for it,
and add support for IPv6 handling.  If the returned IPv6 is link-local,
the address should be assigned to the interface and SLAAC performed to
retrieve the actual IPv6 prefix and RDNSS/DNSSD information.

Subclasses may need to know which IP families were used for the setup
so they can return the correct IP configuration.  We can't just use
the MMBearer default_ip_family becuase that isn't the family that
was actually used during the connection.

Originally developed by:
  Ben Chan <benchan@chromium.org>

This patch replaces mm_bearer_report_disconnection() with a more generic
mm_bearer_report_connection_status(), which allows reporting any
connection status of a bearer. This further allows getting rid of those
custom report_connection_status functions in plugic specific bearer
subclasses.

Note that while plugin-specific implementations can receive multiple
'MMBearerConnectionStatus' values, the generic implementation is only allowed
to receive DISCONNECTED. Plugins need to make sure that they process all the
other status values, and only report DISCONNECTED to the parent when required.

MBM:
  The MBM bearer implementation of report_connection_status() expects either
  CONNECTED or DISCONNECTED. If any of these is received and there is an ongoing
  connection attempt, the corresponding operation will be completed. If there is
  no connection attempt, we will just handle the DISCONNECTED state, calling the
  parent method to notify that the modem got network-disconnected.

Icera:
  The Icera bearer implementation of report_connection_status() expects either
  CONNECTED, CONNECT FAILED or DISCONNECTED. If any of these is received and
  there is an ongoing connection or disconnection attempt, the corresponding
  operation will be completed. If there is no connection or disconnection
  attempt, we will just handle the CONNECT FAILED and DISCONNECTED states,
  calling the parent method (always with DISCONNECTED) to notify that the modem
  got network-disconnected.

Option/HSO:
  The Option/HSO bearer implementation of report_connection_status() expects
  either CONNECTED, CONNECTION FAILED or DISCONNECTED. If any of these is
  received and there is an ongoing connection or disconnection attempt, the
  corresponding operation will be completed. If there is no connection or
  disconnection attempt, we will just handle the CONNECTION FAILED and
  DISCONNECTED states, calling the parent method (always with DISCONNECTED) to
  notify that the modem got network-disconnected.

Huawei:
  The Huawei bearer implementation of report_connection_status() expects either
  CONNECTED or DISCONNECTED. These messages are not used to process pending
  connection or disconnection attempts; so if they are received while one of
  these is on-going, it will just be ignored. CONNECTED reports are also
  ignored, so we will just handle the DISCONNECTED state, calling the parent
  method to notify that the modem got network-disconnected.

Altair-LTE:
  The Altair-LTE bearers will only report DISCONNECTED on network-disconnected
  cases. There is no custom report_connection_status().

Novatel-LTE:
  The Novatel-LTE bearers will only report DISCONNECTED on network-disconnected
  cases. There is no custom report_connection_status().

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

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

If none of the specified methods is supported, an error is returned.

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.

Moved the utils to play with binary to hex strings into libmm-common.

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 c8153b1e
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 fb318784
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>

Plugins may require specific dialling commands depending on the port type.