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
