Unable to get data session on EM7565 using SLQS04.00.11


#1

Hello,

I am not able to get data session on EM7565 using sierra Linux QMI SDK version 04.00.11 (SLQS04.00.11).
However, I can get data session on EM7565 using at!scact=1,1 AT command

Does SLQS04.00.11 support EM7565?

EM7565 firmware version:
Manufacturer: Sierra Wireless, Incorporated
Model: EM7565
Revision: SWI9X50C_01.00.02.00 6ff48a jenkins 2017/09/29 05:54:26
MEID: 35926008010494
IMEI: 359260080104943
IMEI SV: 2
FSN: UF742486640306
+GCAP: +CGSM

at!priid?
PRI Part Number: 9907344
Revision: 001.001
Customer: Generic-M2M

Carrier PRI: 9999999_9907259_SWI9X50C_01.00.02.00_00_GENERIC_001.012_000

Using AT & T SIM card, APN setting is:
+CGDCONT: 1,“IP”,“broadband”,“0.0.0.0”,0,0,0,0

I am using Sierra Linux QMI driver version S2.31N2.50
GobiSierial - 2.31
GobiNet - 2.50 and compiled as RAWIP mode
/dev/qcqmi0 get created correctly.

dmesg shows that GobiNet works fine:
[ 12.159077] GobiNet: 2018-02-28/SWI_2.50
[ 12.185253] GobiNet 1-2:1.8 eth0: register ‘GobiNet’ at usb-0000:00:15.0-2, GobiNet Ethernet Device, d2:fe:b4:a7:3f:53
[ 12.193926] USB Speed : USB 2.0
[ 12.196644] usbcore: registered new interface driver GobiNet
[ 12.215830] usbcore: registered new interface driver GobiSerial
[ 12.219053] usbserial: USB Serial support registered for GobiSerial
[ 12.220423] GobiSerial 1-2:1.0: GobiSerial converter detected
[ 12.227034] usb 1-2: GobiSerial converter now attached to ttyUSB0
[ 12.230230] GobiSerial 1-2:1.2: GobiSerial converter detected
[ 12.239674] usb 1-2: GobiSerial converter now attached to ttyUSB1
[ 12.242063] GobiSerial 1-2:1.3: GobiSerial converter detected
[ 12.248148] usb 1-2: GobiSerial converter now attached to ttyUSB2
[ 12.248222] GobiSerial: 2017-12-22/SWI_2.31:GobiSerial
[ 17.380558] GobiNet 1-2:1.8 enp0s21f0u2i8: renamed from eth0
[ 17.983052] creating qcqmi0
[ 17.991379] RawIP mode

When I use at!scact=1,1 command, I can get data session and IP address using dhclient,
and opersatet and carrier shows network interface is up:
cat /sys/bus/usb/devices/1-2/1-2:1.8/net/enp0s21f0u2i8/operstate
up
cat /sys/bus/usb/devices/1-2/1-2:1.8/net/enp0s21f0u2i8/carrier
1

However, when I use SLQS04.00.11 library functions, I cannot get data session.
Here is the log:

Cell modem scan and initialize success:
2018-04-11T17:28:09.862784+00:00 hyperlinc /sbin/cellqmid: ******* Cell modem daemon started. Version=[243.20180411.165237] *******
2018-04-11T17:28:09.889408+00:00 hyperlinc SWI0 SDK Process: SU:Process Started, version: SLQS04.00.11
2018-04-11T17:28:09.890245+00:00 hyperlinc SWI0 SDK Process: SU:7 -> task started
2018-04-11T17:28:09.890948+00:00 hyperlinc SWI0 SDK Process: QM:Task started
2018-04-11T17:28:09.892706+00:00 hyperlinc SWI0 SDK Process: SU:12 -> task started
2018-04-11T17:28:09.893663+00:00 hyperlinc SWI0 SDK Process: UDIAG:DS Shell launched
2018-04-11T17:28:09.894581+00:00 hyperlinc SWI0 SDK Process: UDIAG:DS Shell launched
2018-04-11T17:28:09.897715+00:00 hyperlinc SWI0 SDK Process:
2018-04-11T17:28:09.900711+00:00 hyperlinc SWI0 SDK Process:
2018-04-11T17:28:09.906351+00:00 hyperlinc SWI0 SDK Process: SU:17 -> task started
2018-04-11T17:28:09.914383+00:00 hyperlinc SWI0 SDK Process: >>MM sn or usb [0] 1-2
2018-04-11T17:28:09.915823+00:00 hyperlinc SWI0 SDK Process: ttyUSB0 device found on USB Interface 0
2018-04-11T17:28:09.916624+00:00 hyperlinc SWI0 SDK Process: ttyUSB0 device found on USB Interface 0
2018-04-11T17:28:09.917324+00:00 hyperlinc SWI0 SDK Process: ttyUSB1 device found on USB Interface 2
2018-04-11T17:28:09.917998+00:00 hyperlinc SWI0 SDK Process: ttyUSB1 device found on USB Interface 2
2018-04-11T17:28:09.918686+00:00 hyperlinc SWI0 SDK Process: ttyUSB2 device found on USB Interface 3
2018-04-11T17:28:09.919400+00:00 hyperlinc SWI0 SDK Process: ttyUSB2 device found on USB Interface 3
2018-04-11T17:28:09.920033+00:00 hyperlinc SWI0 SDK Process: swi_ossdkusbscan/1518: 3 tty interfaces successfully scanned
2018-04-11T17:28:09.920778+00:00 hyperlinc SWI0 SDK Process: qcqmi0 device found on USB Interface 8
2018-04-11T17:28:09.921510+00:00 hyperlinc SWI0 SDK Process: qcqmi0 device found on USB Interface 8
2018-04-11T17:28:09.922034+00:00 hyperlinc SWI0 SDK Process: swi_ossdkusbscan/1544: 1 qmi interfaces successfully scanned
2018-04-11T17:28:09.922625+00:00 hyperlinc SWI0 SDK Process: swi_ossdkusbscan/1556: 4/4 interfaces successfully scanned
2018-04-11T17:28:09.923275+00:00 hyperlinc SWI0 SDK Process: swi_ossdkusbscan: drivers ready!
2018-04-11T17:28:09.923702+00:00 hyperlinc SWI0 SDK Process: QM:qm_map_instances_to_device_files: USEP_QMI: 0 USEP_QMI2: -1 USEP_QMI3: -1
2018-04-11T17:28:09.924053+00:00 hyperlinc SWI0 SDK Process: QM:qm_map_instances_to_device_files: USEP_QMI4: -1 USEP_QMI5: -1 USEP_QMI6: -1
2018-04-11T17:28:09.924486+00:00 hyperlinc SWI0 SDK Process: QM:qm_map_instances_to_device_files: USEP_QMI7: -1 USEP_QMI8: -1
2018-04-11T17:28:09.924857+00:00 hyperlinc SWI0 SDK Process: QM:qm_ds_handle_app_dev_ready: devstate 1
2018-04-11T17:28:09.925238+00:00 hyperlinc SWI0 SDK Process: QM-DCS:SDK<-DCS Notif: ch/Msgid/Msglen/Svctype: 1/0014/0/248
2018-04-11T17:28:09.925811+00:00 hyperlinc SWI0 SDK Process: QM-DCS:SDK<-DCS Notif: ch/Msgid/Msglen/Svctype: 3/0014/0/248
2018-04-11T17:28:09.926338+00:00 hyperlinc SWI0 SDK Process: QM-DCS:SDK<-DCS Notif: ch/Msgid/Msglen/Svctype: 5/0014/0/248
2018-04-11T17:28:10.867286+00:00 hyperlinc /sbin/cellqmid: SLQS_init: APP<->SDK IPC init successful

But start data session fails(using SLQSStartStopDataSession SDK function):
2018-04-11T17:28:11.391743+00:00 hyperlinc /sbin/cellqmid: Will Establish Connection on Auto Profile
2018-04-11T17:28:11.392649+00:00 hyperlinc /sbin/cellqmid: Establishing Connection…
2018-04-11T17:28:11.393586+00:00 hyperlinc /sbin/cellqmid: SLQSStartStopDataSession returned 57353(0xe009), rcv4:0(0x0), rcv6:0(0x0)
2018-04-11T17:28:11.394088+00:00 hyperlinc /sbin/cellqmid: session id: 0, v4 session id: 0, v6 session id: 0, failureReason: 0, failureReasonv4: 0, failureReasonv6: 0, verbFailReasonType: 0, verbFailReason: 0
2018-04-11T17:28:21.400897+00:00 hyperlinc SWI0 SDK Process: QM:qmqmireq/1523: Request: QMI Instance 0
2018-04-11T17:28:21.402012+00:00 hyperlinc SWI0 SDK Process: QM:SDK->Mdm: request received : ipcch/svctype/xactionlen/clientnum: 0/0003/4/2
2018-04-11T17:28:21.402775+00:00 hyperlinc SWI0 SDK Process: QM:SDK->Mdm: request validated : ipcch/svctype/xactionlen/clientnum: 0/0003/4/2
2018-04-11T17:28:21.403566+00:00 hyperlinc SWI0 SDK Process: QM:qmqmireq/1637: WDS Request: Active Client 2, WDS Client 0
2018-04-11T17:28:21.438289+00:00 hyperlinc SWI0 SDK Process: USB read: bytes2read = 93, read 93 bytes
2018-04-11T17:28:21.439295+00:00 hyperlinc SWI0 SDK Process: QM:SDK<-Mdm Resp: ch/Msgid/Msglen/client: 0/0024/90/2
2018-04-11T17:28:21.440065+00:00 hyperlinc SWI0 SDK Process: QM:qmqmireq/1523: Request: QMI Instance 0
2018-04-11T17:28:21.440892+00:00 hyperlinc SWI0 SDK Process: QM:SDK->Mdm: request received : ipcch/svctype/xactionlen/clientnum: 0/0003/9/2
2018-04-11T17:28:21.441651+00:00 hyperlinc SWI0 SDK Process: QM:SDK->Mdm: request validated : ipcch/svctype/xactionlen/clientnum: 0/0003/9/2
2018-04-11T17:28:21.442371+00:00 hyperlinc SWI0 SDK Process: QM:qmqmireq/1637: WDS Request: Active Client 2, WDS Client 0
2018-04-11T17:28:21.501374+00:00 hyperlinc SWI0 SDK Process: USB read: bytes2read = 35, read 35 bytes
2018-04-11T17:28:21.502287+00:00 hyperlinc SWI0 SDK Process: QM:SDK<-Mdm Resp: ch/Msgid/Msglen/client: 0/0020/32/2
2018-04-11T17:28:21.503034+00:00 hyperlinc /sbin/cellqmid: Determine Signal Interface
2018-04-11T17:28:21.503805+00:00 hyperlinc /sbin/cellqmid: Radio Interface is LTE
2018-04-11T17:28:21.504403+00:00 hyperlinc /sbin/cellqmid: Will Establish Connection on Fixed Profile ID: [1] [1]
2018-04-11T17:28:21.505005+00:00 hyperlinc /sbin/cellqmid: Establishing Connection…
2018-04-11T17:28:21.505653+00:00 hyperlinc /sbin/cellqmid: SLQSStartStopDataSession returned 57353(0xe009), rcv4:0(0x0), rcv6:0(0x0)
2018-04-11T17:28:21.506343+00:00 hyperlinc /sbin/cellqmid: session id: 0, v4 session id: 0, v6 session id: 0, failureReason: 0, failureReasonv4: 0, failureReasonv6: 0, verbFailReasonType: 0, verbFailReason: 0
2018-04-11T17:28:31.511891+00:00 hyperlinc SWI0 SDK Process: QM:qmqmireq/1523: Request: QMI Instance 0
2018-04-11T17:28:31.512945+00:00 hyperlinc SWI0 SDK Process: QM:SDK->Mdm: request received : ipcch/svctype/xactionlen/clientnum: 0/0003/4/2
2018-04-11T17:28:31.513718+00:00 hyperlinc SWI0 SDK Process: QM:SDK->Mdm: request validated : ipcch/svctype/xactionlen/clientnum: 0/0003/4/2
2018-04-11T17:28:31.514400+00:00 hyperlinc SWI0 SDK Process: QM:qmqmireq/1637: WDS Request: Active Client 2, WDS Client 0
2018-04-11T17:28:31.516780+00:00 hyperlinc SWI0 SDK Process: USB read: bytes2read = 93, read 93 bytes
2018-04-11T17:28:31.517783+00:00 hyperlinc SWI0 SDK Process: QM:SDK<-Mdm Resp: ch/Msgid/Msglen/client: 0/0024/90/2
2018-04-11T17:28:31.518451+00:00 hyperlinc SWI0 SDK Process: QM:qmqmireq/1523: Request: QMI Instance 0
2018-04-11T17:28:31.519080+00:00 hyperlinc SWI0 SDK Process: QM:SDK->Mdm: request received : ipcch/svctype/xactionlen/clientnum: 0/0003/9/2
2018-04-11T17:28:31.519733+00:00 hyperlinc SWI0 SDK Process: QM:SDK->Mdm: request validated : ipcch/svctype/xactionlen/clientnum: 0/0003/9/2
2018-04-11T17:28:31.520378+00:00 hyperlinc SWI0 SDK Process: QM:qmqmireq/1637: WDS Request: Active Client 2, WDS Client 0
2018-04-11T17:28:31.582278+00:00 hyperlinc SWI0 SDK Process: USB read: bytes2read = 35, read 35 bytes
2018-04-11T17:28:31.583323+00:00 hyperlinc SWI0 SDK Process: QM:SDK<-Mdm Resp: ch/Msgid/Msglen/client: 0/0020/32/2

SLQSStartStopDataSession always return 0xe009 (0xE009 - IPV4 and IPV6 is down). Failure reason is 0.
You can see that in my code I tried both auto-profile and fixed profile at 1 and 1.

The input parameter I give in SLQSStartStopDataSession are:
pTechnology = 1 if LTE / UMTS /GSM
pTechnology = 2 if CDMA
ipfamily = 0x04 (I only need IPv4)

When doing auto-profile:
pProfileId3GPP = NULL
pProfileId3GPP2 = NULL

When doing fixed profile:
pProfileId3GPP = 1
pProfileId3GPP2 = 1

But they both fail.
Do I have to do something special for profile setting, or modem setup?

Thanks,
Shuo


#2

Shuo,

From memory there were some initial problems with the SDK and the EM7565 that had to be worked out around the QMAP interfacing, I would recommend starting with the latest which is 4.00.13, available at the link below.

https://source.sierrawireless.com/resources/airprime/software/linux-qmi-sdk-software-latest/

Regards

Matt


#3

Hi Matt,

Thanks for your reply.
But actually currently I am not able to use SDK version 4.00.13.
I think SDK header file is missing “qmap.h”.
I got the same problem on version 4.00.12 as well. That is why I have to use version 4.00.11.
When I compiled my code using SLQS4.00.13, it gave an error of:

“…/slqs/api/dcs/inc/qaGobiApiDcs.h:21:18: fatal error: qmap.h: No such file or directory”
In qaGobiApiDcs.h at line 21, it has #include “qmap.h”
However, I can’t find any qmap.h file in SLQS directory.

I posted this issue on forum as well, but has not got reply yet.

Regards,
Shuo


#4

Shuo,

I have just started a data session (IPv4 on LTE, using the EE network in the UK) and closed it down successfully running release 8 on my unit (1.05.01 firmware) using the connection manager. Can you confirm that you are able to run the sample application as well? Do you want me to post the log files?

Regards

Matt


#5

Hi Matt,

Thanks again for your help. I can confirm that connection manager is able to get a LTE data session.

I think I figured out what was wrong.
Previously, I had “-D ULONG_AS_EIGHT_BYTES_ON_64BIT” in my Makefile.
After I removed this and re-compiled my code, now my daemon is able to get a data session using SLQS4.00.11.

The reason why I added “-D ULONG_AS_EIGHT_BYTES_ON_64BIT” in my Makefile:
In SwiDataTypes.h, it has:
#ifdef ULONG_AS_EIGHT_BYTES_ON_64BIT // on 32bit, long & int has same length
typedef unsigned long ULONG;
#else
typedef unsigned int ULONG;
#endif

Our platform is x86_64 which is for sure 64bit for unsigned long.
It seems that the SDK binary for x86_64 is not compiled has “-D ULONG_AS_EIGHT_BYTES_ON_64BIT” defined. So it has inconsistent ULONG size on my code side and SDK side.

The SDK library and binary I used is from build/bin/hostx86_64 and build/lib/hostx86_64.

Should we define ULONG as unsigned long which is 64 bits on x86_64? I mean for SDK binary for x86_64 platform, should it be compiled with “-D ULONG_AS_EIGHT_BYTES_ON_64BIT” defined?

If so, can I get a compiled SDK binary that has ULONG defined as 64 bit?

Regards,
Shuo


#6

Shuo,

Not sure about the above but if you want an SDK compiled using a specific toolchain or options then you need to go through the official support channels (either to your FAE if direct or distributor depending on who you have bought the unit from) so that they can do this for you.

Regards

Matt