Automatically connect plugged in modems

[Aleksander Morgado]

Hey!

> >> After having set up modemmanager properly, I still need to run `mmcli simple-connect...` each time I plug in the modem. Plus, the ID sometimes changes when re-plugging it, so I have to query the ID (sometimes the modem takes a while to show up too), and THEN manually connect it.
> >>
> >> Not a huge deal TBH, but still low-key annoying; it gets repetitive rather quickly.
> >>
> >
> > Yes, that is all expected. If you want an "automated" connection
> > management, you need something on top of MM to do it. MM just provides
> > APIs to control the modem, it doesn't do any logic by itself. No one
> > is expected to run --simple-connect every time to connect a modem,
> > there should be some other process in charge of doing that for you.
> >
>
> That makes sense: do one thing and to it well :)
>

That's the idea!

> >> So I wrote a very little helper that listens on the D-Bus interface for new modems, and automatically connects them to the network (sim-pin and profile-id are read from a config file). Maybe this can be of use to others?:
> >>
> >> https://git.sr.ht/~whynothugo/mmctl
> >>
> >> Configuration of the network itself (e.g.: DHCP) is handled by the network manager service (systemd-networkd in my case) once wlan0 is up.
> >>
> >
> > Thanks for sharing! I'm sure this could be helpful to others.
> >
> > One thing I quickly spotted is that you're assuming DHCP can be run in
> > the modem, and this is not always the case. Instead, you should look
> > at the generated connected bearer object and see what are the
> > Ip4Config and Ip6Config property values. The bearer may report
> > "static" if the user should configure the IP settings provided by the
> > modem in the bearer object, or "dhcp" if the user should run DHCP (or
> > SLAAC for IPv6), or "ppp" if the user should run pppd over a specific
> > TTY port.
> >
>
> I don't exactly assume DHCP; the helper limits itself to connecting the modem
> to the cellular network and doesn't handle the IP layer at all. Establishing
> the upper-layer network connection is not handled deliberately, since that's
> handled by the network management service itself (systemd-networkd in my case).
>
> Presently, I _do_ have wwan0 configured to use DHCP (since my ISP uses this).
> However, systemd-networkd is adding native support for grabbing the details
> from ModemManager[1], so I'll just rely on that in future.
>
> [1]: https://github.com/systemd/systemd/pull/22315
>

Oh, I missed this! I've added some comments there.

> >> Aside from sharing this very tiny tool, I wanted to also kind of suggest incorporating this functionality into modem-manager itself; adding support for configuration files where one can define sim-pin, profile-id, etc, and have modem-manager automatically connect when it's detected.
> >>
> >
> > This is not a task of ModemManager really. MM just provides a mean to
> > configure the modem, it is not in charge of the actual logic to
> > perform the connection, or what to do with the connection. Upper
> > layers like NetworkManager (in most distros), netifd (in openwrt) or
> > Shill (in ChromeOS) are the ones in charge of triggering the
> > connection setup and then configuring the net interface as requested.
> > All those upper layers already have ways to store connection settings
> > like APN, PIN, user/pass... Adding the complexity of managing all that
> > by MM automatically is not something I'd personally like to do.
> > Setting up a connection, along with default routes and every other
> > detail should be done by the network management logic in the system,
> > be it a ethernet, a wireless or a modem device.
> >
>
> Right!
>
> I currently use `iwd` to tell the wifi adapter "please connect to this AP".
> systemd-networkd then handles the IP configuration.
>
> My goal with mmctl is to have an analogous for modems; something that ONLY
> connects the modems, but leaves the IP configuration to the network management
> service.
>

If using that systemd networkd branch, you then just need a way to run
Simple.Connect() any time the modem is reported as disconnected, and
networkd would take care of the IP setup.

> > That said, we could have a simple program like yours as an example in
> > the ModemManager sources, or even something that could be used in
> > setups where no other upper layer is available (e.g. assuming there
> > will be one single default route via the modem and such). I have
> > several examples like those that I could adapt, and ideally they would
> > be using libmm-glib (e.g. in python via GObject Introspection). I have
> > absolutely no idea if you can have automatic bindings like the ones we
> > have in python or javascript via GIR when using rust, is that a thing?
> >
>
> I'm currently using the D-Bus API directly (using zbus, a Rust library for
> connecting to D-Bus).

Yeah, zeenix' latest and greatest :)

> Is is possible to generate bindings via GIR, but I'm not
> sure if there's any benefit so as to justify the added complexity.
>

Ok.

> Maybe just adding a link to it in examples is enough. It might be enough for
> someone, or at least a sufficient reference.

If you prepare your tool as a clean example of how to interact with MM
with the zbus library in rust, then we can definitely add it to the
examples directory. A comment to the networkd integration in the tool
may also help users wanting to use that.

--
Aleksander
https://aleksander.es