Unable to get IPv4 over LTE

[Vincent Bernat]

 ❦ 20 janvier 2016 09:58 +0100, Bjørn Mork <bjorn at mork.no> :

> 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?

No, I don't know.

> 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.

Is it possible to query it?

> 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.

Is it an easy way to force from LTE? Currently, I go in my bathroom, but
that's not very convenient when you are in a car for example. I have
tried --set-preferred-mode, but it forces me to use --set-allowed-modes
and I get:

$ mmcli -m 0 --set-preferred-mode=3g --set-allowed-modes='2g|3g|4g'
error: couldn't set current modes:
'GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method
SetCurrentModes is not implemented on interface
org.freedesktop.ModemManager1.Modem'

I am open to any manipulation through mmcli to fix the situation. I
already have a large script to get the modem in good shape after
resuming since otherwise, the SIM is "missing":

  Status   |           lock: 'unknown'
           | unlock retries: 'unknown'
           |          state: 'failed'
           |  failed reason: 'sim-missing'
           |    power state: 'low'
           |    access tech: 'unknown'
           | signal quality: '0' (cached)

>> 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?

If you want to reach a capable person at Lenovo, you could ping Peter FP
Zhang (zhangfp1 ... lenovo ... com). I remember that he was able to
quickly get a BIOS problem fixed on the Linux Thinkpad mailing list last
year (in less than two weeks, from the report to the release!). Maybe he
can handle this kind of stuff too.
-- 
Kindness is a language which the deaf can hear and the blind can read.
		-- Mark Twain