Uqmi always reconnect/activate internet connection

I recently installed Openwrt on a "Zyxel LTE5398-M904"

I apologize in advance if the question might be trivial

I ask if anyone might have suggestions and/or opinions that would allow better management

I created a script that runs every minute it checks the connection
with the command:

uqmi -d /dev/cdc-wdm0 --get-data-status | grep "disconnected"

I would like to know how reliable such a way should be to detect any disconnections

Below is the common information that is usually requested:

ubus call system board

{
        "kernel": "5.15.147",
        "hostname": "LTE5398-M904",
        "system": "MediaTek MT7621 ver:1 eco:3",
        "model": "ZyXEL LTE5398-M904",
        "board_name": "zyxel,lte5398-m904",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "revision": "r24936-60ffcfdabc",
                "target": "ramips/mt7621",
                "description": "OpenWrt SNAPSHOT r24936-60ffcfdabc"
        }
}

cat /etc/config/network

config interface 'wan'
        option device '/dev/cdc-wdm0'
        option proto 'qmi'
        option pdptype 'ipv4'
        option auth 'none'
        option apn 'iliad'

cat /etc/crontabs/root

#min hour day month day-week command
#0-59 0-23 1-31 1-12 0-6(0=Sunday) exec
* * * * * /root/wan_connect

cat /root/wan_connect

#!/bin/sh
LTEPROTO=$(cat /etc/config/network | grep "proto 'qmi'" | wc -l)
if [ ${LTEPROTO} -eq "1" ]; then

LTESTATUS=$(uqmi -d /dev/cdc-wdm0 --get-data-status | grep "\"connected\"" | wc -l)

if [ ${LTESTATUS} -eq "0" ]; then
logger "exec /root/wan_connect: lost connection detected"
logger "exec /root/wan_connect: exec ifdown wan; ifup wan"
ifdown wan
ifup wan
fi
fi

ps: the script deliberately does not reboot the interface in order to evaluate the stability of the system, as I realized that it could create "race conditions" with the automatic reconnection functionality pre-implemented by the qmi

I have the same router, and I have a similar script. My ISP tends to disconnect me every 24 hours, but my internet connection has been "stable" for weeks.

1 Like

Yes, I had read both your posts and those about the automatic reconnection.

but I don't find an efficient solution (I also tried watchcat but it's based on ping) to some events I have:

my script log this:

Mon Feb  5 02:59:00 CET 2024
uqmi -d /dev/cdc-wdm0 --get-current-settings
"Out of call"
uqmi -d /dev/cdc-wdm0 --get-signal-info
{
        "type": "lte",
        "rssi": -73,
        "rsrq": -9,
        "rsrp": -105,
        "snr": 8.600000
}
uqmi -d /dev/cdc-wdm0 --get-serving-system
{
        "registration": "registered",
        "plmn_mcc": 222,
        "plmn_mnc": 50,
        "plmn_description": "Iv:L\u0006",
        "roaming": false
}
uqmi -d /dev/cdc-wdm0 --get-system-info
{
        "wcdma": {
                "service_status": "none",
                "true_service_status": "none",
                "preferred_data_path": false
        },
        "lte": {
                "service_status": "available",
                "true_service_status": "available",
                "preferred_data_path": false,
                "domain": "cs-ps",
                "service": "cs-ps",
                "roaming_status": "off",
                "forbidden": false,
                "mcc": "222",
                "mnc": "50",
                "tracking_area_code": 23076,
                "enodeb_id": 230131,
                "cell_id": 0,
                "voice_support": true,
                "ims_voice_support": false,
                "cell_access_status": "all calls",
                "registration_restriction": 0,
                "registration_domain": 0
        }
}
ifconfig wwan0
wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.77.97.237  P-t-P:10.77.97.237  Mask:255.255.255.252
          inet6 addr: fe80::6c91:1274:34e3:53e5/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:485406 errors:0 dropped:0 overruns:0 frame:0
          TX packets:270017 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:536787481 (511.9 MiB)  TX bytes:60806406 (57.9 MiB)

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.77.97.238    0.0.0.0         UG    0      0        0 wwan0
10.77.97.236    0.0.0.0         255.255.255.252 U     0      0        0 wwan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan

logread log this:

Mon Feb  5 02:01:16 2024 daemon.notice netifd: wan_4 (3303): udhcpc: sending renew to server 10.77.97.238
Mon Feb  5 02:01:16 2024 daemon.notice netifd: wan_4 (3303): udhcpc: lease of 10.77.97.237 obtained from 10.77.97.238, lease time 7200
Mon Feb  5 02:59:00 2024 user.notice root: exec /root/lte_connect lost connection detected  ERROR=1

if I make the script do ifdown wan and ifup wan when it detects disconnection, I could create "race conditions" with automatic reconnection pre-implemented.

I also found this commit but I don't know if it can be reimplemented in the current Openwrt:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9abdf580d910e13ade68cbb23da9b5d83b839f8d

Is it possible to increase the amount of logs of the uqmi package?

can you post your script if possible so I can test it in my environment

This must be one of the most sought after features in OpenWrt crying out for more attention.

2 Likes

yes thanks for your quick response

but to apply this solution I would have to install "Modem Manager" which from what I understand is better but also a larger software package

Is there a possibility to do the same thing but with uqmi?

I think only with polling, which I consider unsatisfactory. This is main reason I opted for ModemManager.

Alternatively, I believe itā€™s trivial to get the modem itself to automatically reconnect, but then the IP data used by netifd is wrong.

There is desperately needed further attention in this area from those with the necessary know-how, but so far it has been neglected unfortunately.

If one were showcasing OpenWrt, this would be an area to avoid. No donā€™t look here, keep walking.

On the plus side, there has been some recent attempts to address the outstanding issues in ModemManager - see here:

With my own script I linked above reconnection time is down to three seconds (if modem restart is deactivated from the corresponding netifd script), but I would like this improved further if possible. I suppose if the modem can reconnect itself that may be better, and have the netifd data updated as soon as possible? My old Huawei B818-263 reconnected in one second. Iā€™m hazy on the particulars as I donā€™t understand the underlying mechanics so well.

1 Like

I think I'll give up and install "Modem Manager"

Kindly if it doesn't bother you too much before I proceed with the installation of the "Modem Manager" package, could you tell me how to display the same information from the CLI that uqmi shows me with the commands:

uqmi -d /dev/cdc-wdm0 --get-data-status
uqmi -d /dev/cdc-wdm0 --get-current-settings
uqmi -d /dev/cdc-wdm0 --get-signal-info
uqmi -d /dev/cdc-wdm0 --get-serving-system
uqmi -d /dev/cdc-wdm0 --get-system-info
uqmi -d /dev/cdc-wdm0 --get-lte-cphy-ca-info
uqmi -d /dev/cdc-wdm0 --get-cell-location-info 

in order to be able to compare "Modem Manager" and uqmi

I have been using a combination of "watchcat" and some self-made scripts (probably adapted from some of yours, I can't remember right now) and it works, but this is obviously not a proper solution.

What is the current status of ModemManager support about this (sorry, but there are too many active threads for me)? Do you recommend trying any version in particular?

Do you still need to build packages for your device (perhaps I can lend a helping hand here)?

I think it's worth it.

If the question: 'is that a cheeky request' were to be answered in the negative, then I'm not sure that that answer would pass the red-face test.

OK so since this patch:

ModeManager from version 1.18.8 has implemented so-called 'dispatcher scripts', which facilitate user-defined actions on detected events, obviating the requirement for wasteful and potentially delay-inducing polling.

Out of the box, present versions of ModemManager will report any disconnection to netifd using this default dispatcher script:

#!/bin/sh

# SPDX-License-Identifier: CC0-1.0
# 2022 Aleksander Morgado <aleksander@aleksander.es>
#
# Automatically report to netifd that the underlying modem
# is really disconnected
#
# require program name and at least 4 arguments
[ $# -lt 4 ] && exit 1

MODEM_PATH="$1"
BEARER_PATH="$2"
INTERFACE="$3"
STATE="$4"

[ "${STATE}" = "disconnected" ] || exit 0

. /usr/share/ModemManager/modemmanager.common
. /lib/netifd/netifd-proto.sh
INCLUDE_ONLY=1 . /lib/netifd/proto/modemmanager.sh

MODEM_STATUS=$(mmcli --modem="${MODEM_PATH}" --output-keyvalue)
[ -n "${MODEM_STATUS}" ] || exit 1

MODEM_DEVICE=$(modemmanager_get_field "${MODEM_STATUS}" "modem.generic.device")
[ -n "${MODEM_DEVICE}" ] || exit 2

CFG=$(mm_get_modem_config "${MODEM_DEVICE}")
[ -n "${CFG}" ] || exit 3

logger -t "modemmanager" "interface ${CFG} (network device ${INTERFACE}) ${STATE}"
proto_init_update $INTERFACE 0
proto_send_update $CFG
exit 0

But then perversely neither netifd nor ModemManager actually bring the connection back up following having reported and logged the disconnection, or have any option to facilitate the same.

I wrote a hack to actually effect the reconnection following disconnection using the following alternative dispatcher script '10-report-down-and-reconnect', which I based on the '10-report-down' script:

root@OpenWrt:~# cat /usr/lib/ModemManager/connection.d/10-report-down-and-reconnect
#!/bin/sh

# Automatically report to netifd that the underlying modem
# is really disconnected and reconnect if interface was up

# require program name and at least 4 arguments
[ $# -lt 4 ] && exit 1

MODEM_PATH="$1"
BEARER_PATH="$2"
INTERFACE="$3"
STATE="$4"

[ "${STATE}" = "disconnected" ] || exit 0

. /usr/share/ModemManager/modemmanager.common
. /lib/netifd/netifd-proto.sh
INCLUDE_ONLY=1 . /lib/netifd/proto/modemmanager.sh

MODEM_STATUS=$(mmcli --modem="${MODEM_PATH}" --output-keyvalue)
[ -n "${MODEM_STATUS}" ] || exit 1

MODEM_DEVICE=$(modemmanager_get_field "${MODEM_STATUS}" "modem.generic.device")
[ -n "${MODEM_DEVICE}" ] || exit 2

CFG=$(mm_get_modem_config "${MODEM_DEVICE}")
[ -n "${CFG}" ] || exit 3

IFUP=$(ifstatus ${CFG} | jsonfilter -e '@.up')

logger -t "modemmanager" "interface ${CFG} (network device ${INTERFACE}) ${STATE}"
proto_init_update $INTERFACE 0
proto_send_update $CFG

[ "${IFUP}" = "true" ] && ifup ${CFG}

exit 0

This works just fine, albeit I feel the reconnection is a little slow - 5 seconds on my Zyxel NR7101 without any further change.

The reconnection time can be sped up using this suggestion:

And with this my reconnection time is now 3 seconds.

In terms of further development, as you can see from here:

A reconnection facility has been added to ModemManager itself, and I would happily test that on my Zyxel NR7101 with 23.05 installed, but I lack the know-how to do make an installable package for that without spending ages researching how to do that.

1 Like

Yes I just finished installing it and I assume it will be more stable than before (or at least I hope so) :+1:

I apologize if the question may have been misunderstood, I will look into it calmly the documentation. :sweat_smile:

Thank you for taking the time to answer questions I asked. :grinning:

1 Like

Unfortunately I have to inform you that due to lack of experience or other causes I had to restore UQMI as the system with "Modem Manager" is not stable, at least in my case.

what I noticed that errors are accumulated on the wwan0 interface and even if the interface has an IP address, it doesn't even allow me to ping

Below is the modem manager configuration I used:

config interface 'wan'
        option device '/sys/devices/platform/1e1c0000.xhci/usb2/2-1'
        option proto 'modemmanager'
        option apn 'iliad'
        option auth 'none'
        option iptype 'ipv4'
        option loglevel 'DEBUG'
        option delegate '0'

You do know that ModemManager requires proxy access? If accessing the modem with another tool like uqmi without using a proxy, it will mess up communication and lead to lots of errors. See the explanation given in this thread:

Or perhaps your modem just needed a reset?

1 Like

It doesn't seem to me that when it went into error I issued uqmi commands, but you may very well be right it was a long night and as usual the mistakes will have been made by me (the person in front of the monitor usually makes mistakes, computer systems usually don't) :sweat_smile:

at most I used sms_tool to give AT commands, example:

sms_tool -d /dev/ttyUSB2 at "AT+QCAINFO"

I will wait until the auto-reconnect functionality is an option of the "Modem Manager" protocol that has been proposed to the package maintainer -> "yegorich https://github.com/openwrt/packages/issues/19794#ref-pullrequest-2089853468" :+1:

Anyway, thanks for the support you provided me

Yeah you really need proxy else the communication is wrecked and youā€™ll see lots of errors.

Iā€™d urge trying ModemManager again, but taking care to interact with modem only by proxy.

Not sure if those tools like the sms_tool supports proxy access or not.

1 Like

thanks again, there are many things I should learn... :sweat_smile:

Oh and by the way ModemManager has its own sms functionality presumably rendering external utilities like sms_tool redundant.

See ā€˜messaging optionsā€™ here:

https://www.freedesktop.org/software/ModemManager/man/1.0.0/mmcli.8.html

1 Like

Did that configuration work for you at all? When I try something similar, "netifd" complains that the device name is too long, and truncates it to 15 characters.

I assume you are referring to this (with ModemManager)

option device '/sys/devices/platform/1e1c0000.xhci/usb2/2-1

the connection starts and is established, I can navigate, etc

but unfortunately I haven't found a simple way to send AT commands to the modem, if I try shortly after the interface with ifconfig wwan0 shows errors "RX packets:27767 errors:456"(navigation ko).

I would need a hand first to carry out the classic ifdown wan; ifup wan that with the ModemManager package when there are errors on the interface does not restore the starting situation "RX packets:27767 errors:0" (navigation ok)

I also tried /etc/init.d/modemmanager stop; /etc/init.d/modemmanager start same problem does not restore the starting situation

I'm trying to read up on it, but I find the ModemManager package more complicated to manage

If someone gives me a hand, maybe I'll figure it out

1 Like

Iā€™m no ModemManager expert. Maybe @patrakov has some idea here?

You sure youā€™re not running any conflicting processes that break the proxy communication with the modem? By contrast to tools that speak to the modem in a kind of one shot and one response way, which doesnā€™t work very well with maintaining an active connection, ModemManager keeps open a communication channel with the modem through proxy, and using external tools in a manner that circumvents the proxy will break the communication and lead to errors as described above.

AT commands can be sent using mmcli:

https://www.freedesktop.org/software/ModemManager/man/1.0.0/mmcli.8.html#:~:text=--command%3DCOMMAND,is%20run%20in%20debug%20mode

Again, take care not to use an external tool that will break proxy communication.

I no longer have any QMI-compatible device. The commands below are guesses verified against the manual pages and a Huawei NCM modem.

Do not even try sending any AT commands; for most of the useful ones, an equivalent native mmcli command line switch exists. The manual is here: https://www.freedesktop.org/software/ModemManager/man/latest/mmcli.1.html

First of all, you need to figure out the index of the modem. It is a small integer.

MODEM_INDEX=$(mmcli -K --list-modems | grep '^modem-list.value' | head -n 1 | sed 's@.*/@@')

Then you can try getting the overall status of the modem:

mmcli -K -m "$MODEM_INDEX"

Or use -J to get JSON instead, this applies to all commands. This output would include some of the values that you are interested in, approximately equivalent to your --get-system-info output.

For the extended signal quality report (equivalent to --get-signal-info), you first need to enable periodic collection of the extended information. "10" in the example below is the period in seconds.

mmcli -m "$MODEM_INDEX" --signal-setup=10

Then, to get the report, use this command:

mmcli -K -m 0 --signal-get

Example report (trimmed to exclude inapplicable values):

modem.signal.refresh.rate         : 10
modem.signal.threshold.rssi       : 0
modem.signal.threshold.error-rate : no
modem.signal.lte.rssi             : -84.00
modem.signal.lte.rsrq             : -10.00
modem.signal.lte.rsrp             : -113.00
modem.signal.lte.snr              : 2.00

For MCC/MNC and related stuff (the approximate equivalent of --get-serving system), use this:

mmcli -K -m "$MODEM_INDEX" --location-get

Sample output:

modem.location.3gpp.mcc          : 515
modem.location.3gpp.mnc          : 66
modem.location.3gpp.lac          : 7002
modem.location.3gpp.tac          : 000000
modem.location.3gpp.cid          : 07013031
1 Like