Re: ModemManager and muxed network interfaces

Hey Thomas,

I'm working on setting up muxed network interfaces with ModemManager
so that e.g. you can connect to multiple APNs at the same time, each
with its own subnet on a different virtual network interface link
created from the "master" wwan modem interface. These links can be
done either with mbim (using VLANs) or qmi (using the built-in muxing
capabilities of qmi_wwan or with rmnet).

Now, in order to integrate this with NetworkManager, the main
difference that NM will see upon connecting a modem through MM will
be that the data port reported in the Bearer info that
Simple.Connect() returns is no longer the master wwan interface, but
a new "qmimux0" interface (name varies depending on the kernel backed

I already have this logic setup in a custom branch, but I'm lacking 2
things right now:
  * When setting up the muxing support, we need to configure the MTU
of the master wwan interface to a specific value that the modem tells
us to use (the maximum data aggregation size).
  * And also, before NetworkManager can bring up the "qmimux0" link
interface, the "master" wwan modem interface needs to be already up
or the link ifup will fail.

I can definitely add those two things to the ModemManager connection
logic, but wanted to ask, is there any way NetworkManager could setup
both the master network interface AND then the muxed qmimux0
interface? E.g. if MM exposed all those things in DBus, could NM
setup both those interfaces? Or is that too much change in the NM
logic because it truly expects to setup one interface at a time?

I think the way to go is to add it in MM, so that theoretically NM
does not need to do absolutely anything, but wanted to ask first
Any comments or suggestions?

Hi Aleksander,

NetworkManager's primary means of configuring something is by having a
connection profile to begin with.

If the master network interface requires non-trivial configuration,
then it probably would also require a profile in NetworkManager, and
the "port" interface would refer to that controller interface.

On the other hand, for vlan interfaces/profiles you don't necessarily
need a profile for the parent device. Specifying the parent (interface
name) is enough.

Also, that one connection profile in NetworkManager can control
multiple "devices", is not new. That also happens when you activate a
modem connection. There is the control port (a NMDevice) but there is
also the actual interface with the IP configuration. I think that is
currently not solved well and is in dire need of improvement, but in
general, that there are multiple "devices" that are configured by one
profile is also viable.

On the other hand, if MM can abstract all of this nicely, then indeed
it seems good if MM does it. That would also (theoretically) simplify
it for users who don't wnat to use NM but MM.

I went ahead and added all the necessary logic in MM, because the
master/parent interface setup is not trivial; e.g. there is a case
where the master MTU needs to be set before the interface is switched
to raw-ip in the kernel, and also links pre-created before the master
link is brought up, and several other magical things to do here and
there. As you said, MM can abstract all of this nicely.

In the NM side, the only thing that you would need to know is whether
you want multiplexing support or not. As of now, I'm preparing a new
"multiplex" setting in the MM connection settings that accepts 3
values: "none" (multiplex must not be used), "requested" (multiplex
should be used if available) and "required" (multiplex must be used or
otherwise fail). Right now the absence of the setting means "none", so
for now NM won't request multiplexing. In this next MM 1.18 dev cycle,
and if the multiplexing support is stable enough, we may change that
absence to mean "requested", or otherwise maybe suggest one additional
explicit NM setting to let users to configure it, or something like
that. The target is to allow the connection manager (NM or some
others) to bring up multiple connection settings over a single modem
object, as that is what this multiplexing feature provides (e.g. one
APN for Internet, one APN for a private corporate network, one APN for


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]