QMI IPv6 crashes

[Dan Williams]

On Wed, 2014-06-11 at 10:12 +0200, Bjørn Mork wrote:
> Dan Williams <dcbw at redhat.com> writes:
> > On Thu, 2014-04-24 at 20:48 +0200, Bjørn Mork wrote:
> >> Dan Williams <dcbw at redhat.com> writes:
> >> 
> >> > Hi,
> >> >
> >> > I did some testing with the UML290 on both Verizon (LTE) and T-Mobile
> >> > (UMTS) and got odd results from GetCurrentSettings, and couldn't get any
> >> > connectivity:
> >> >
> >> > [mm-bearer-qmi.c:382] get_ipv6_config(): QMI IPv6 Settings:
> >> > [mm-bearer-qmi.c:393] get_ipv6_config():     Address: 2600:1014:b005:6ff1:7824:b541:88db:58c8/64
> >> > [mm-bearer-qmi.c:399] get_ipv6_config():     Gateway: d42f:cc9d:967a:4442::
> >> > [mm-bearer-qmi.c:410] get_ipv6_config():     DNS #1: 2001:4888:3a:ff00:304:d::
> >> > [mm-bearer-qmi.c:421] get_ipv6_config():     DNS #2: 2001:4888:39:ff00:308:d::
> >> >
> >> > This matches the raw QMI output, eg:
> >> >
> >> >>>>>>>   type       = "IPv6 Secondary DNS Address" (0x28)
> >> >>>>>>>   length     = 16
> >> >>>>>>>   value      = 20:01:48:88:00:39:FF:00:03:08:00:0D:00:00:00:00
> >> >>>>>>>   translated = { [0] = '8193 ' [1] = '18568 ' [2] = '57 ' [3] =
> >> > '65280 ' [4] = '776 ' [5] = '13 ' [6] = '0 ' [7] = '0 '}
> >> >
> >> > Now what is up with that...  neither the gateway nor the DNS servers are
> >> > actually valid IPv6 addresses?  Clearly stuff didn't work.
> >> 
> >> Huh? The DNS server addresses look both valid and reasonable to me.
> >> 2001:4888::/32 is allocated to Verizon, and there is nothing technically
> >> wrong with those addresses - is there?
> >> 
> >> The gateway looks suspicious though.  It is in a reserved part of the
> >> address space:
> >> http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
> >> I guess it could work nontheless, as long as the modem responds to NS
> >> for that address and the host doesn't sanity check it.  But it makes
> >> more sense using some other address pointing to the modem, if you can.
> >> Or try disabling ARP (i.e. ND) and just point the default route to the
> >> wwan0 device.
> >> 
> >> Maybe using the RAs at least for the default route makes more sense?
> >> That's what you'll do in almost every other case.  Or doesn't the modem
> >> respond to RS? Do you see any other IPv6 packets from the modem?
> >
> > Update on this.  I've tested a number of different devices with two
> > different SIMs where both carriers support IPv6.
> >
> > Novatel USB551L + Verizon: V4V6 works fine
> > Novatel USB551L + T-Mobile: V4V6 crashes the modem
> > Huawei E398 + Verizon: V4V6 works fine
> > Huawei E398 + T-Mobile: V4V6 works fine
> > Sierra MC7750 + Verizon: V4V6 works fine in Windows
> > Sierra MC7750 + Verizon: V4V6 crashes modem in Linux
> 
> The last one is very interesting as it is a sign that we can avoid the
> crash by doing "something" differently.  But I have no clue what that
> could possibly be.  Maybe it's because we use a different MAC address?
> Or maybe it's our DAD packets messing up the modem?

It may well be; I got a crashlog from the 7750 a while back with "AT!
GCDUMP":

Src: FatalError
Dat: 00000DFE
Str: ps_icmp6_nd.c
Fmt: Can't find the ND control block
00000000 00000000 00000000 00000000
Task: DS
Time: 0000CCE3

So yeah it has something to do with neighbor discovery.

> Does the Novatel USB551L + T-Mobile work in Windows as well?

I'll have to try that too, though the Verizon connection manager doesn't
like working with the T-Mobile SIM.  I'll see what I can do.

> Did you try disabling anything that might possibly send anything
> unexpected to the modem (SLAAC, ND, whatever)?  In theory the connection
> should still work with a statically assigned address, default routing
> out the interface and no ND.

Haven't had time to do this yet, but I'll try to get there.  I wonder if
there's a good way to disable the kernel assignment of an LL address to
the interface, just for testing?  (though I think not...)

Dan