IPv6 supported by MC77xx?

Hello,

I’ve been trying to get an IPv6 (or more correct a dual-stack) connection up and running on a MC7710 in QMI mode, but have not been successful.

The recipe I’ve followed seems to work with a Huawei modem based on the same MDM9200 chip, so I assumed it would work with the Sierra module in QMI mode as well. I’ve configured profile1 with PDP-IPV4V6 using AT commands for simplicity:

+CGDCONT: 1,“IPV4V6”,“my-ipv4v6-apn”,“0.0.0.0”,0,0

This is configured as the default profile, and looks just fine when I look at it with QMI WDS commands. Then I’ve tried to connect by setting QMI_WDS_SET_CLIENT_IP_FAMILY_PREF to 4 and sending QMI_WDS_START_NETWORK_INTERFACE with an APN TLV matching the above profile, and then setting QMI_WDS_SET_CLIENT_IP_FAMILY_PREF to 6 and repeating the connect request using a second WDS client ID. This procedure will bring up a dual stack connection with the Huawei modem. With the MC7710 only the IPv4 session comes up, and what’s even more weird is that when I look at the runtime settings, then the PDP is set to PDP-IP - i.e. IPv4 only.

So I wonder, is the IPv6 support somehow disabled in the firmware? If so, are there other firmwares available? I’ve currently got
SWI9200X_03.00.08.02AP R3715 CARMD-EN-10526 2011/11/14 18:42:43

I have not yet tried IPv6 in Direct IP mode or in PPP mode. I don’t expect the latter to be supported, but I did notice that the newest Direct IP driver for Linux had added some code to handle IPv6 packets so I guess that might be working. I am most interested in QMI mode, though. There seems to be a significant speed advantage over the two other options.

Just for the record: There are definitely bugs in the Huawei IPv6 support, and if those are related to the Qualcomm part of this firmware then it certainly makes sense to disable it. The Huawei Qualcomm firmwares I’ve seen are:

M9200B-SCAQDBZD-3.0.350045T
M9200B-SCAQDBZD-3.0.350025T
M9200B-SCAQWBZD-3.3.33T

while it seems that the Qualcomm firmware embedded in the SWI firmware on the MC7710 is

M9200B-SCAQWBZD-3.0.370035T

I’ve no idea what those codes and numbers mean, but I guess it’s a combination of feature and version. Is some part of it indicating IPv6 as a “feature”, or is this just supposed to work on all firmwares? Is there some trick to enabling it?

Bjørn

Hi Bjørn,

Are you using Sierra QMI SDK? Are you testing against live network?

I am not able to check this issue now, but guess it worth a try using latest FW, if possible please contact your FAE or distributor to get it.

Thx

No, I am not using the Sierra QMI SDK. I just received the Linux SDK today and haven’t had the time to look at it yet. I am using a home cooked perl script to create the QMI commands, and injecting them using the qmi_wwan driver (which will be in Linux 3.4).

The network is sort of live. The APN routes to a test PGW, or whatever the GGSN like boxes are called in LTE networks, but the radio network is a live production network.

It would help to know what I was asking for. What is the latest firmware, and is there some FW changelog available somewhere?

I feel I need some reason to make a request, as I’ve been buggering my distributor enough already to build up a really bad conscience :slight_smile:

EDIT: I’ve now finally started looking at the Linux QMI SDK, and I see why you asked that question. It contains a lot of useful information about the FW images as well. Thanks for pointing that out.

Bjørn

Looks like I’ve got more challenges here. I’ve got the SLQS01.06.01 version of the SDK, but I obviously also need something else. Until now I have assumed that I could use the sierra.c driver as included in Linux 3.x after adding the appropriate product ID. And thiswill be default in Linux 3.4 unless someone acts fast!

But I see that the SDK refers to Serial / Network Drivers version 2.7/2.12.

The sierra.c version in mainline is v1.7.16 and the one I can find for public download on the SW website is v1.7.40. AFAICS both of these support the serial ports (DM, NMEA and AT) on th MC7710 just fine. But the SDK doesn’t like it. The log says:

Apr 27 15:27:22 nemi SWI SDK Process: SU:Process Started, version: SLQS01.06.01
Apr 27 15:27:22 nemi SWI SDK Process: SU:7 -> task started
Apr 27 15:27:22 nemi SWI SDK Process: QM:Task started
Apr 27 15:27:22 nemi SWI SDK Process: SU:12 -> task started
Apr 27 15:27:22 nemi SWI SDK Process: SU:1 -> task started
Apr 27 15:27:22 nemi SWI SDK Process: SU:17 -> task started
Apr 27 15:27:22 nemi SWI SDK Process: ttyUSB0 device found on USB Interface 0
Apr 27 15:27:22 nemi SWI SDK Process: ttyUSB0 device found on USB Interface 0
Apr 27 15:27:22 nemi SWI SDK Process: ttyUSB1 device found on USB Interface 2
Apr 27 15:27:22 nemi SWI SDK Process: ttyUSB1 device found on USB Interface 2
Apr 27 15:27:22 nemi SWI SDK Process: ttyUSB2 device found on USB Interface 3
Apr 27 15:27:22 nemi SWI SDK Process: ttyUSB2 device found on USB Interface 3
Apr 27 15:27:22 nemi SWI SDK Process: ttyUSB3 device found on USB Interface 8
Apr 27 15:27:22 nemi SWI SDK Process: ttyUSB3 device found on USB Interface 8
Apr 27 15:27:22 nemi SWI SDK Process: UDIAG:DS Shell launched
Apr 27 15:41:43 nemi SWI SDK Process: QM:SDK<-Mdm: ch/QMImsgid/QMImsglen/IPCmsglen: 0/0000/0/45
Apr 27 15:41:43 nemi slqstutorialhosti686: wQCWWANEnumerateDevices: rc = 0xE903, eQCWWAN_ERR_SWIDCS_DEVNODE_NOT_FOUND
Apr 27 15:41:43 nemi slqstutorialhosti686: #devices: 1 deviceNode:  deviceKey:

So the SDK doesn’t find what it’s looking for. Is that because of wrong serial driver, or is it looking for some magic the completely-unknown-to-me Network Driver?

It would be great if some of this information could be made publically available. I’ve got great help from my supplier so far, but they don’t really know all these details. Working via them as a proxy feels a bit like stumpling around blind folded.

Note that there has already been a request to add the 1199:68a2 device to the mainline Sierra serial driver, a change which will go into the Linux 3.4. And I have added the device to the new qmi_wwan driver which also will be in 3.4. If Sierra are planning on submitting anything upstream at all for these devices, then it is necessary to act now…

Bjørn

Hi,

SierraWireless release a specific set of driver for QMI module (including MC77xx) and that’s the one mentioned in SDK doc, “Serial / Network Drivers version 2.7/2.12”.
Using this driver, MC77xx should be detected and loaded automatically with no need to manually add the PID.

However, it is not included in SDK binary but one should able to get it from same network path downloading the SDK binary.
Kindly check the path you downloaded the SDK or ask your FAE/Disturator.

Hope it helps.
L

Sierra Wireless has a good reputation for providing drivers upstream. Do you happen to know if there are any plans for submitting this driver to the Linux mainline kernel?

The reason why I am eager to know this is because I recently hacked together a generic QMI/wwan driver based on some Huawei and ZTE modems using Qualcomm MDM9200. And as it seemed to work reasonably well for the MC7710 too, and there were no other drivers handling the SW QMI mode vid:pid in the kernel, I just added it to that driver. At the time I had no knowledge about the existence of any Sierra QMI Linux driver at all.

What this means is that unless we do something really fast to prevent it, then the MC77xx modules in QMI mode will be bound to the qmi_wwan driver in Linux 3.4. See Linus latest -rc announcement: lkml.org/lkml/2012/4/29/2

This can of course always be reversed if/when a new driver is submitted. But it will most certainly cause problems in the situation where you provide out-of-tree drivers. Which is yet another good reason to get them in the mainline tree as quickly as possible.

Thanks. I’ve asked and expect to receive it as soon as they have sorted out some access problems they were having.

Bjørn

OK, this is derailing quickly…

I haven’t yet received the drivers from my distributor, but looking at what the SDK is trying to do I have a strong feeling that they will look a lot like Qualcomm’s Gobi drivers. Could anyone confirm this? Which means that they are not suitable for the mainline Linux kernel and never will be. Elly Jones did a tremendous job trying to clean them up and submitting them a long time ago (see git.chromium.org/gitweb/?p=chrom … libqmi.git

But back to the SDK. How about getting it fixed to use the interface which will be in the mainline kernel? Should be a simple task. Another option is creating a shim driver just eating the ioctls from the SDK, but that is going to be rather ugly. I might do that anyway just to play with the binary SDK I’ve got, but I don’t think I’m going to make it public as the /dev/qcqmi thingy should really die… IMHO.

Right. I thought I could get away with a fuse based approach, but for some reason that didn’t work. Could be that the SDK verifies that the file is a char device?

Anyway, I just made a module. Ugly hack from hell, reading and writing from/to another char device, but it works. Found that the SDK enforces usbX naming, so the netdev must be renamed from wwanX first:

ip link set dev wwan0 name usb0

After that, everything is fine:

May  4 19:07:05 nemi SWI SDK Process: SU:Process Started, version: SLQS01.06.01
May  4 19:07:05 nemi SWI SDK Process: SU:7 -> task started
May  4 19:07:05 nemi SWI SDK Process: QM:Task started
May  4 19:07:05 nemi SWI SDK Process: SU:12 -> task started
May  4 19:07:05 nemi SWI SDK Process: SU:1 -> task started
May  4 19:07:05 nemi SWI SDK Process: UDIAG:DS Shell launched
May  4 19:07:05 nemi SWI SDK Process: SU:17 -> task started
May  4 19:07:05 nemi SWI SDK Process: ttyUSB0 device found on USB Interface 0
May  4 19:07:05 nemi SWI SDK Process: ttyUSB0 device found on USB Interface 0
May  4 19:07:05 nemi SWI SDK Process: ttyUSB1 device found on USB Interface 2
May  4 19:07:05 nemi SWI SDK Process: ttyUSB1 device found on USB Interface 2
May  4 19:07:05 nemi SWI SDK Process: ttyUSB2 device found on USB Interface 3
May  4 19:07:05 nemi SWI SDK Process: ttyUSB2 device found on USB Interface 3
May  4 19:07:05 nemi SWI SDK Process: qcqmi0 device found on USB Interface 8
May  4 19:07:05 nemi SWI SDK Process: qcqmi0 device found on USB Interface 8
May  4 19:07:05 nemi SWI SDK Process: swi_ossdkusbscan: drivers ready!
May  4 19:07:05 nemi SWI SDK Process: QM:qm_ds_handle_app_dev_ready: devstate 1
May  4 19:07:05 nemi SWI SDK Process: QM:SDK<-Mdm: ch/QMImsgid/QMImsglen/IPCmsglen: 1/0000/0/25
May  4 19:07:05 nemi slqstutorialhosti686: Device State Change Callback Invoked: rc = 0x1, 
May  4 19:07:05 nemi slqstutorialhosti686: appstatechange: device ready, APP disconnected from SDK
May  4 19:07:06 nemi slqstutorialhosti686: wSLQSStart: APP<->SDK IPC init successful
May  4 19:07:06 nemi slqstutorialhosti686: wSLQSStart: APP registered for Device State Change notification
May  4 19:07:18 nemi SWI SDK Process: QM:SDK<-Mdm: ch/QMImsgid/QMImsglen/IPCmsglen: 0/0000/0/62
May  4 19:07:18 nemi slqstutorialhosti686: wQCWWANEnumerateDevices: rc = 0x0, 
May  4 19:07:18 nemi slqstutorialhosti686: #devices: 1 deviceNode: /dev/qcqmi0 deviceKey: 1234567890abcd
May  4 19:07:18 nemi slqstutorialhosti686: appstatechange: device ready, APP disconnected from SDK

I do not think this is supportable though. I am certainly not going to submit it to mainline. But I might publish it in the code sharing foum here if there is any interest.

But the real solution is that the SDK adapts to the wwanX and /dev/cdc-wdmY devices instead. That should be a piece of cake if you have access to the SDK source. The only special services it seems to use from the qcqmi driver is the MEID ioctl and the Client ID allocation. The first is meaningless and could just as well have been done using QMI_DMS directly. And the second could also be done directly as the /dev/cdc-wdmY interface provides full access to QMI_CTL too (it isn’t QMI aware, so it cannot do any filtering at all)

I tried the MC7710 in DirectIP mode, using a R&S CMW500 as base station, but unfortunately, no success …

The CMW log says “RRC connection established”, I can briefly see it tries to set an IPv4 address and an IPv6 prefix, and then it stops with a “Signaling Failure” message.

The MC7710 uses dual stack, i.e. an IPv4v6 PDP type. If I change the PDP type to IPv4, everything works as expected.

I have tried MC7710 FW versions 3.5.19.04 and 3.5.23.2, neither works.

Hi Stefan,

Please submit a new post next time to get better exposure.

Anyway, as I know some MC77xx was configured with IPv6 support disabled.
It is carrier specific and in case you are using that kind of MC77xx for test, please check with your FAE or distributor for information.

Thx
L

Actually IPv6 was disabled in the module.

It took 3 months until the FAE provided the code to enable IPv6 …

Unfortunately, there is no error response if IPv6 is disabled, and setting a IPv6 or IPv4v6 context is possible nevertheless.

Anyway, thanks for the answer.

Hello,

I have two pieces of MC7710 and I can’t establish IPV6 PDP context. Could you please tell me how to enable IPV6 support on MC7710?

Thank you.

Regards,
Michal

Hi,
As per my previous post, can you please check with your FAE or distributor whether IPv6 was disabled and procedure to enable it?
Thx

I think somethink like querying the state of IPv6 belongs into the public documentation, and make changing the setting password protected.

As already stated, I waited 3 month for a FAE response on this matter (and we are shipping a large amount of Sierra Modules per month). The MC7710 happily accepts setting IPv6 PDP context and then fails on context activation with a generic “+CME Error” …

I can not give the command here as I am NDA bound, but someone from Sierra could (and should - Customer Relationship, anyone listening?)

I can’t understand why Sierra blocking IPV6 by default when option is available over AT command. I contacted my local distributor but it seems that my problem will not be resolved soon. They tell me that ipv6 is not blocked. So I’m little bit confused.