How to get Interface Identifier during IPv6 PDP activation

We are doing “ETSI TS 102 514” test. One of the standard requires the end point device to configure its link-local IPv6 Address based on the Interface Identifier during IPv6 context Activation. I did some research on this. And I know that after end point device send the “Activate PDP Context Request”, GGSN will generate an IPv6 address composed of the prefix allocated to the PDP context and an interface identifier generated by the GGSN. End point device will receive PDP Context Response which contains the interface identifier generated by GGSN.

Right now, our device fails in this standard because its IPv6 link local address is generated based on its MAC address, not the interface identifier generated by GGSN.

We are using Sierra Wireless Linux QMI SDK version: SLQS03.02.03
And Sierra Linux QMI driver (GobiNet) version: S2.26N2.38

My questions are:

  1. Whose responsibility is to create IPv6 link local address based on Interface Identifier during IPv6 context Activation? Application software? QMI driver?
  2. If it is application software, which Sierra Linux QMI SDK function should I use to get this Interface Identifier?

“SLQSStartStopDataSession” seems not return anything related to Interface Identifier.
I tried “SLQSWdsSwiPDPRuntimeSettings”, but I am not sure that does it return anything related to Interface Identifier. However calling SLQSWdsSwiPDPRuntimeSettings always fail with 1017 - Mandatory QMI TLV not provided.

Hi,

What unit are you using (MC7304, MC7455, etc)? Also the SDK you are using is really old now, there is a lot that has gone into it between your and the current versions, same for the SDK, I would strongly suggest you upgrade. It could well be that if you use more current versions the SLQSWdsSwiPDPRuntimeSettings API will return a valid response I presume you are trying to run the API after you have started a session rather than just against the default bearer?

I am not too aware of the low level messaging with regards context response and interface ID. Where did you find this from? Also when you are talking about interface are you talking about interface on the air side or on the host/USB side as the two are completely independent of each other. Either way the unit will just get an IP address from the network (be it IPv4 or v6) and use this, the MAC (used to calculate the local link address) is not used at all over LTE so again is independent.

an you also detail your test setup a little and what is saying that you are failing i.e. a CMW 500 test case?

Regards

Matt

We are using MC7304. Our device is tested by 7layer test lab. They are using CMW 500. And they tested on standard “ETSI TS 102 514”. See the link below, for the test standard in detail:
etsi.org/deliver/etsi_ts/102 … 20101p.pdf

We are failing in RQ_000_7003, RQ_000_7024, RQ_000_7030.

The Interface Identifier is something like an ID that is generated by GGSN. It is not something like the network interface.

Please check the link below(page 3) to see what happens during PDP activation.
cisco.com/c/en/us/td/docs/i … snipv6.pdf

In summary, the end point device will receive an PDP Context Accept response during PDP activation. And that PDP Context Accept response contains the interface identifier generated by GGSN.

RQ_000_7024 requires our device to create IPv6 link local address using the Interface Identifier generated by GGSN during PDP activation. For example, if the Interface Identifier contained inside PDP Context Accept response is 1, our device should create IPv6 link local address as: fe80::1. But right now, the IPv6 address is created based on MAC address.

My questions is who should extract Interface Identifier and create IPv6 link local address based on this identifier?

  1. Should Linux QMI driver does all these?
  2. Should Linux QMI SDK automatically does all these?
  3. Should our application software call SDK function to do this? If so, which SDK functions should I call to achieve this?

We know that SLQSWdsSwiPDPRuntimeSettings is for MC77xx modems. That’s why this function didn’t work.

I think there is a link confusion here. The MC7304, like all other LTE USB modems, has two network links which are half-bridged together. There is one link over the mobile network to the PGW/GGSN and one link over USB to the host. What you observe on the host side is only the USB link. The ETSI requirements deal with the mobile link.

Although there are to network links, there should be only one network interface associated with these two links? (e.g. eth3)

  1. How many network interfaces(e.g. eth3) are associated with these two network links?
  2. If there are 2 network interfaces, how can I view the network interfaces associated with each link? Especially the interface associated with ink over the mobile network to the PGW/GGSN.

The unit can create one PDN for each QMI interface there is and for which there is a corresponding eth interface, in the case of QMI this is two PDN’s, with the Sierra drivers a third is hidden as it is for internal/chipset use (it is shown with the open source drivers).

You can’t view the low level network interface details other than through layer 3 debugging tools from Qualcomm. It is handled by the LTE stack as there is no need for the application to see it.

Regards

Matt

Our issue is that we are failing in RQ_000_7003, RQ_000_7024, RQ_000_7030 of “ETSI TS 102 514” test.
For RQ_000_7024, it requires our device to create IPv6 link local address using the Interface Identifier generated by GGSN during PDP activation.

  1. Which network interface is associated with this setting? From the host side, we can see only one network interface (e.g. eth3) that correspond to cell modem.
  2. Who should set this IPv6 link local address based on this standard? QMI driver? SDK? Our application software?

Do you see two qcqmi interfaces then you should see two eth interfaces for the unit? If you don’t I suspect there is something wrong with your configuration.

When the unit starts a data session with the network it will get an IP address assigned, be it IPv4 or IPv6, after this the network interfaces will be populated with the information in the unit generally through a dhclient which means passing the IP address back and any other pertinent information such as DNS serrver, etc, that is it, the interface identifier is not part f the necessary information.

With regards the testing itself I have no idea why you are doing this in the first place, I have never heard of anyone doing this sort of testing, why are you doing it? What certification is it for? I am not aware of any testing that an application has to go through that would require the IP addresses it assigns itself on internal links s this is irrelevant to anything.

Regards

Matt

I only see one qcqmi interface (e.g. /dev/qcqmi0), and one network interface.
I should have one qcqmi interface for each cell modem? Or two for each cell modem?
The usb composition is set to 6.
at!udusbcomp?
!UDUSBCOMP: 6

Which udusbcomp should we use?

Hi,

I would use 7, pretty sure this is the default. Change it with the below commands.

at!entercnd="A710"
at!udusbcomp=?       //Just to show you the options
at!udusbcomp=7
at!reset

I have never really figured out the difference between QMI and RMNet, certainly not in terms of how they interact with a host system.

Regards

Matt

I am trying to test for RAW IP mode.
The GobiNet driver that I am using is version 2.38, and I compiled it as RAW_IP mode.
Does MC7304 or MC7354 support RAW IP mode? Do I need to do any AT command to change the modem from 802.3 mode to RAW_IP mode?

Thanks,
Shuo

Shuo,

MC74 is RAWIP by default, you have to compile the driver as such.

Regards

Matt

We are using MC73xx (7354 and 7304). Do we need any extra AT command to set the mode.
I saw the code of Sierra QMI driver. In “QMICTLSetDataFormatReq”, it sets the mode to “0x0002” if it is raw ip, otherwise it sets the mode to “0x0001” (ethernet mode).
Is the work done by Sierra QMI driver enough to set the mode of cell modem to RAW_IP? Or do I also need to issue any AT command to toggle the mode of cell modem?

Thanks,
Shuo

Shuo,

Ok MC74 is rawIP MC73 is not. Need to figure out if you can set MC73 to it but I do no think so.

Regards

Matt

Hi,

Correction over the air is raw IP for both MC73 and MC74, you just need to check the compile option in the driver and change accordingly as it is this that artificially adds the headers maing it ‘not’ raw IP.

Regards

Matt

This is not relevant for the subject (which is meaningless as explained earlier) or the OPs version of the driver (which is severely outdated). But for anyone else happening to read this thread: You do not need to recompile GobiNet for raw IP support anymore. Newer versions of the driver has a runtime switch. The compile time option simply changes the default setting of this switch. You can always override it at runtime by for example:

insmod GobiNet.ko iRAWIPEnable=1

This will make the MC73xx use raw IP mode.