I would like to know about the PerformNetworkScan function in the QMI library. We’re experiencing instances when the function timesout after 5 minutes of hogging the EM7565 processes.
This is as expected, since the timeout is 5 minutes but why are we getting a timeout? and why is it that if a scan starts to hang, not even a power cycle of the module can reset it. We see that after a power cycle, the function will continue to hang and give a timeout result. We’re unsure of how this issue is being triggered. Are there limits to how often this function can be called? Is there a function that kill the Network Scan and reset the device so that a fresh new scan can be initiated? Or a function that reduces the timeout period for the scan? What is the official way of setting up the device so that we do not run into such hanging of the module?
Just f.y.i. this is how we call the function.
ULONG resultcode; /* Result of SwiQmiSendnWait() */
BYTE *pOutParam; /* ptr to outbound param field */
BYTE *pReqBuf; /* Pointer to ougoing request buffer */
USHORT ParamLength; /* Ret'd length of the Param field */
/* Initialize the pointer to the outgoing request buffer pointer */
/* This also locks a mutex */
resultcode = qmgetreqbkp(&pReqBuf);
if (resultcode != eQCWWAN_ERR_NONE)
{
struct SwiQmiSendNoWaitResult result = { .error = resultcode };
return result;
}
/* Get a pointer to the start of the outbound QMI Parameter field */
pOutParam = amgetparamp( AMTYPEQMIREQUEST, pReqBuf );
/* Invoke the function which packs QMI message */
resultcode = PkQmiNasSlqsPerformNetworkScan( &ParamLength,
pOutParam );
if (resultcode != eQCWWAN_ERR_NONE)
{
qmrelreqbkp();
struct SwiQmiSendNoWaitResult result = { .error = resultcode };
return result;
}
struct SwiQmiSendNoWaitResult result = SwiQmiSendNoWait( pReqBuf,
eQMI_SVC_NAS,
ParamLength,
eQMI_TIMEOUT_120_S, /* 2 minutes*/
&ParamLength );
/* Unlock mutex */
qmrelreqbkp();
return result;
I have tried MBPL SDK sample application connection manager, I don’t see problem:
owner@ubuntu:~/QMI/MBPL/MBPL_SDK_R30_ENG6-lite.src/MBPL_SDK_R30_ENG6-lite.src/SampleApps/lite-qmi-connection-manager$ sudo ./bin/lite-qmi-connection-managerhostx86_64
lite-qmi-connection-manager v1.0.2211.0
Open transport "/dev/cdc-wdm0" on USB device in MBIM mode
Device interface: MBIM
Model: EM7565
Device Power Status: 0 - Online
HomeNetwork: SMC HK
Network Selection Preference: auto
SessionStatus (0:ipv4): Disconnected
SessionStatus (1:ipv6): Disconnected
SessionStatus (2:ipv4): Disconnected
SessionStatus (3:ipv6): Disconnected
SessionStatus (4:ipv4): Disconnected
SessionStatus (5:ipv6): Disconnected
SessionStatus (6:ipv4): Disconnected
SessionStatus (7:ipv6): Disconnected
Auto-ping check on connection: enabled
Routing table update on connection: enabled
Please select one of the following options or press 'q' to exit:
1. start a single-PDN data session
2. Start one connection of a multi-PDN data session
3. Stop one connection
4. Stop all active connections
5. Display all profiles on the device
6. Display one profile on the device
7. Create a profile on the device
8. Modify an existing profile on the device
9. Delete a profile from the device
10. Scan available networks
11. Lock PCI
12. Disable PCI locking
13. Get PCI locking
14. Enable QOS Event
15. Disable QOS Event
16. Request QOS Expanded
17. Get QOS Information
18. QOS Indication Register
19. Read QOS Data Statistics (SWIQOS)
20. Read QOS Extra APN Parameters (SWIQOS)
21. Get Packet Statistics
22. Get Current Channel Rate
23. Toggle pinging on connection
24. Toggle routing table update on connection
27. Enable QMAP
28. Disable QMAP
29. Enable/disable WDS event report indication
30. Enable/disable keep data session alive
(q)uit to exit:
10
jyi run_tests: NetworkScan may take a few minutes. Result will be displayed when available. Please wait...
Please select one of the following options or press 'q' to exit:
1. start a single-PDN data session
2. Start one connection of a multi-PDN data session
3. Stop one connection
4. Stop all active connections
5. Display all profiles on the device
6. Display one profile on the device
7. Create a profile on the device
8. Modify an existing profile on the device
9. Delete a profile from the device
10. Scan available networks
11. Lock PCI
12. Disable PCI locking
13. Get PCI locking
14. Enable QOS Event
15. Disable QOS Event
16. Request QOS Expanded
17. Get QOS Information
18. QOS Indication Register
19. Read QOS Data Statistics (SWIQOS)
20. Read QOS Extra APN Parameters (SWIQOS)
21. Get Packet Statistics
22. Get Current Channel Rate
23. Toggle pinging on connection
24. Toggle routing table update on connection
27. Enable QMAP
28. Disable QMAP
29. Enable/disable WDS event report indication
30. Enable/disable keep data session alive
(q)uit to exit:
unpack_nas_PerformNetworkScan ret: 0
Network Scan Result: 0
Network 0: SMC HK
MCC/MNC: 454/6
In Use: Current serving(1)
Forbidden: Not forbidden(2)
Preferred: Preferred(1)
Roaming: Home(1)
RAT: LTE(8)
MNC includes PCS digit: FALSE
Network 1: SMC HK
MCC/MNC: 454/6
In Use: Available(2)
Forbidden: Not forbidden(2)
Preferred: Preferred(1)
Roaming: Home(1)
RAT: UMTS(5)
MNC includes PCS digit: FALSE
Network 2: 3
MCC/MNC: 454/3
In Use: Available(2)
Forbidden: Not forbidden(2)
Preferred: Not preferred(2)
Roaming: Roam(2)
RAT: LTE(8)
MNC includes PCS digit: FALSE
Network 3: CSL
MCC/MNC: 454/19
In Use: Available(2)
Forbidden: Not forbidden(2)
Preferred: Not preferred(2)
Roaming: Roam(2)
RAT: UMTS(5)
MNC includes PCS digit: FALSE
Network 4: 3
MCC/MNC: 454/3
In Use: Available(2)
Forbidden: Not forbidden(2)
Preferred: Not preferred(2)
Roaming: Roam(2)
RAT: UMTS(5)
MNC includes PCS digit: FALSE
Network 5: CSL
MCC/MNC: 454/0
In Use: Available(2)
Forbidden: Forbidden(1)
Preferred: Not preferred(2)
Roaming: Roam(2)
RAT: UMTS(5)
MNC includes PCS digit: FALSE
Network 6: CMHK
MCC/MNC: 454/12
In Use: Available(2)
Forbidden: Forbidden(1)
Preferred: Not preferred(2)
Roaming: Roam(2)
RAT: LTE(8)
MNC includes PCS digit: FALSE
Network 7: CSL
MCC/MNC: 454/0
In Use: Available(2)
Forbidden: Forbidden(1)
Preferred: Not preferred(2)
Roaming: Roam(2)
RAT: LTE(8)
MNC includes PCS digit: FALSE
Network 8: CMHK
MCC/MNC: 454/13
In Use: Available(2)
Forbidden: Not forbidden(2)
Preferred: Not preferred(2)
Roaming: Roam(2)
RAT: UMTS(5)
MNC includes PCS digit: FALSE
Thanks for the reply. I’ll try to paint you the full picture.
We have been experiencing a situation where our USB2.0 Ethernet connection to the EM7565 goes ‘down’ from our Linux OS, Freescale IMX6.q controller. We’ve been trying resolve the issue from both SW and HW angles and we’ve come to the point where we are looking at the QMI library that we use for interfacing with the EM7565. The problem is that we don’t fully understand how to reproduce the failure (it’s happening at our clients location in Europe), and what we have for testing is to intentionally force the USB2.0 eth device to down or kill the process running ‘slqssdk’ process.
Our current QMI version
SLQS04.00.11
Side story is that we contracted a Software Solutions Company to do this integration of EM7565 to our device, the company folded and we were left with an edited QMI library that prevented us from upgrading to more recent versions. We plan on exploring how we can upgrade in the future, since our upcoming projects will require it. We also know that this company bought access to the source code and we have the code rather than binaries.
Now, you could say, it’s a modified library and you can’t help. Well, we reverted all the changes and modified our code to work with the ‘unedited’ QMI library, but we get the same result. The original modification was done to prevent the Perform Network Scan call from holding up our entire process. So now we just kick off the Scan as a thread and check its status.
We understand that we likely have an error with our code with the USB2.0 Ethernet device going down, but we would like to prevent the EM7565 from holding up the process for 5minutes when the issue arises.
You could try on your system:
Get connected to the EM7565
Have the EM7565 connect to a Cell service (3G/LTE take your pick).
Confirm that the EM7565 is communicating with your main Controller via you USB ethernet device.
Start a Perform Network Scan
Kill the slqssdk process or bring the eth device down.
Try to re-establish the connection (eth device up) to EM7565 and try to ‘GetStatus’ or interact with the EM7565. Our device becomes unresponsive for 5 minutes.
After 5 minutes from the eth device going down, we get a return value for Perform Network Scan that is timeout error 57348.
We have read that the EM7565 can process 3 tasks at a time but in this situation, it seems to block all processes. We cannot interact with the device until we get the timeout error.
Thanks for dealing with me here. We don’t have the latest SLQ SDK, and we will likely have to work a long time (weeks may be months) to have that even ready to test. We’ve never had to integrate the MBPL library before, and our code is not set up for that, it set up for using the slq source code.
We can’t interact with the EM7565 at all when we’re in the state of Perform Network Scan hanging. Would there be any possible way that we could kill the process or prevent the hang from happening? I appreciate the help.
Thanks. Just to make it clear what we need to try, we’re already killing the slqssdk to get the module into the hanging state. Are you suggesting we reboot the module and kill the slqssdk again?