qmi_wwan add_mux/del_mux

[Andre Valentin]

Hi !

Am 30.01.21 um 14:15 schrieb Aleksander Morgado:
> Hey all,
> 
>>>>>>> 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?
>>>>>>>
>>>>>>> For context, I'm trying to work on adding support for this interface
>>>>>>> in libqmi, with the new qmi_device_add_link() interface that is right
>>>>>>> now only available when using rmnet with netlink.
>>>>>>>
>>>>>>
>>>>>> In the context of multiplexing QMUX data sessions, Stephan also
>>>>>> suggested we revive this old patch that never got a v2 in the LKML:
>>>>>> https://lore.kernel.org/netdev/1530066614-24995-1-git-send-email-subashab@codeaurora.org/
>>>>>>
>>>>>> Adding support to use rmnet on top of qmi_wwan seems like a good idea,
>>>>>> and we would be able to use the implementation we already have for
>>>>>> e.g. IPA, e.g.:
>>>>>> https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/184#note_715900
>>>>>>
>>>>>> What do you all think?
>>>>>
>>>>> I think that would be the best solution, since it also allows
>>>>> homogeneity with PCIe MHI.
>>>>>
>>>>> Reading again the comments, it seems to me that the patch was not too
>>>>> far to be acceptable, so maybe it would be worth looking at it again.
>>>>>
>>>>
>>>> Subash, any reason why the patch was forgotten and no v2 proposed? Is
>>>> there something we can do to push it forward?
>>>
>>> Hi
>>>
>>> That was my bad. I will send an updated patch with the changes mentioned
>>> by Bjørn.
>>
>> Great! Thanks for doing that :)
>>
> 
> The patch is already in net-next, yey!
> 
> Regarding libqmi-glib, I thought of adding new APIs in the QmiDevice
> to allow setting/getting the pass through value, but given that this
> setting *requires* first enabling raw-ip, I have instead updated the
> QmiDeviceExpectedDataFormat enum with a new "QMAP_PASS_THROUGH" value,
> in addition to "802_3" and "RAW_IP". The
> qmi_device_set_expected_data_format() will update the "raw_ip" and
> "pass_through" settings to the required values for each
> QmiDeviceExpectedDataFormat (considering also that in older kernels
> these may not exist)
> 
> See https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/205
> 
> Comments welcome!
> 

This all looks very interesting. Can't wait to get it in OpenWRT :-)

Did I understand you correctly that this call wouldn't be needed anymore:
qmicli ... --wds-bind-mux-data-port=mux-id=${mux_id},ep-iface-number=${ep_id}

Kind regards,

André


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4052 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20210130/7fabf5df/attachment.bin>