Dealing with 'pdp-type-ipv4-only-allowed' errors on MBIM

[Aleksander Morgado]

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.

-- 
Aleksander
https://aleksander.es