If we cancel connect_cancellable, the connect task will return a
G_IO_ERROR_CANCELLED. We may need to do some cleanup (like, disconnect
if the connection went far enough to actually start the network
connection), thus it's important we check for cancellation correctly.
This property contains the DBus path of a Bearer object of type
MM_BEARER_TYPE_DEFAULT_ATTACH, which is automatically exposed by the
modem when registered in the LTE network.
Unlike standard bearer objects created by the user, this bearer won't
allow any connection/disconnection request, as its status is bound to
the LTE registration exclusively.
The bearer settings exposed by the object include the APN details that
have been used during the initial packet network attach, which may be
defined by modem settings (e.g. if previously configured in the
firmware which APN to use for the given SIM card operator) or by the
network itself (e.g. if none configured, or if a network override is
required as when roaming).
The bearer object will be created as soon as the LTE attach status
details are known, and only while the modem is enabled. The
implementation allows modems to update the LTE attach status details
during runtime, so the bearer object with the settings may be
recreated during runtime as well.
Until now we have only allowed to use and setup 'default bearers' (in
4G) or 'primary contexts' (in 2G/3G).
We can define a couple of additional bearer types, though:
* The 'dedicated bearers' (in 4G) or 'secondary contexts' (in 2G/3G),
which are associated to a specific default/primary one, but which
provide specific QoS settings configured via traffic flow templates.
* The 'initial default EPS bearer', which is a special case of default
bearer in LTE, which is automatically created and connected when the
modem is registered in the LTE network.
This commit introduces a new 'MMBearerType' enumeration that will be
associated to each bearer through a 'BearerType' property in the
org.freedesktop.ModemManager1.Bearer interface, showing what kind of
bearer/context this is.
By default, right now, all bearer objects created are 'default'
bearers.
If we ask too quick for the PDP context status after a successful
connection attempt reported by the modem, we may find it still flagged
as inactive if the modem is still busy setting up the PPP session.
Do an explicit longer initial timeout before we run the first check,
and after that one setup the additional checks at a higher rate.
Reported-by: Colin Helliwell <colin.helliwell@ln-systems.com>
On modems with a single TTY for both control and data, we cannot use
the TTY to load connection status once we're in connected mode:
Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#<CR>'
(ttyUSB2): <-- '<CR><LF>CONNECT 100000000<CR><LF>'
(ttyUSB2): port now connected
Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
Simple connect state (8/8): All done
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
checking if connected failed: Couldn't check current list of active PDP contexts: No AT port available to run command
...
So, disable connection monitoring right away if that situation is
detected:
Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#<CR>'
(ttyUSB2): <-- '<CR><LF>CONNECT 100000000<CR><LF>'
(ttyUSB2): port now connected
Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
Simple connect state (8/8): All done
Connection monitoring is unsupported by the device
...
https://bugs.freedesktop.org/show_bug.cgi?id=100376
Introduce "sms only" and "CSFB not preferred" home/roaming states to be reported
for the CS context, while already registered on LTE.
Based on 3GPP TS 27.007 v13.5.0.