WDS Bind Mux Port?

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:
> On Wed, Jan 11, 2017 at 11:03 AM, Daniele Palmas <dnlplm at gmail.com> wrote:
>>>> >> > From a quick check with a Huawei ME909u (MDM9215) running in QMI mode
>>>> >>
>>>> >> we are using a modified version of that driver with Telit LE922A6 to
>>>> >> support multiple data sessions that, for my understanding, are lacking
>>>> >> in qmi_wwan.
>>>> >>
>>>> >
>>>> > I am using Sierra MC7455, which have both /dev/cdc-wdm0 and
>>>> > /dev/cdc-wdm1,
>>>> > this allow me to have to have two simultaneous data connections with
>>>> > qmi_wwan (also MC7304 support this).
>>>> >
>>>>
>>>> But do those USB compositions have more than one rmnet device? In
>>>> LE922A6 we have only one device at the usb level.
>>>>
>>>> Daniele
>>>>
>>>
>>> You are correct.
>>>
>>> But aren't we able to have several data connections on same device with
>>> MBIM, I would remember that Björn did have some example of that, or is
>>> memory failing me? (of course this would be outside the QMI scope).
>>
>> Yes, exactly, MBIM is working fine in that way.

Except that there hasn't really been any demand, so I think I'm the only
one ever having used it.  And even I don't bother anymore, since it
requires so many manual steps.

Yes, I know I almost promised to look at automating the link/bearer
configuration for libmbim/ModemManager a loooong time ago. You just have
to realize that I don't always get around to actually implemeting
everything I promise :)

>> But there are people that need the modem to be controlled through QMI
>> and have the requirement to setup multiple concurrent data session,
>> making this a showstopper for qmi_wwan.
>
> If this is indeed something to support, why don't we set it up as well
> with qmi_wwan/libqmi?

My thought as well. Adding multiplexing support to the qmi_wwan data
plane does not seem very difficult. Codewise. The main issues are the
usual policy questions:

1) We can only add the necessary knobs to adjust the data plane

  We cannot automatically turn then beased on control plane messages,
  since the qmi_wwan driver is completely control protocol agnotistic.
  Some userspace tool (i.e libqmi) will have to coordinate the control
  and data plane, similar to how we do it for raw IP for example: You
  need both a WDA Set Data Format message and writing to the sysfs file.


2) We need to figure out a sane user interface

  I haven't exactly received much applause for the creative use of VLAN
  tagging in cdc_mbim ;)  So I'm not sure that is worth copying.  The
  only reason would be to keep the UI of two multiplexing drivers
  similar.  But IIUC, QMI multiplexing is tied to raw-ip.  Which with
  our current implementation excludes VLAN tags as an option.

  So the table is open:  How do you want additional multiplexed qmi_wwan
  data interfaces implemented? Driver specific netlink messages to add
  and remove links?  Or extending the raw-ip sysfs interface (dunno if I
  can sell that in)?

  I assume that we want to keep a single /dev/cdc-wdmX and have proper
  slave netdevs for every multiplexed channel, in any case.  But what do
  we do about the original netdev?  Keep it as master only, or should we
  accept traffic for some default multiplex channel on it?  The cdc_mbim
  driver is an example I would want to avoid here...  But that's
  basically because MBIM has multiplexing by default, and most (all)
  users ignore it.  As long as QMI multiplexing is something that needs
  to be explicitly enabled, I think we can safely force the users to
  create a new link even for the first channel.


Don't know how much time I will have for this, but I must admit that I
am curious about this feature.  So I might spend time I don't have :)



Bjørn