problems with QMI dual stack connections from MM - works with qmicli
aleksander at aleksander.es
Mon Apr 26 09:52:34 UTC 2021
> >> > Well, the direct reason is clear from the log: We skip the
> >> > CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect
> >> > multiple IPv6 bearers after the first one. Just not any IPv4 or
> >> > dual-stack.
> >> OK, an extra debug line proves that this is because of the only possible
> >> reason: ctx->no_ip_family_preference is TRUE on the second bearer
> >> But how did that happen?
> > I assume you're testing this by running mmcli --simple-connect without
> > using an explicit ip-type in the connection settings?
> Yes, this explains that part.
> > The no_ip_family_preference flag was originally implemented to allow
> > running WDS Start Network without the explicit IP Family Preference
> > TLV, to cover old devices that would not support that TLV yet. So, if
> > no explicit IP type is requested during connection, we would skip
> > adding that TLV.
> > The logic was later updated to skip running the WDS Set IP Family
> > command following the same reason, i.e. if no IP type was requested as
> > input. This additional check could probably be skipped and we should
> > always always try to run this command, and just ignore the error if it
> > fails with an unsupported error or something.
> > So, if you're attempting to connect the IPv4-only context by skipping
> > the ip-type connection setting, this issue would be triggered. I
> > cannot reproduce the issue if I consistently use ip-type=ipv4 when
> > wanting to connect to IPv4-only.
> > I believe this should change though, but I'm not sure how. Maybe we
> > should remove altogether the no_ip_family_preference flag; I don't
> > recall when this was implemented (back in 2012) whether adding the TLV
> > to the Start Network command would break the connection attempt on
> > modems not supporting it, or just if it would silently ignore it. I'm
> > going to test with the oldest QMI devices I have around and see what
> > happens.
> The QMI connection logic has always been fragile and over-complicated.
> And it's not our fault. The firmware implemetation is fragile and
> I've been trying to come up with a procedure which is consistently
> working for me on this *one* modern modem over the weekend. And
> failed. I am starting to wonder if we can make this work..
> Some observations:
> - dual-stack fails if default bearer is connected as ipv4 only
Oh, but this is expected, isn't it? or is it not expected? I have
always assumed that to be the case.
> - default bearer APN changes when switching SIMs (to SIM defined APN?)
Is the module switching carrier config as well when switching SIMs?
Please note that ModemManager has 2 different sets of settings for the
initial APN: the settings stored in the modem (either provided by
carrier config or set by user manually) and also the real settings
reported by the network once it's registered. E.g. the modem may ask
for APN "internet" and the network may successfully register the
device with APN ("data") instead. mmcli should show both these things
separately; the real network status settings will be reported as a
separate bearer object.
> - connecting multiple ipv4 or dual-stack bearers fails
Wait, it doesn't fail for me here, as long as I use ip-type=ipv4
explicitly for example.
I haven't been able to test multiple dual-stack here yet; my network
operator allows me to use multiple IPv4 APNs but no IPv6, and I still
don't know how to configure more than one IPv4v6 APNs in my home LTE
> - connecting multiple ipv6 bearers works
> This is with commit 1fce03879e28 ("trying to move indication setup")
> Multiple ipv4 bearers works for me on commit f17095045187 ("port-qmi:
> fix WITH_QRTR check")
> I am unable to make any sense out of this, and am seriously considering
> just switching to MBIM and forgetting about this Qualcomm firmware mess
> Sorry, i do not think these issues are related to ModemManager at all.
The connection logic was really complex before adding the multiplexing
support already, it is much more complex now, and it's even more
complex for the setup in Qualcomm SoCs...
There is one additional thing you didn't test, and I don't know if it
would be useful for you or not. See this MR here:
That branch allows querying/modifying/deleting connection profile
settings in devices, and it also allows requesting a connection
through a specific profile. The WDS Start Network, in this case, just
references the profile id that should be connected.
More information about the ModemManager-devel