Hey!
> > The current MM scheme where it will tries IPV4V6 by default, and falls
> > back to IPV4 and then IPV6 works pretty well.
> >
> > But I've been looking at the other end of this the last few days. And
> > been puzzled by the fact that we get a session established on the first
> > IPv4V6 attempt, which is then immediately disconnected with RADIUS
> > reporting
> >
> > Acct-Terminate-Cause = User-Request
> >
> > I obviously never considered that the error could be on the ModemManager
> > client side :-) Thought we had something wrong in the APN config on the
> > PGW.
> >
> > Then I just tried establishing sessions with mbimcli, and noticed that
> > this works just fine both with IpType set to either 'default' or
> > 'ipv4v6'. We get a 'connect-done' message with
> > ActivationState = 'activated' and IpType = 'ipv4' in both cases.
> >
> > The problem seesm to be that the 'connect-done' also sets
> > NwError = '50' ('pdp-type-ipv4-only-allowed'), which is correct. I
> > assume this is what makes MM disconnect the session and retry with a new
> > ipv4 only bearer. This is suboptimal both from the client and network
> > side. It would be really nice if MM could just be happy with that
> > 'activated' state.
> >
> > I am not even sure it should change the bearer from ipv4v6 to ipv4 when
> > the 'connect-don'e comes back with IpType = 'ipv4'. If that is even
> > possible? The APN might (and in this case - will ) change to dual stack
> > in the future. Continuing to request ipv4v6, but accept ipv4, is the
> > correct thing to do.
> >
>
> I believe we did use the "returned ip type" in the past, but then
> changed that logic. Here's a comment in the code that may be relevant:
>
> /* Report the ip_type we originally requested, since the
> ip_type
> * from the response is only relevant if the requested used
> * MBIM_CONTEXT_IP_TYPE_DEFAULT, which MM never does. Some
> * devices (K5160) report the wrong type in the response.
> */
>
> I wonder if "the wrong type" in the response is really in line with
> what you found out; i.e. that asking for IPv4V6 may end up returning
> IPv4 only and we shouldn't treat that as an error really.
>
> We also right now look for the nw_error before anything else, and if
> there is such an error, we abort the attempt. We should also improve
> that.
>
> The step that retrieves IP settings already allows exposing IPv4-only
> even if IPv4v6 was requested, so we would only need to change the
> previous step.
>
How about this?
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/348
--
Aleksander
https://aleksander.es
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
