<div dir="ltr"><div>Hi Aleksander,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno lun 2 ago 2021 alle ore 16:41 Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey all,<br>
<br>
I've been testing with all my modems for the next 1.18 release, and<br>
for the QMI and MBIM ones I've done tests with and without<br>
multiplexing support (i.e. connecting normally as we did until now,<br>
and also connecting with multiplexing enabled).<br>
<br>
All the QMI modems I have tested with have worked fine. If QMAP wasn't<br>
supported by the modem and we were requesting multiplexing, it would<br>
automatically just fallback to no multiplexing (802.3 or plain<br>
raw-ip), and that was it.<br>
<br>
Most of the MBIM modems I have tested with have worked fine as well,<br>
with the exception of the Netgear AC340U, which would reply with<br>
"InvalidParameters" if we were attempting to connect any session with<br>
id != 0. All the other modems have been able to correctly setup<br>
multiplexing when requested without issues.<br>
<br>
Even if the tests have been quite satisfactory overall (I've tested<br>
>60 different modems in the past month), I think that for 1.18 we<br>
should not enable multiplexing by default (except for IPA), and still<br>
leave it as a requirement from the user at connect time. So, if the<br>
user wants to setup a connection with multiplexing enabled, it should<br>
pass either "multiplex=requested" or "multiplex=required" in the<br>
connection settings explicitly<br>
<br></blockquote><div><br></div><div>I think it makes sense.</div><div><br></div><div>Thanks,</div><div>Daniele</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I've also updated the daemon to have a "--test-multiplex-requested"<br>
option, so that if given, the default would be back to attempt to<br>
enable multiplexing whenever possible.<br>
<br>
The main reason for this decision is that the network interface that<br>
gets connected if multiplexing is enabled would change between 1.16<br>
and 1.18, because with multiplexing we're connecting an ephemeral<br>
network link that we have created during runtime  (e.g. for a QMI<br>
modem that had a connected net interface named wwan0 in 1.16, the<br>
connected net interface in 1.18 would be named qmapmux0.0 instead).<br>
<br>
This connected net interface name change wasn't an issue for<br>
NetworkManager or standard distributions, but it would have been a<br>
major change for every other custom system using ModemManager, if e.g.<br>
custom firewall or routing rules were configured based on the network<br>
interface name and such. I think we should provide more information<br>
about the feature to system integrators, and give some more time for<br>
the feature to be used and tested, before discussing again whether it<br>
should be the default or not in 1.20.<br>
<br>
The MR that includes the changes to update the multiplexing default is<br>
this one, including some other related fixes:<br>
<a href="https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/598" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/598</a><br>
<br>
Comments welcome!<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</blockquote></div></div>