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? 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. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
