16 Feb 2018
I spent some time in the United States last month. Equipped with SIM cards from
both Tele2 Sweden (MCCMNC 24007) and Telenor Norway (MCCMNC 24201), I set out
to test IPv6 while roaming, as I usually do while abroad.
The previous posts in this series are:
There were two mobile networks that I was able to register in and test:
AT&T (3G/4G, no 2G) and
T-Mobile (2G/3G/4G). The test results are found
below.
I could also see three other 4G networks show up in a network scan (Caprock
Cellular, Sprint and
Verizon), but none of those were available
to me. Presumably neither Tele2 nor Telenor have roaming arrangements with any
of those operators.
AT&T - MCCMNC 310410
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Tele2 SE |
3G |
Fails (cause code 33) |
IPv4-only (cause code 50) |
Tele2 SE |
4G |
Works perfectly |
Works perfectly |
Telenor NO |
3G |
Fails (cause code 33) |
IPv4-only (cause code 50) |
Telenor NO |
4G |
Works perfectly |
Works perfectly |
T-Mobile - MCCMNC 310260
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Tele2 SE |
2G |
Fails (cause code 33) |
IPv4-only (cause code 50) |
Tele2 SE |
3G |
Fails (cause code 33) |
IPv4-only (cause code 50) |
Tele2 SE |
4G |
Works perfectly |
Works perfectly |
Telenor NO |
2G |
Fails (cause code 33) |
IPv4-only (cause code 50) |
Telenor NO |
3G |
Fails (cause code 33) |
IPv4-only (cause code 50) |
Telenor NO |
4G |
Works perfectly |
Works perfectly |
3GPP cause code #33 means «requested service option not subscribed», while
cause code #50 means «PDP type IPv4 only allowed». The latter doesn’t
indicate a fatal error, as I do automatically get a working IPv4-only
connection to the Internet.
The fact that IPv6 consistently fails on 2G/3G is in all likelihood due to
Tele2/Telenor’s
HLR
removing the IPv6 capabilities from my subscriber profile before transmitting
it to AT&T/T-Mobile’s
vSGSN.
Tele2 and Telenor do this to forestall the possible IPv6-related failures
described in RFC 7445 sections
3 and
6. In this case, it is in all
likelihood an unnecessary precaution, considering that both AT&T and T-Mobile
are known to have deployed IPv6 to their own customers.
15 Oct 2017
I attended the Netnod Tech Meeting
2017 in
Stockholm earlier this week. As I usually do when when going abroad, I spent
some time testing to what extent IPv6 works while roaming in the various
PLMNs I have access
to.
The previous posts in this series are:
Test results
Telia - MCCMNC 24001
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Telenor Norway |
2G |
Fails |
IPv4-only connection |
Telenor Norway |
3G |
Fails |
IPv4-only connection |
Telenor Norway |
4G |
N/A (no service) |
N/A (no service) |
It would appear that Telenor Norway does not have a 4G roaming agreement with
Telia. My phone was unable to register in Telia’s 4G network, at least.
In 3G and 2G coverage, I could register, but IPv6 did not work. Requesting dual
stack connectivity would only yield IPv4. This is of course a quite acceptable
outcome for the vast majority of users, as the Internet will ostensibly work
just fine..
In all likelihood the IPv6 failures observed on 2G and 3G is due to Telenor
Norway’s
HLR
removing the IPv6 capabilities from my subscriber profile before transmitting
it to Telia’s
vSGSN.
This is done to forestall the possible IPv6-related failures described in RFC
7445 sections
3 and
6.
Presumably Telenor Norway will, at some point in the future, remove this IPv6
capability blacklisting for Telia, after having ascertained that Telia’s 2G/3G
network does not have any issues with supporting the IPv6 PDP types.
3 - MCCMNC 24002
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Telenor Norway |
3G |
Fails |
IPv4-only connection |
Telenor Norway |
4G |
Works perfectly |
Works perfectly |
In 4G coverage, IPv6 works perfectly. In 3G coverage, it fails - presumably due
to the same IPv6 capability blacklisting as described above for Telia.
I did however notice at one point that if I connected a dual stack IPV4V6 PDP
context while in 3’s 4G network, and then moved into an area that had only 3G
coverage, IPv6 kept working perfectly. Thus it would appear that 3’s 3G network
has no issues supporting visiting subscribers using IPv6.
Note that 3 does not operate a 2G network.
Tele2 - MCCMNC 24007
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Telenor Norway |
3G |
Fails |
IPv4-only connection |
Telenor Norway |
4G |
Works perfectly |
Works perfectly |
Same results as for 3.
I did not get to test physically moving from 4G to 3G coverage. That said, I
know for a fact that Tele2 provides IPv6 to their own mobile subscribes, so it
seems like a safe bet to assume that their 3G network would support IPv6 just
fine, if it hadn’t been for Telenor’s IPv6 capability blacklisting.
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Telenor Norway |
3G |
Works perfectly |
Works perfectly |
Telenor Norway |
4G |
Works perfectly |
Works perfectly |
Perfect score. It is perhaps not surprising that if a single Swedish operator
would be fully «IPv6-approved», and therefore exempt from Telenor Norway’s IPv6
capability blacklisting, it would be their Swedish sister company Telenor
Sweden.
It might also be worth noting that Telenor Sweden is the vPLMN my phone prefers
to register in if I leave it in the default automatic mode. Therefore, for
Telenor Norway subscribers, IPv6 Just Works while visiting Sweden - unless
one manually fiddles around with the network settings.
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Telenor Norway |
2G |
Works perfectly |
Works perfectly |
Perfect score.
The Net4Mobility PLMN is, as far as I can understand, a joint venture between
Tele2 and Telenor Sweden that provides shared 2G coverage for both of those
providers. That is, if I lock my phone on to MCCMNC 24007 (Tele2) or 24008
(Telenor Sweden), it will nevertheless change to 24024 (Net4Mobility) if I also
limit it to 2G only.
This means Net4Mobility is logically part of Telenor Sweden’s network, and thus
it makes sense that it, like MCCMNC 24008, is exempt from Telenor Norway’s IPv6
capability blacklisting.
12 Oct 2017
I spent this weekend in Czechia. As I usually do when when going abroad, I
spent some time testing to what extent IPv6 works while roaming in the various
PLMNs I have access
to.
The previous posts in this series are:
Those posts contain some more technical background about the testing
methodology, so I suggest you skim through them in order to better interpret
the test results in this post.
Test results
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Telenor Norway |
2G |
Fails |
IPv4-only connection |
Telenor Norway |
3G |
Fails |
IPv4-only connection |
Telenor Norway |
4G |
Works perfectly |
Works perfectly |
While in 2G and 3G coverage Telenor’s HLR/HSS blacklisting trick comes into
play, blocking any kind of IPv6 usage. (See the IPv6 roaming in Belgium and
Romania post for an
explanation of what that trick is.)
These results do not necessarily mean that T-Mobile has a problem with
supporting IPv6 on 2G and/or 3G. It could very well be that it is entirely due
to Telenor’s HLR/HSS blacklisting, and that it would start working immediately
if Telenor were to move T-Mobile to their IPv6 whitelist.
When in 4G coverage, IPv6-only and dual stack work perfectly. This is as
expected, because the HLR/HSS blacklisting trick does not work on 4G.
O2 - MCCMNC 23002
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Telenor Norway |
2G |
Fails |
IPv4-only connection |
Telenor Norway |
3G |
Fails |
IPv4-only connection |
Telenor Norway |
4G |
Works perfectly |
Works perfectly |
Exactly the same results as T-Mobile. Telenor’s HLR/HSS IPv6 blacklisting in
action.
Home PLMN |
Tech |
IPV6 PDP context |
IPV4V6 PDP context |
Telenor Norway |
2G |
Works perfectly |
Works perfectly |
Telenor Norway |
3G |
Works perfectly |
Works perfectly |
Telenor Norway |
4G |
Works perfectly |
Works perfectly |
Vodafone is the only Czech operator to get a perfect score. IPv6-only and dual
stack connectivity always works, regardless of the technology used.
31 Jul 2017
I recently purchased a new laptop, an HP EliteBook 820
G4.
When ordering, I was given the choice of two different LTE WWAN modems: the HP
lt4120 and the HP lt4132. The former is a rebranded Foxconn T77W595, while
the latter is a rebranded Huawei
ME906s-158.
Both modems cost about the same and there were reports of people getting them
both working under Linux, so it didn’t seem to matter much which of them I
chose. I eventually decided on the lt4132, the primary reason being that its
specifications
clearly state that it supports IPv6. This made the lt4132 seem like the safe
choice, as I was unable to easily confirm that the lt4120 supported IPv6.
I was wrong. I should have opted for the lt4120. Read on for the details.
Linux support
The lt4132 did not work out of the box with my preferred Linux distribution
Fedora 26;
ModemManager didn’t
recognise it as a supported modem.
The modem was visible in the output from usb-devices
, however:
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=ff MxPS=64 #Cfgs= 3
P: Vendor=03f0 ProdID=a31d Rev=01.02
S: Manufacturer=HP
S: Product=HP lt4132 LTE/HSPA+ 4G Module
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=2mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=06 Prot=00 Driver=cdc_ether
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver=(none)
I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=(none)
I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=(none)
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=14 Driver=(none)
I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver=(none)
The problem here is Cfg#= 2
, indicating that the modem is in configuration
2
. The Linux kernel selects configuration 2
by default, but that does not
work with ModemManager. Configuration 3
(
MBIM
mode) is a much better choice.
Changing to configuration 3
is easy enough. Note that it is essential to
first deconfigure the device by selecting configuration 0
and wait a few
milliseconds. Going directly from 2
to 3
does not work. Thus:
$ echo 0 > /sys/bus/usb/devices/1-3/bConfigurationValue
$ sleep 1
$ echo 3 > /sys/bus/usb/devices/1-3/bConfigurationValue
The 1-3
part might not be correct for your system. If it’s not, grep lt4132
/sys/bus/usb/devices/*/product
will probably tell you what the correct sysfs
device path is.
This made ModemManager recognise the modem. At this point I could run nmcli
con add type gsm ifname '*' apn telenor.smart
to make
NetworkManager successfully
establish a mobile data connection. Well, ostensibly - it still didn’t quite
work. All the data traffic was being blackholed. This was solved by enabling
the ndp_to_end
USB quirk, like so:
$ echo Y > /sys/class/net/wwp0s20f0u3c3/cdc_ncm/ndp_to_end
In the future, the lt4132 will be better supported out of the box. It will
not be necessary to manually deal with these settings; the upcoming version of
usb_modeswitch
will automatically select USB configuration 3
, and a patch I wrote to
automatically enable the ndp_to_end
USB
quirk
will be part of the Linux kernel starting with version 4.13.
In the interim, however, it is easy enough to automate the application of these
tweaks by using udev rules. Simply create
a file called, e.g., /etc/udev/rules.d/hp-lt4132.rules
and add the following
three lines to it:
ACTION=="add|change", SUBSYSTEM=="usb", ATTR{idVendor}=="03f0", ATTR{idProduct}=="a31d", ATTR{bConfigurationValue}!="3", ATTR{bConfigurationValue}:="0"
ACTION=="add|change", SUBSYSTEM=="usb", ATTR{idVendor}=="03f0", ATTR{idProduct}=="a31d", ATTR{bConfigurationValue}!="3", RUN+="/bin/sh -c 'sleep 1; echo 3 > %S%p/bConfigurationValue'"
ACTION=="add|change", SUBSYSTEM=="net", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="a31d", ATTR{cdc_ncm/ndp_to_end}=="N", ATTR{cdc_ncm/ndp_to_end}:="Y"
That’s all it takes. (You will probably want to change the vendor/product IDs
03f0
/a31d
if you don’t have the same HP-branded flavour of the Huawei
ME906s-158 I do, though.)
Lack of IPv6 support
The Huawei ME906s-158 product
page
clearly specifies that the modem supports IPv6. Turns out, this is a lie - or
at best, extremely misleading.
When I attempted to establish an IPv6 mobile data connection, it would just
fail:
$ mmcli -m 0 --simple-connect=apn=telenor.smart,ip-type=ipv6
error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.libmbim.Error.Status.NoDeviceSupport: NoDeviceSupport'
Requesting dual-stack with ip-type=ipv4v6
instead would ostensibly succeed,
but it would only yield an IPv4-only connection.
I also tried the modem under Windows 10. It was only able to get IPv4
connectivity there too, so it seems clear that this is a firmware issue. For
the record, I’m on the latest firmware available fom HP, version
11.617.13.00.00
.
In order to figure out what was going on, I used the option
serial port
driver to interact with the modem’s AT command
interface:
$ modprobe option
$ echo 03f0 a31d > /sys/bus/usb-serial/drivers/option1/new_id
$ cat /dev/ttyUSB0 &
The first thing to check is the output of the AT+CGDCONT=?
command, a
3GPP-standardised command which returns the supported
data types:
$ echo $'AT+CGDCONT=?\r' > /dev/ttyUSB0
+CGDCONT: (0-11),"IP",,,(0-2),(0-3),(0,1),(0,1),(0-2),(0,1)
OK
This is a smoking gun: there should have been two more lines returned here,
one with "IPV6"
and another with "IPV4V6"
in the second comma-separated
field. This output is essentially the modem stating «I only support IPv4».
Huawei has published an extensive
document
that details all the various AT commands supported by the modem. One of these
is AT^IPV6CAP
, a Huawei proprietary command to «Query IPv6 Capability» (see
page 281). The possible return codes and their meanings are documented as
follows:
1 IPv4 only
2 IPv6 only
7 IPv4 only, IPv6 only and IPv4v6
So let’s see what it says:
$ echo $'AT^IPV6CAP?\r' > /dev/ttyUSB0
^IPV6CAP: 1
OK
This appears to confirm what the AT+CGDCONT=?
command already told us, the
modem is IPv4-only. However, the AT^IPV6CAP=?
command did give me a little
bit of hope:
$ echo $'AT^IPV6CAP=?\r' > /dev/ttyUSB0
^IPV6CAP: (1,2,7)
OK
I interpret this to mean that the modem actually does contain support for
IPv6 and IPv4v6; only that it is currently in an IPv4-only operational mode.
The question then becomes: how to change the operational mode to 7
? I have no
idea, unfortunately. It’s not AT^IPV6CAP=7
, for what it’s worth.
I eventually had to give up on making IPv6 work with this modem. Perhaps it
will be fixed in a future firmware update, but until then my recommendation is
clear: stay away from the Huawei ME906s-158 / HP lt4132 LTE modem!
Support tickets were opened with both HP and Huawei support about the issue, by
the way. Despite several rounds of escalating their respective cases, none of
them were able to figure out a solution. HP support eventually gave up on
solving the case and shipped me a replacement HP lt4120 free of charge
instead. That did the trick; it turns out the lt4120 supports IPv6 perfectly.
I’ll have to commend HP for good customer support here; they obviously
considered the lack of IPv6 support to be a real defect and did what was
necessary to fix the problem in the most efficient manner.
30 Jul 2017
When I created this blog a couple of years ago, I was disappointed to find
out that the GitHub
Pages service (GHP) did not support IPv6. This was
due to the fact that GHP’s CDN provider Fastly didn’t
support IPv6.
To work around this problem I ended up inserting a dual-stacked HTTP proxy
service
in front of my (IPv4-only) GHP-hosted blog. While it was hardly ideal, it did
the trick.
The other day I was pleasantly surprised to find out that I no longer need this
hack: Fastly and GHP now do support IPv6! IPv6 appears to have been enabled for
https://toreanderson.github.io and all
other GHP sites without requiring explicit opt-in. Perfect!
When did it happen? Well, it seems Fastly announced IPv6 availability on the
31st of March (after having had it in
limited beta since last
summer).
Assuming Twitter is a reliable indicator, IPv6 was enabled for GHP specifically
sometime between the 10th of
April and the 28th
of May.
I was quite critical of Fastly in those old posts, so it’s only fair that I
congratulate them now. Well done, Fastly - I’m very happy to see you get on the
IPv6 bandwagon!