Dealing with 'pdp-type-ipv4-only-allowed' errors on MBIM
aleksander at aleksander.es
Mon Sep 7 08:22:13 UTC 2020
> 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
> 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
> 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
The step that retrieves IP settings already allows exposing IPv4-only
even if IPv4v6 was requested, so we would only need to change the
More information about the ModemManager-devel