EM7455: Link down (in QMIWDSEventResp) on performing ping test

Embedded wireless modules
#1

Why does the QMI link state becomes “down” on performing a ping test (even in idle case), even when the data connection is up?

I have forced the link state to “true” in QMIWDSEventResp function of the QMI.c. Now it does not receive link failure and the ping test works. This is not a right solution as it will never detect real link failure.

Why does the QMIWDSEventResp API incorrectly reads the link state down? How do I fix this?

6,1729,6618560000,-;GobiNet::GobiNetDriverRxFixup(0)
6,1730,6618560000,-;GobiNet::GobiNetDriverRxFixup(0) RX From Device:
6,1731,6618560000,-;GobiNet::PrintHex(0) : 45 00 00 54 00 00 00 00 71 01 0B 32 08 08 08 08 64 62 CA 05 00 00 91 6F FB 0A 00 42 F4 B8 7E 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6,1732,6618560000,-;GobiNet::PrintHex(0) : 32 74 20 4C 53 08 00 00 00 00 00 00 08 00 45 00 00 54 00 00 00 00 71 01 0B 32 08 08 08 08 64 62 CA 05 00 00 91 6F FB 0A 00 42 F4 B8 7E 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6,1733,6618780000,-;GobiNet::ProcessReadWorkFunction(953) ResubmitIntURB
6,1734,6618780000,-;GobiNet::ReadCallback(953) Read 77 bytes
6,1735,6618780000,-;GobiNet::PrintHex(953) : 01 4C 00 80 01 23 04 4B 00 01 00 40 00 1A 08 00 38 16 00 00 00 00 00 00 19 08 00 74 16 00 00 00 00 00 00 15 04 00 FF FF FF FF 14 04 00 FF FF FF FF 13 04 00 FF FF FF FF 12 04 00 FF FF FF FF 11 04 00 44 00 00 00 10 04 00 46 00 00 00
6,1736,6618780000,-;GobiNet::QMIWDSCallback(953) Net device link is connected
6,1737,6618780000,-;GobiNet::QMIWDSCallback(953) clientID :0x2301
6,1738,6619530000,-;GobiNet::GobiNetDriverTxFixup(2811)
6,1739,6619530000,-;GobiNet::GobiNetDriverTxFixup(2811) For sending to device modified:
6,1740,6619530000,-;GobiNet::PrintHex(2811) : 45 00 00 54 00 00 40 00 40 01 FC 31 64 62 CA 05 08 08 08 08 08 00 DA 04 FB 0A 00 43 94 22 8E 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6,1741,6619590000,-;GobiNet::GobiNetDriverRxFixup(0)
6,1742,6619590000,-;GobiNet::GobiNetDriverRxFixup(0) RX From Device:
6,1743,6619590000,-;GobiNet::PrintHex(0) : 45 00 00 54 00 00 00 00 71 01 0B 32 08 08 08 08 64 62 CA 05 00 00 E2 04 FB 0A 00 43 94 22 8E 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6,1744,6619590000,-;GobiNet::PrintHex(0) : 32 74 20 4C 53 08 00 00 00 00 00 00 08 00 45 00 00 54 00 00 00 00 71 01 0B 32 08 08 08 08 64 62 CA 05 00 00 E2 04 FB 0A 00 43 94 22 8E 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6,1745,6619790000,-;GobiNet::ProcessReadWorkFunction(953) ResubmitIntURB
6,1746,6619790000,-;GobiNet::ReadCallback(953) Read 77 bytes
6,1747,6619790000,-;GobiNet::PrintHex(953) : 01 4C 00 80 01 23 04 4C 00 01 00 40 00 1A 08 00 8C 16 00 00 00 00 00 00 19 08 00 C8 16 00 00 00 00 00 00 15 04 00 FF FF FF FF 14 04 00 FF FF FF FF 13 04 00 FF FF FF FF 12 04 00 FF FF FF FF 11 04 00 45 00 00 00 10 04 00 47 00 00 00
6,1748,6619790000,-;GobiNet::QMIWDSCallback(953) Net device link is connected
6,1749,6619790000,-;GobiNet::QMIWDSCallback(953) clientID :0x2301
6,1750,6620540000,-;GobiNet::GobiNetDriverTxFixup(2811)
6,1751,6620540000,-;GobiNet::GobiNetDriverTxFixup(2811) For sending to device modified:
6,1752,6620540000,-;GobiNet::PrintHex(2811) : 45 00 00 54 00 00 40 00 40 01 FC 31 64 62 CA 05 08 08 08 08 08 00 36 9A FB 0A 00 44 28 8C 9D 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6,1753,6620610000,-;GobiNet::GobiNetDriverRxFixup(0)
6,1754,6620610000,-;GobiNet::GobiNetDriverRxFixup(0) RX From Device:
6,1755,6620610000,-;GobiNet::PrintHex(0) : 45 00 00 54 00 00 00 00 71 01 0B 32 08 08 08 08 64 62 CA 05 00 00 3E 9A FB 0A 00 44 28 8C 9D 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6,1756,6620610000,-;GobiNet::PrintHex(0) : 32 74 20 4C 53 08 00 00 00 00 00 00 08 00 45 00 00 54 00 00 00 00 71 01 0B 32 08 08 08 08 64 62 CA 05 00 00 3E 9A FB 0A 00 44 28 8C 9D 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6,1757,6620670000,-;GobiNet::ProcessReadWorkFunction(953) ResubmitIntURB
6,1758,6620670000,-;GobiNet::ReadCallback(953) Read 34 bytes
6,1759,6620670000,-;GobiNet::PrintHex(953) : 01 21 00 80 01 24 04 0A 00 22 00 15 00 01 02 00 01 00 10 02 00 02 00 11 04 00 03 00 D0 07 12 01 00 06
6,1760,6620670000,-;GobiNet::QMIWDSCallback(953) Net device link is disconnected
6,1761,6620670000,-;GobiNet::QMIWDSCallback(953) clientID :0x2401
6,1762,6620780000,-;GobiNet::ProcessReadWorkFunction(953) ResubmitIntURB
6,1763,6620780000,-;GobiNet::ReadCallback(953) Read 77 bytes
6,1764,6620780000,-;GobiNet::PrintHex(953) : 01 4C 00 80 01 23 04 4D 00 01 00 40 00 1A 08 00 E0 16 00 00 00 00 00 00 19 08 00 1C 17 00 00 00 00 00 00 15 04 00 FF FF FF FF 14 04 00 FF FF FF FF 13 04 00 FF FF FF FF 12 04 00 FF FF FF FF 11 04 00 46 00 00 00 10 04 00 48 00 00 00
6,1765,6620780000,-;GobiNet::QMIWDSCallback(953) Net device link is disconnected
6,1766,6620780000,-;GobiNet::QMIWDSCallback(953) clientID :0x2301

at!gstatus?
!GSTATUS:
Current Time: 8827 Temperature: 35
Reset Counter: 7 Mode: ONLINE
System mode: LTE PS state: Attached
LTE band: B4 LTE bw: 20 MHz
LTE Rx chan: 2100 LTE Tx chan: 20100
LTE CA state: NOT ASSIGNED
EMM state: Registered Normal Service
RRC state: RRC Idle
IMS reg state: Full Srv IMS mode: Normal

PCC RxM RSSI: -73 RSRP (dBm): -100
PCC RxD RSSI: -73 RSRP (dBm): -100
Tx Power: – TAC: 2F02 (12034)
RSRQ (dB): -6.9 Cell ID: 054C8E20 (88903200)
SINR (dB): 12.2

at+cgcontrdp
+CGCONTRDP: 1,5,ims,38.0.16.18.17.20.168.234.197.177.237.35.176.91.153.140, 254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.1, 32.1.72.136.0.101.255.0.6.46.0.13.0.0.0.0, 32.1.72.136.0.100.255.0.6.32.0.13.0.0.0.0,32.1.72.136.0.5.113.58.0.224.1.4.0.0.0.120,32.1.72.136.0.5.113.58.0.224.1.4.0.0.1.32
+CGCONTRDP: 3,6,vzwinternet,100.98.202.5,38.0.16.18.177.36.252.13.0.0.0.42.35.31.98.1,0.255.101.0 254.128.0.0.0.0.0.0.0.0.0.42.35.31.98.64,198.224.171.135 32.1.72.136.0.101.255.0.6.46.0.13.0.0.0.0,198.224.169.135 32.1.72.136.0.100.255.0.6.32.0.13.0.0.0.0

OK
at!scact?
!SCACT: 1,0
!SCACT: 2,0
!SCACT: 3,1
!SCACT: 4,0
!SCACT: 5,0
!SCACT: 6,0

OK
at+cpin?
+CPIN: READY

OK

#2

Hi akn ,

Which firmware version are you using? If you are not on the latest firmware, please download the latest one and retry.

Why did you modify the source driver’s QMI.c file? Please use the latest official driver from Sierra.
Could you please share the entire commands and log file as attachments?

You can get them here AirPrime EM/MC74xx Approved FW Packages
Linux QMI Driver S2.42N2.64

#3

I have upgraded the Gobi driver to Linux QMI Driver S2.42N2.64, but this issue still exists.

My module has the latest Verizon fw PRI FF GOOD 0 0 0 002.079_001 02.33.03.00_VERIZON fw.

I forced the link status to true to check if the LTE module can maintain the link and it starts maintaining the link up but further it never returns link down, even if the data connection is really down. So this is not a right solution.

pktStatusRead[0] should always be 0x02, if the link is active. This is not always true in my case.
Sometimes it starts returning 0x01 and never returns 0x02, until I restart the packet-data+network (udhcpc client) connection.

disconnected case (I end up at this point)
4,577,31110000,-;QMIWDSEventResp GetQMIMessageID result = 0x22
4,578,31110000,-;GetTLV result 0x1
4,579,31110000,-;pktStatusRead 0x1 0x0
4,580,31180000,-;Link state is disconnected

connected case
4,708,80760000,-;QMIWDSEventResp GetQMIMessageID result = 0x22
4,709,80760000,-;GetTLV result 0x2
4,710,80760000,-;pktStatusRead 0x2 0x0
4,711,80760000,-;Net device link is connected

source reference:
QMI.c->QMIWDSEventResp():nearby line 1500

  result = GetTLV( pBuffer, buffSize, 0x01, &pktStatusRead[0], 2 );
  // 1 or 2 bytes may be received
  if (result >= 1)
  {
     if (pktStatusRead[0] == 0x02)
     {
        *pbLinkState = true;
     }
     else
     {
        *pbLinkState = false; // forced it to TRUE for test
     }
  }

backtrace:
(GetTLV+0x0/0x160) from QMIWDSEventResp (linux/drivers/net/usb/QMI.c:1505)
4,104122,281240000,-; r8:00000000 r7:de413df8 r6:00000000 r5:00000000 r4:00000000
(QMIWDSEventResp+0x0/0x400) from QMIWDSCallback (linux/drivers/net/usb/QMIDevice.c:7003)
(QMIWDSCallback+0x0/0x77c) from NotifyAndPopNotifyList (linux/drivers/net/usb/QMIDevice.c:3524)
(NotifyAndPopNotifyList+0x0/0x3e8) from ReadCallback (linux/drivers/net/usb/QMIDevice.c:848 linux/drivers/net/usb/QMIDevice.c:878 linux/drivers/net/usb/QMIDevice.c:1420)
(ReadCallback+0x0/0x16b0) from ProcessReadWorkFunction (linux/drivers/net/usb/QMIDevice.c:10085)
(ProcessReadWorkFunction+0x0/0x110) from process_one_work (linux/arch/arm/include/asm/thread_info.h:97 linux/kernel/workqueue.c:2098)
4,104128,281240000,-; r5:c0c51500 r4:de36f6c0
(process_one_work+0x0/0x470) from worker_thread (linux/include/linux/list.h:188 linux/kernel/workqueue.c:2211)
(worker_thread+0x0/0x5b0) from kthread (linux/kernel/kthread.c:121)
(kthread+0x0/0x9c) from do_exit (linux/kernel/exit.c:906)
4,104132,281240000,-; r6:c003b6fc r5:c0055364 r4:de04dea0

Why do I get incorrect value in pktStatusRead[0]?

#4

The following commands were used
at!entercnd=“A710”
at+cmee=2
at!usbcomp=1,1,10d
AT!SCACT=1,3

if at!scact? returns connection active then the application starts the dhcpc client on the cellular interface.

The application is continuously checking for the status of the data connection using at!scact?. (It does not change in my case even if pktStatusRead[0] == 0x01)

#5

Hi @akn

It can be a limitation of the current driver module.
Please contact your distributor or submit “Contact Us” on Sierrawireless.com for technical support in this case.