Unable to get IPv4 over LTE

[Bjørn Mork]

Vincent Bernat <bernat at luffy.cx> writes:

So, failing LTE:

> [mm-bearer-mbim.c:212] ip_configuration_query_ready(): IPv4 configuration available: 'address, gateway'
> [mm-bearer-mbim.c:218] ip_configuration_query_ready():   IP addresses (1)
> [mm-bearer-mbim.c:222] ip_configuration_query_ready():     IP [0]: '10.130.78.68/24'
> [mm-bearer-mbim.c:231] ip_configuration_query_ready():   Gateway: '10.130.78.1'
> [mm-bearer-mbim.c:258] ip_configuration_query_ready(): IPv6 configuration available: 'none'

Working HSPA:

> [mm-bearer-mbim.c:212] ip_configuration_query_ready(): IPv4 configuration available: 'address, gateway, dns'
> [mm-bearer-mbim.c:218] ip_configuration_query_ready():   IP addresses (1)
> [mm-bearer-mbim.c:222] ip_configuration_query_ready():     IP [0]: '10.147.116.209/24'
> [mm-bearer-mbim.c:231] ip_configuration_query_ready():   Gateway: '10.147.116.1'
> [mm-bearer-mbim.c:239] ip_configuration_query_ready():   DNS addresses (2)
> [mm-bearer-mbim.c:244] ip_configuration_query_ready():     DNS [0]: '10.200.102.244'
> [mm-bearer-mbim.c:244] ip_configuration_query_ready():     DNS [1]: '10.200.102.243'
> [mm-bearer-mbim.c:258] ip_configuration_query_ready(): IPv6 configuration available: 'none'

Working LTE:

> [mm-bearer-mbim.c:212] ip_configuration_query_ready(): IPv4 configuration available: 'address, gateway, dns'
> [mm-bearer-mbim.c:218] ip_configuration_query_ready():   IP addresses (1)
> [mm-bearer-mbim.c:222] ip_configuration_query_ready():     IP [0]: '10.147.150.111/24'
> [mm-bearer-mbim.c:231] ip_configuration_query_ready():   Gateway: '10.147.150.1'
> [mm-bearer-mbim.c:239] ip_configuration_query_ready():   DNS addresses (2)
> [mm-bearer-mbim.c:244] ip_configuration_query_ready():     DNS [0]: '10.200.102.244'
> [mm-bearer-mbim.c:244] ip_configuration_query_ready():     DNS [1]: '10.200.102.243'
> [mm-bearer-mbim.c:258] ip_configuration_query_ready(): IPv6 configuration available: 'none'

The other messages look pretty similar. As you point out:  The only
observable difference is the lack of DNS addresses.  And a minor
difference in the allocated addresses, which may or may not be related.
You wouldn't happen to know if the operator differentiate between the
10.130.0.0/16 and 10.147.0.0/16 addresses?

Well, what I suspect is that the missing DNS servers (and possible the
address pool) is a symptom of a weird firmware behaviour on the EM7345:
It doesn't necessarily respect the requested APN on LTE.  I have also
seen this, being completely unable to initiate an IPv4 connection to any
specific APN different from the default without doing some trick to
force a new connection.

What I *believe* happens is that the firware is too eager to reuse the
default bearer on LTE. So if you request an IPV4 connection and the
default bearer is on IPv4 too, then the firmware doesn't really connect
anything at all - it simply returns the default bearer attributes.
Which is fine if the default bearer APN and the requested APN is the
same.  It will also appear to work if the default bearer APN provides
the service you want (Internet access typically).  But it doesn't have
to, and I suspect your operators don't do that.

I don't know if you even can specificy the APN of the default bearer on
this modem?  It seems to be operator MCC+MNC derived.

Apart from forcing the modem away from LTE, I suspect that you may force
another network connection by either requesting an IPv6 context or
connecting more than one IPv4 APN.  IIRC the problem only affected the
first IPv4 connection.  But MM doesn't support multiple connections on
MBIM yet, does it?  So neither of these workarounds are really useful
for daily usage.

> As I said, I have the same behavior with different carriers. Maybe they
> all use the same software though (carriers are Salt (CH), Sunrise (CH)
> and Orange (FR)).
>
> I have never updated the firmware of the modem (I think this is only
> possible from Windows and no Windows). The modem is quite buggy and I
> often use a "reset-all" script to get things in working order. When I
> say I "reset" the modem, this includes a USB reset (ioctl
> USBDEVFS_RESET).

A firmware update will probably help on stability, but I don't think
they've ever fixed the "wrong APN" bug I refer to above.  Not that I've
bothered reporting it either.  Sierra doesn't want to support this modem
directly (which I can understand) and refer to Lenovo for support. And I
don't know where to start there.. Besides, I suspect this is really an
Intel bug.  Maybe someone here with an XMM7160 modem from another vendor
can confirm?



Bjørn