qmi_wwan add_mux/del_mux

Aleksander Morgado aleksander at aleksander.es
Fri Jan 22 11:52:46 UTC 2021


Hey Daniele,

> > Say I create a new muxed interface for mux id 5:
> >   echo 5 > /sys/class/net/wwan0/qmi/add_mux
> > A new qmimux0 interface is created.
> >
> > Is there any way to know which mux id was used to create the qmimux0
> > looking just at sysfs or some other way? In other words, how would I
> > know what the mux id is for a given qmimuxN interface that may not
> > have been created by me?
> >
> > Also, say that I have 2 different programs creating this kind of
> > interfaces, and both use the qmi/add_mux attribute. If they both run
> > at the same time (asking for different mux ids), and two interfaces
> > qmimux0 and qmimux1 are created, how can each program know which was
> > the interface corresponding to the mux id they requested?
> >
> > Not sure I'm missing something, but I didn't find a way to do this
> > kind of matchings. If the virtual qmimux interface exposed a sysfs
> > attribute specifying which is the mux id they correspond to, the
> > matching would be much easier. Would that be possible?
> >
>
> Yes, all your questions make sense to me and, to my understanding,
> currently there's no solution at the driver level.
>
> As you sugget, the easiest change would probably be a sysfs file in
> the qmimux network interface: I quickly wrote the attached patch,
> without claiming to be correct, just to give the idea (applies to
> current net-next).
>
> So it works something like:
>
> root at LABNL-ITC-SW01:~# ip link show
> 7: wwp0s20u2i2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> mode DEFAULT group default qlen 1000
>     link/ether 5e:1a:7e:1c:86:d4 brd ff:ff:ff:ff:ff:ff
> root at LABNL-ITC-SW01:~# echo 5 >
> /sys/bus/usb/devices/3-2:1.2/net/wwp0s20u2i2/qmi/add_mux
> root at LABNL-ITC-SW01:~# echo 9 >
> /sys/bus/usb/devices/3-2:1.2/net/wwp0s20u2i2/qmi/add_mux
> root at LABNL-ITC-SW01:~# ip link show
> 7: wwp0s20u2i2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> mode DEFAULT group default qlen 1000
>     link/ether 5e:1a:7e:1c:86:d4 brd ff:ff:ff:ff:ff:ff
> 8: qmimux0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state
> DOWN mode DEFAULT group default qlen 1000
>     link/none
> 9: qmimux1: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state
> DOWN mode DEFAULT group default qlen 1000
>     link/none
> root at LABNL-ITC-SW01:~# cat
> /sys/bus/usb/devices/3-2:1.2/net/wwp0s20u2i2/upper_qmimux0/qmap/mux_id
> 0x05
> root at LABNL-ITC-SW01:~# cat
> /sys/bus/usb/devices/3-2:1.2/net/wwp0s20u2i2/upper_qmimux1/qmap/mux_id
> 0x09
>
> However, I'm not sure this is the best solution and would be accepted,
> since there's reluctance to add new sysfs files.
>

As I understand it, the add_mux/del_mux API won't go away even if we
integrate the rmnet support, so I think it would be a good idea to
have the new "mux_id" sysfs attribute for the muxed interface, so that
there's a clear way on how to map those interfaces by userspace.
Otherwise, the integration using add_mux/del_mux would need to heavily
rely on having "just one" application doing that management, which is
a bit limited.

-- 
Aleksander
https://aleksander.es


More information about the libqmi-devel mailing list