When we get a disconnect event that we wanted to ignore, set the
DisconnectRequest property instead so clients on dbus can act on it.
Also upgrade the logs from dbg to msg (info) as there would be otherwise
no message indicating the disconnect request if it is not acted on.
This was checked with dbus-monitor:
```
$ dbus-monitor --system "type='signal',sender='org.freedesktop.ModemManager1'"
signal time=1747362238.227804 sender=:1.73798 -> destination=(null destination) serial=741 path=/org/freedesktop/ModemManager1/Bearer/0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.ModemManager1.Bearer"
array [
dict entry(
string "DisconnectRequest"
variant boolean true
)
]
array [
]
```
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
When bearer gets an event that should trigger a disconnection but we
cannot disconnect (for example because we're waiting for pppd to close),
we now trigger a new 'disconnect-request' event instead
This was tested with the following hook:
```
$ cat /etc/ModemManager/connection.d/handle-disconnect-request.sh
#!/bin/sh
if [ "$4" != disconnect-request ]; then
exit 0
fi
iface=$(mmcli -b "$2" -K | awk '/bearer.status.interface/ { print $3 }')
if pkill -f "pppd\>.*\<$iface\>"; then
logger -t mm-disconnect-request "Killed $iface pppd"
else
logger -t mm-disconnect-request "No pppd found for $iface"
fi
```
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
The next commit will introduce a new dispatcher event.
This commit should not change anything user-facing
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Continues removing usage of MMBaseModem in a bunch of files
by splitting out bits of its usage to separate interfaces.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Rather than make all of them rely on MMBaseModem for it. This
lets us disentangle dependencies for easier unit testing.
For interfaces, rather than casting directly to MMBaseModem
use intermediate interfaces (MMIfaceAuth and MMIfaceOpLock)
that tests can fake out.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
We want to ensure that all errors reported via DBus operations are
normalized to MM-specific errors.
We don't want to return QMI or MBIM specific errors, as those are
protocol specific and we don't want DBus clients to need to rely on
knowing which is the protocol in use by the device.
The connection error exposed in the DBus interface should be an error
defined in the ModemManager API, and therefore it should be normalized
before being exposed.
This was already being done by limiting the exposure to MM specific
errors, but now we also try to normalize QMI or MBIM errors into MM
specific ones.
We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
The modem may report the 'apn-type' field is the one to be used as
index; if that's the case, allow setting and deleting profiles based
on the given 'apn-type' field.
This change also makes the internal profile management operations use
one index field or another, based on what the protocol implements.
By the time we report the bearer as 'Connected', the DBus client
should also be able to know right away the value of
'ReloadStatsSupported', instead of needing to wait for it to be
updated asynchronously.
This logic adds one additional step in the generic connection
sequence for this purpose, which is run after the modem is connected
but before we report the state change via DBus.
This property means that the current bearer can reload stats and read TX
and RX bytes transmitted.
The property is initiliazed as soon as the bearer is connected.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
We let protocol implementations provide the uplink and downlink speeds
agreed with the network as part of the connect result, and we then move
them to the bearer stats in DBus.
It stores the epoch timestamp of the current bearer session start.
If there is no connected bearer, it is set to 0 and not displayed
in mmcli output.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Includes updates by Aleksander Morgado to fix coding style issues.
Just triggering a connection status reload won't change the actual
bearer object state.
We change the signature of the reload_connection_status_finish()
method so that it returns the actual reloaded bearer connection
status, and so both the load_ and reload_ methods can be implemented
with exactly the same method, something that was not possible before.
Once we get the new connection status reloaded, we apply it in the
bearer object only if it's DISCONNECTED (and it wasn't DISCONNECTED
before). This should cover the true real case we're interested in, and
nothing else (i.e. we won't overcomplicate the logic attempting to
handle disconnected->connected transitions detected in the sync()
operation).
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.
When a user-requested connection attempt fails, we not only return the
connection error to the user that requested it, we also publish the
specific connection error in DBus for others to check why the failure
happened.
Some of the operations performed by the profile management interface
will require checking whether the operation is attempted on a profile
for which there is a known connected bearer object.
We introduce a new method to lookup a bearer in the bearer list by its
connected profile id.
Implementations that support profile management will provide the
connected profile id value in the MMBearerConnectResult returned to
the base bearer object during the connection attempt.
There is no point in providing a configurable default IP family in the
bearer object, because we can always assume IPv4 as being the only
default expected.
Simplify the logic and also provide a new method to get the normalize
the IP family, using IPv4 as default always.
If using PPP, ModemManager is never in charge of deciding when the
connection is finished, because that would end up making ModemManager
try to use the TTY port while pppd is still using it.
When the modem goes unregistered for some time, we should not force
the disconnection of the bearer object, we still need to wait for pppd
to tell us the modem is disconnected.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/331
This property will be TRUE if the bearer has the data session
connected through a multiplexed interface.
If the bearer is disconnected, or connected without multiplexing, the
property will report FALSE.
When we're reusing over and over the same bearer object, we can
provide statistical information about the number of connection
attempts that have been done and how many of them failed.
We don't want the connection status checks to interfere with the
disconnection logic, e.g. if they're both using the same TTY for both
things.
E.g. the CGACT? from the conncheck gets in the way of the
disconnection logic:
<debug> [1576037519.710684] Flashing data port (ttyUSB1)...
<debug> [1576037519.710740] (ttyUSB1): port attributes not fully set
<debug> [1576037520.287636] (ttyUSB1) device open count is 3 (open)
<debug> [1576037520.287804] (ttyUSB1): --> 'AT+CGACT?<CR>'
<debug> [1576037520.711067] (ttyUSB1) device open count is 2 (close)
<debug> [1576037520.711127] (ttyUSB1): running init sequence...
<debug> [1576037520.711231] PDP disconnection already sent
<debug> [1576037520.711263] Disconnected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Instead, fully skip all conncheck and stat updates as long as the
modem is not connected. The actual conncheck and stat update timeouts
will be removed once completely disconnected, as it was before.
There are modems out there (e.g. SIM7600E) where we connect a given
CID >1 but once connected, only CID=1 is reported as connected, and
not the one we explicitly attempted to connect. In this situation the
modem is connected successfully, and we're properly ignoring the
disconnection report detected from CGACT? responses, but we're
probably better logging this situation only in debug level, not as
info, because this check is done periodically every 5s...
<debug> [1568649020.333263] (ttyUSB5): --> 'AT+CGDCONT=7,"IP","inet.es"<CR>'
<debug> [1568649020.383517] (ttyUSB5): <-- '<CR><LF>OK<CR><LF>'
<debug> [1568649020.383617] (ttyUSB5) device open count is 3 (open)
<debug> [1568649020.383655] Connection through a plain serial AT port (ttyUSB5)
<debug> [1568649020.383683] (ttyUSB5) device open count is 4 (open)
<debug> [1568649020.383802] (ttyUSB5) device open count is 3 (close)
<debug> [1568649020.383873] (ttyUSB5): --> 'ATD*99***7#<CR>'
<debug> [1568649020.405767] (ttyUSB5): <-- '<CR><LF>CONNECT 115200<CR><LF>'
<debug> [1568649020.405853] [ttyUSB5] Setting flow control: rts-cts
<debug> [1568649020.405878] (ttyUSB5): enabling RTS/CTS flow control
<debug> [1568649020.405897] (ttyUSB5): port attributes not fully set
<debug> [1568649020.405910] (ttyUSB5): flow control settings updated to rts-cts
<debug> [1568649020.405940] (ttyUSB5): port now connected
<debug> [1568649020.405983] Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
<debug> [1568649020.406081] PPP is required for connection, will ignore disconnection reports
<info> [1568649020.406155] Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
<info> [1568649020.406361] Simple connect state (8/8): All done
<debug> [1568649020.406461] (ttyUSB5) device open count is 2 (close)
<debug> [1568649020.448483] (net/ppp0): adding device at sysfs path: /sys/devices/virtual/net/ppp0
<debug> [1568649020.448738] (net/ppp0) could not get vendor/product id
<debug> [1568649020.448776] [filter] (net/ppp0) port filtered: virtual device
<debug> [1568649050.395662] (ttyUSB6) device open count is 2 (open)
<debug> [1568649050.395871] (ttyUSB6): --> 'AT+CGACT?<CR>'
<debug> [1568649050.408638] (ttyUSB6): <-- '<CR><LF>+CGACT: 1,1<CR><LF>+CGACT: 2,0<CR><LF>+CGACT: 3,0<CR><LF>+CGACT: 4,0<CR><LF>+CGACT: 5,0<CR><LF>+CGACT: 6,0<CR><LF>+CGACT: 7,0<CR><LF><CR><LF>OK<CR><LF>'
<debug> [1568649050.408803] connection status loaded: disconnected
---> <info> [1568649050.408825] ignoring disconnection report for bearer '/org/freedesktop/ModemManager1/Bearer/0'
<debug> [1568649050.408848] (ttyUSB6) device open count is 1 (close)
<debug> [1568649055.398994] (ttyUSB6) device open count is 2 (open)
<debug> [1568649055.399084] (ttyUSB6): --> 'AT+CGACT?<CR>'
<debug> [1568649055.411489] (ttyUSB6): <-- '<CR><LF>+CGACT: 1,1<CR><LF>+CGACT: 2,0<CR><LF>+CGACT: 3,0<CR><LF>+CGACT: 4,0<CR><LF>+CGACT: 5,0<CR><LF>+CGACT: 6,0<CR><LF>+CGACT: 7,0<CR><LF><CR><LF>OK<CR><LF>'
<debug> [1568649055.411652] connection status loaded: disconnected
---> <info> [1568649055.411674] ignoring disconnection report for bearer '/org/freedesktop/ModemManager1/Bearer/0'
Never automatically flag the bearer as disconnected if it's using PPP,
because we could end up using the TTY at the same time as pppd, with
the wrong CLOCAL settings.
So, whenever we detect that the bearer requires PPP, we will ignore
all disconnection reports generated by ModemManager itself.
Dominique Martinet
Dan Williams
Guido Günther
Aleksander Morgado
Aleksander Morgado
Rukun Mao
Frederic Martinsons
Dylan Van Assche