[PATCH 0/3] Enabling IPv6 on Qualcomm MDM9x00 chipsets

[Dan Williams]

On Wed, 2013-11-27 at 19:08 +0100, Bjørn Mork wrote:
> Dan Williams <dcbw at redhat.com> writes:
> 
> > So this NV item is actually called NV_IPV6_ENABLED_I, which is pretty
> > telling.  And it's only one byte in length too.
> 
> You have documentation for the NV items?  Is that available to the
> public somewhere?

I don't have recent, but searching usually snags some results.  In the
phone world they are often called "seems" for some reason, since NV
items usually need reflashing when you move a phone from carrier to
carrier on CDMA.  So, you pick an NV item that you know the name of, you
google for it, then you find an item close to the one you want to know
about, and google for that.  And then sometimes you can find the exact
one you want to know :)

None of the NV item numbers or their structure definitions is
copyrightable since lists of numbers fall under the phonebook copyright
exceptions, at least in the US.

> >> Note that if you have an IPv6 *only* SIM, like I have, then you also
> >> have to change the PDP type of the default profile to IPV6 and restart
> >> the modem.  Else it won't work.  The same goes for IPv4 *only* SIMs,
> >> actually: If the default profile has a type different from IP, then
> >> the modem will fail to attach to the network.
> >
> > Does this still hold for IPV4V6, if the modem supports it?  Or is it
> > only a problem with SIM:IPv6 & PDP:IPV4 and vice versa?
> 
> You tell me. I don't know.  Currently I have a number of IPv4 only SIMs,
> and one IPv6 only SIM.  I do not have any SIM allowing dual stack IPV4V6
> connections.

AFAIK, the SIM isn't the problem, it's the device and the carrier/APN.
The SIM really shouldn't care at all, it's just used for authentication
and home/roaming.  If the device supports IPv6 (not all do of course)
then it will request an IPv6 bearer from the carrier, and if the carrier
supports IPv6 *and* your APN allows IPv6, then you'll get it.

> From what I understand, there is some doubt about IPV4V6 among
> operators. If you depend on that type, then you prevent roaming in
> networks which does not support it, IIUC.  And there are still a few of
> those around the world.
> 
> So the operators seem to be more interested in NAT64/DNS64/464XLAT
> solutions using IPV6 only PDP contexts than true dual stack solutions.
> It does make some sense, given that most of them would use NATed RFC1918
> addresses for the IPv4 part of the IPV4V6 context anyway.
> 
> But that's probably because they don't care at all about IPv6 in mobile
> broadband devices yet

Having IPV4V6 just makes it easier in the client, since the client
doesn't have to start multiple PDP contexts, one for IPv4 and one for
IPv6.  On most modems, that would require either two network ports, or
one network port and one free TTY for PPP.  In the QMI case, the device
is perfectly happy to run both protocols over the same network interface
though, which makes things really, really simple.  AT commands, not so
much.

> 
> >> So how do you find your default profile?  It's often the first one,
> >> listed as 1 in the output from AT+CGDCONT?.  So an easy way to change
> >> it to IPV6 is by using the AT command interface:
> >> 
> >>  AT+CGDCONT=1,"IPV6"
> >> 
> >> You can verify that this in fact changed the default by using qmicli:
> >> 
> >>  bjorn at nemi:~$ qmicli -d /dev/cdc-wdm0 --wds-get-default-settings=3gpp
> >>  Default settings retrieved:
> >>          APN: ''
> >>          PDP type: 'ipv6'
> >>          Username: ''
> >>          Password: ''
> >>          Auth: 'none'
> >> 
> >> 
> >> I hope this helps documenting yet another piece of undocumented
> >> magic in these Qualcomm firmwares.  You gotta wonder what they smoked
> >> the day they decided to disable IPv6 by default...
> >
> > Well, I'm sure there's documentation in the Qualcomm ICDs and under
> > NDA :)  But we certainly don't have any of that.  The NV item
> > provisioning is under the control of the OEM or the provider during
> > provisioning, so the best guess is that the OEM either just didn't
> > bother to set it, since they didn't care about IPv6, or they actually
> > don't want to support it, or they are relying on provider-specific
> > connection software to make the change when needed.
> 
> You are probably right.  It doesn't make any sense to me, but that seems
> to be the way they think.  "Let's just make sure things fail in subtle
> and random ways.  That will save us from supporting it.  IPv6 is an
> advanced feature which noone needs.  We can always fix this in the next
> batch"

Check out my response with the E397 though; it has an 'inactive'
IPV6_ENABLE NV item, yet I'm still able to use IPv6 with it.  I'll have
to test other devices too.  Perhaps 'inactive' just means 'default', not
"unsupported".  I'll try disabling it explicitly and then connecting
with V6.

Dan