Vincent Bernat <[email protected]> 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 _______________________________________________ ModemManager-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
