Aleksander Morgado <aleksan...@aleksander.es> writes:
> Hey,
>
>> > 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
over-complicated.
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
- default bearer APN changes when switching SIMs (to SIM defined APN?)
- connecting multiple ipv4 or dual-stack bearers fails
- 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.
Bjørn
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
