When the ModemManager daemon is started by the init script, we're
explicitly calling mm_report_events_from_cache() so that all the
hotplug events that happened before that moment are properly notified
to the newly launched daemon.
This initial reporting of events does a wait for the ModemManager
process to be available in DBus, and if the daemon isn't registered in
the bus in a given time, the process is considered failed:
Sun Sep 6 16:20:02 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:02 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:03 2020 [2180]: <info> ModemManager (version 1.14.6) starting in system bus...
Sun Sep 6 16:20:03 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:04 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:05 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:05 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:06 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:06 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:07 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:07 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:08 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:08 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:09 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:09 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:10 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:10 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:11 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:11 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:12 2020 ModemManager: hotplug: checking if ModemManager is available...
Sun Sep 6 16:20:12 2020 ModemManager: hotplug: ModemManager not yet available
Sun Sep 6 16:20:12 2020 ModemManager: hotplug: error: couldn't report initial kernel events: ModemManager not running
Update the default wait time for this initial event notification from
10s to 60s, because there are cases where the daemon is slower to
boot, e.g. during the first boot after a sysupgrade.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
ModemManager allows specifying which are the authentication protocols
to be used during the user/password context authentication with the
peer.
This protocol update allows users to provide a new 'allowedauth'
option in the interface configuration, which is then used in two
different places:
* It is sent to ModemManager in the --simple-connect call so that
modems with a network interface can perform the authentication
using their own vendor-specific protocol.
* If the connection is done using PPP, this list of protocols is used
to configure the pppd call.
If the new 'allowedauth' option is not given, all auth protocols are
implicitly allowed.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
The modemmanager.common file includes several utility functions that
are used in several places like the protocol handler and in hotplug
scripts. These utilities should not be installed in /etc as they're
not configuration.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Unlike other modem protocol handlers like the ones implemented by uqmi
or umbim, in the modemmanager protocol handler the 'device' option
does not specify a device node in /dev. Therefore, we shouldn't flag
the option as 'device' type (dt_type_device).
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
When a USB modem device is unplugged, we had to do two different
things: first, cleanup the sysfs cache; and second, set interface as
unavailable.
Those two things were never being done properly due to several
different issues:
* The parent sysfs path retrieval logic relies on checking for which
sysfs path has the vid/pid files. This logic obviously only works
when the device is available, and cannot be used on e.g. removal
events.
* The command to cleanup the modem wait status from the sysfs cache
was not removing the previous state properly, because the sysfs path
variable wasn't escaped properly for the sed command.
This patch handles those issues in order to have a proper device
removal handling, by making sure the sysfs path is properly escaped in
the sed command, and by introducing a new hotplug script that runs
when the full USB device is removed.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
When the user requests 'any' as 'iptype', we may get either IPv4 or
IPv6 settings.
Simplify the logic by not requiring any explicit iptype before loading
the method reported by the bearer object for IPv4 and IPv6; just load
the methods right away and setup settings based on those.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
The procd based init setup uses a custom `pidfile` parameter, but the
used MODEMMANAGER_PID_FILE was not being defined anywhere.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
The bearer status wasn't being loaded in key/value mode, and therefore
would always fail to load the IPv4 config method.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Aleksander Morgado
Nicholas Smith