Description:
When devices with Quectel LTE modules loose connectivity (e.g. due to weak LTE cell connectivity) we observe that reconnects fail because an uqmi process (triggered by netifd/qmi.sh) stucks. This can be tracked down to some kind of "stall" mode of Quectel LTE modems as already described here: Requests issued by uqmi hang forever and therefore connects/reconnects triggered by netifd via qmi.sh will fail and we have no LTE connection anymore.
Solution:
Since 2020 uqmi has an timeout parameter to handle this problem, see commit 0a19b5b77140465c29e2afa7d611fe93abc9672f. Unfortunately qmi.sh does not make use of this parameter. As described in the above patch, qmi.sh should invoke an early dummy access to "unlock" the modem.
This can be simply archieved by inserting the following line in qmi.sh as line 85
Description: When devices with Quectel LTE modules loose connectivity (e.g. due to weak LTE cell connectivity) we observe that reconnects fail because an uqmi process (triggered by netifd/qmi.sh) stucks. This can be tracked down to some kind of "stall" mode of Quectel LTE modems as already described here: Requests issued by uqmi hang forever and therefore connects/reconnects triggered by netifd via qmi.sh will fail and we have no LTE connection anymore.
Solution: Since 2020 uqmi has an timeout parameter to handle this problem, see commit 0a19b5b77140465c29e2afa7d611fe93abc9672f. Unfortunately qmi.sh does not make use of this parameter. As described in the above patch, qmi.sh should invoke an early dummy access to "unlock" the modem.
This can be simply archieved by inserting the following line in qmi.sh as line 85
Another solution might be to add the "-t" parameter to each uqmi command in qmi.sh.