WDS Bind Mux Port?

Daniele Palmas dnlplm at gmail.com
Wed Jan 11 14:34:38 UTC 2017


2017-01-11 12:05 GMT+01:00 Bjørn Mork <bjorn at mork.no>:
> 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.

Add me to the list of users ;-) And by the way, I know of some Telit
customers using that feature, so maybe we are not alone.

>
> 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 would prefer to extend the sysfs interface, just my two cents.

>   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.
>

My understanding is that multiplexing should be explicitly enabled,
but I'm wondering if having two different netdev behavior between mbim
and qmi can confuse the user, even though this is not probably a
feature for the common user.

Daniele

>
> 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


More information about the libqmi-devel mailing list