Enabling IPv6 on the Huawei ME906s-158 / HP lt4132

Last year I wrote a post about my difficulties getting IPv6 to work with the Huawei ME906s-158 WWAN module. I eventually gave up and had it replaced with a module from another manufacturer.

Not long ago, though, I received an e-mail from another ME906s-158 owner who told me that for him, IPv6 worked just fine. That motivated me to brush the dust off my module and try again. This time, I figured it out! Read on for the details.

The Carrier PLMN List

The ME906s-158 comes with a built-in list of nine different PLMN profiles. This list can be managed with proprietary AT command AT^PLMNLIST, which is documented on page 209 of the module’s AT Command Interface Specification.

To interact with the AT command interface, use the option driver. More details on that here.

This is the complete factory default list:

AT^PLMNLIST?

^PLMNLIST: "00000",00000,23106,26207,23802,23806
^PLMNLIST: "20205",26801,20205,26202,26209,27201,27402,50503,54201,53001,40401,40405,40411,40413,40415,40420,40427,40430,40443,40446,40460,40484,40486,40488,40566,40567,405750,405751,405752,405753,405754,405755,405756,20404,20601,20810,21401,21670,22210,22601,23003,23415,24405,24802,27602,27801,28001,28602,28802,29340,42702,60202,62002,63001,63902,64004,64304,65101,65501,90128,23201,28401,64710,46601,42602,22005,41302,29403,50213,50219,21910,25001,27077,52505,23801,40004,42403,46692,52503,73001,24602,24705
^PLMNLIST: "26201",26201,23001,20416,23203,23207,21901,21630,23102,29702,29401,26002,20201,23431,23432
^PLMNLIST: "21403",20610,20801,20802,21403,22610,23101,23430,23433,26803,26003
^PLMNLIST: "50501",50501,50571,50572
^PLMNLIST: "22801",22801,29501
^PLMNLIST: "21407",21405,21407,23402
^PLMNLIST: "99999",24491,24001,23820
^PLMNLIST: "50502",50502 

OK

Each ^PLMNLIST: line represents a single pre-defined PLMN profile, identified by the first MCCMNC number (in double quotes). The "26201" profile is for Deutsche Telekom, the "50501" profile is for Telstra Mobile, and so on.

The rest of the numbers on each line is a list of MCCMNCs that will use that particular profile. For example, if you have a SIM card issued by T-Mobile Netherlands (MCCMNC 20416), then the ME906s-158 will apply the Deutsche Telekom profile ("26201").

Unfortunately, the documentation offers no information on how the PLMN profiles differ and how they change the way the module work.

My provider (Telenor Norway, MCCMNC 24201) is not present in the factory default list. In that case, the module appears to use the "00000" PLMN profile («Generic») as the default, and that one disables IPv6! Clearly, Huawei haven’t read RFC 6540…

In any case, this explains why I failed to make IPv6 work last year, and why it worked fine for the guy who mailed me - his provider was among those that used the Deutsche Telekom PLMN profile by default.

Modifying the Carrier PLMN List

The solution seems clear: I need to add my provider’s MCCMNC to an IPv6-capable PLMN profile. The Deutsche Telekom one would probably work, but "99999" («Generic(IPV4V6)») seems like an even more appropriate choice.

Adding MCCMNCs is done with AT^PLMNLIST=1,"$PLMNProfile","$MCCMNC", like so:

AT^PLMNLIST=1,"99999","24201"

OK

(To remove an MCCMNC, use AT^PLMNLIST=0,"$PLMNProfile","$MCCMNC" instead.)

I can now double check that the "99999" PLMN profile includes 24201 for Telenor Norway:

AT^PLMNLIST="99999"

^PLMNLIST: "99999",24491,24001,23820,24201

OK

To make the new configuration take effect, it appears to be necessary to reset the module. This can be done with the AT^RESET command.

Confirming that IPv6 works

It is possible to query the module directly about IPv6 support in at least two different ways:

AT^IPV6CAP?

^IPV6CAP: 7

OK

AT+CGDCONT=?

+CGDCONT: (0-11),"IP",,,(0-2),(0-3),(0,1),(0,1),(0-2),(0,1)
+CGDCONT: (0-11),"IPV6",,,(0-2),(0-3),(0,1),(0,1),(0-2),(0,1)
+CGDCONT: (0-11),"IPV4V6",,,(0-2),(0-3),(0,1),(0,1),(0-2),(0,1)

OK

The ^IPV6CAP: 7 response means «IPv4 only, IPv6 only and IPv4v6» (cf. page 336 of the AT Command Interface Specification), and the +CDGCONT: responses reveal that the modem is ready to configure PDP contexts using the IPv6-capable IP types. Looking good!

Of course, the only test that really matters is to connect it:

$ mmcli --modem 0 --simple-connect=apn=telenor.smart,ip-type=ipv4v6
successfully connected the modem
$ mmcli --bearer 0                                                                                            
Bearer '/org/freedesktop/ModemManager1/Bearer/0'
  -------------------------
  Status             |   connected: 'yes'
                     |   suspended: 'no'
                     |   interface: 'wwp0s20f0u3c3'
                     |  IP timeout: '20'
  -------------------------
  Properties         |         apn: 'telenor.smart'
                     |     roaming: 'allowed'
                     |     IP type: 'ipv4v6'
                     |        user: 'none'
                     |    password: 'none'
                     |      number: 'none'
                     | Rm protocol: 'unknown'
  -------------------------
  IPv4 configuration |   method: 'static'
                     |  address: '10.169.198.77'
                     |   prefix: '30'
                     |  gateway: '10.169.198.78'
                     |      DNS: '193.213.112.4', '130.67.15.198'
                     |      MTU: '1500'
  -------------------------
  IPv6 configuration |   method: 'static'
                     |  address: '2a02:2121:2c4:7105:5a2c:80ff:fe13:9208'
                     |   prefix: '64'
                     |  gateway: '::'
                     |      DNS: '2001:4600:4:fff::52', '2001:4600:4:1fff::52'
                     |      MTU: '1500'
  -------------------------
  Stats              |          Duration: '59'
                     |    Bytes received: 'N/A'
                     | Bytes transmitted: 'N/A'

Success!

IPv6 roaming in the United States

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:

• IPv6 roaming in Belgium and Romania
• IPv6 roaming in the United Kingdom
• IPv6 roaming in Czechia
• IPv6 roaming in Sweden

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

T-Mobile - MCCMNC 310260

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.

IPv6 roaming in Sweden

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:

• IPv6 roaming in Belgium and Romania
• IPv6 roaming in the United Kingdom
• IPv6 roaming in Czechia

Test results

Telia - MCCMNC 24001

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

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

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.

Telenor Sweden - MCCMNC 24008

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.

Net4Mobility - MCCMNC 24024

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.

IPv6 roaming in Czechia

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:

• IPv6 roaming in Sweden
• IPv6 roaming in Belgium and Romania
• IPv6 roaming in the United Kingdom

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

T-Mobile - MCCMNC 23001

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

Exactly the same results as T-Mobile. Telenor’s HLR/HSS IPv6 blacklisting in action.

Vodafone - MCCMNC 23003

Vodafone is the only Czech operator to get a perfect score. IPv6-only and dual stack connectivity always works, regardless of the technology used.

Huawei ME906s-158 (a.k.a. HP lt4132): Linux and IPv6 support (or lack thereof)

UPDATE 2018-12-01: The parts about missing IPv6 support in this post is outdated, see this post for updated information.

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.