Managing 4G/LTE ISP-initiated "regular-deactivation"

So Vodafone UK seem to cut 4G connections every 48 hours leading to a "regular-deactivation" event on ModemManager - see the following events at Feb 17, 12:23 and Feb 19, 12:23:

Sat Feb 17 12:23:37 2024 daemon.info [2677]: <info>  [modem0/bearer40] verbose call end reason (6,36): [3gpp] regular-deactivation
Sat Feb 17 12:23:37 2024 daemon.info [2677]: <info>  [modem0] state changed (connected -> registered)
...
Mon Feb 19 12:23:39 2024 daemon.info [2677]: <info>  [modem0/bearer41] verbose call end reason (6,36): [3gpp] regular-deactivation
Mon Feb 19 12:23:39 2024 daemon.info [2677]: <info>  [modem0] state changed (connected -> registered)

I leverage the dispatcher script functionality in ModemManager to immediately reconnect - see here. This works fine.

Now I thought I could be clever and take control over this 48 hour refresh to make it happen around midnight every other day by entering this cron task:

0 0 2-30/2 * * mmcli --modem=0 --simple-disconnect

This resulted in the desired disconnect at midnight:

Thu Feb 22 00:00:00 2024 cron.err crond[6952]: USER root pid 7651 cmd mmcli --modem=0 --simple-disconnect
Thu Feb 22 00:00:00 2024 daemon.info [2677]: <info>  [modem0] state changed (connected -> disconnecting)
Thu Feb 22 00:00:00 2024 daemon.info [2677]: <info>  [modem0] state changed (disconnecting -> registered)

And yet, to my surprise, it made no difference to the 48 hour refresh from the previous Feb 19 "regular-deactivation" in the sense that I still saw this event:

Fri Feb 23 12:23:44 2024 daemon.info [2677]: <info>  [modem0/bearer44] verbose call end reason (6,36): [3gpp] regular-deactivation
Fri Feb 23 12:23:44 2024 daemon.info [2677]: <info>  [modem0] state changed (connected -> registered)

Why isn't "--simple-disconnect" enough to take control over this 48 hour refresh?

@patrakov or @bmork my original NR7101 actually stopped powering on ages ago:

Do you think there is any chance this could have been caused by:

mmcli -m 0 --disable 

getting called every 48 hours? Could the modem getting put into radio off state then back on rapidly somehow damage the hardware, resulting in router not powering on? Or is this completely unrelated?

If unrelated, then I think the solution to my previous post might be:

0 0 2-30/2 * * mmcli --modem=0 --disable

My guess is that it is unrelated. Calling mmcli will not wear out the hardware in any way I can imagine.

2 Likes

OK thanks.

Rather than issuing:

—disable

is there a better way to get my modem to deregister to trigger reconnection in a way that hopefully resets my ISP-triggered 48 hour disconnect? The —simple-disconnect wasn’t enough, so I’m presuming what is needed is reregistration with the network.

Might:

--3gpp-ussd-cancel

be appropriate?

Or is the —disable already the best way?

I don't know this. I usally power down the radio using

mbimcli --set-radio-state=off

when I need to disconnect the initial bearer. But that's an even bigger hammer, I guess.

Actually it looks like mmcli's --disable is equivalent to mbimcli's radio-state=off:

"power low" as MM sees it is more like "radio off", not as "power
saving mode". Just think that when you switch off the radio, the power
consumed goes very low :slight_smile:

https://mail.gnome.org/archives/networkmanager-list/2016-March/msg00099.html

But it turns out that even when I use: --disable, like so:

Sat Feb 24 00:00:00 2024 cron.err crond[17367]: USER root pid 19211 cmd mmcli --modem=0 --disable
Sat Feb 24 00:00:00 2024 daemon.info [2677]: <info>  [modem0] state changed (connected -> disabling)
Sat Feb 24 00:00:01 2024 daemon.info [2677]: <info>  [modem0/bearer53] connection #1 finished: duration 22329s, tx: 180551754 bytes, rx: 2098847475 bytes
Sat Feb 24 00:00:01 2024 user.notice modemmanager: interface wan (network device wwan0) disconnected
Sat Feb 24 00:00:01 2024 daemon.notice netifd: Interface 'wan' has lost the connection
Sat Feb 24 00:00:01 2024 daemon.warn dnsmasq[1]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Sat Feb 24 00:00:01 2024 daemon.notice netifd: Network device 'wwan0' link is down
Sat Feb 24 00:00:01 2024 daemon.info [2677]: <info>  [modem0] 3GPP registration state changed (home -> unknown)
Sat Feb 24 00:00:01 2024 daemon.info [2677]: <info>  [modem0] state changed (disabling -> disabled)
Sat Feb 24 00:00:01 2024 daemon.notice netifd: wan (19244): stopping network
Sat Feb 24 00:00:01 2024 daemon.notice netifd: wan (19244): successfully disconnected all bearers in the modem
Sat Feb 24 00:00:01 2024 daemon.notice netifd: Interface 'wan' is now down

This wasn't enough to shift the 48-hour 'regular-deactivation':

Sun Feb 25 12:23:46 2024 daemon.info [2677]: <info>  [modem0/bearer55] verbose call end reason (6,36): [3gpp] regular-deactivation
Sun Feb 25 12:23:46 2024 daemon.info [2677]: <info>  [modem0] state changed (connected -> registered)

Perhaps there is nothing I can do to take control over this period. And perhaps the 48 hour 'regular-deactivation' is applied at the same time from the cell tower to all connected devices independent of when they registered/connected.

If any reader can offer any insight here please do chime in!

Hi.

Same here with my isp, but it's 24h range.
I tested with another ISP at same location with same devices, and I got same IP for days, and not a single disconnection occurred until I manually disconnected the device/lt4 interface.
Not openwrt related. It's a ISP policy for mobile connections.
With my mikrotik sxt_lt6 same thing, 24h period.
Huawei b315, E3372 with openwrt, samo. At the device logs I got 24h period with a few seconds of variation.

Thanks for sharing that. Is the disconnection period related to when you connected or independent? I thought mine was 48 hours from connection, and so that by disconnecting I could shift it (so disconnects occur at night), but issuing: mmcli —disable and immediately reconnecting doesn’t cut it in that the 48 hour interval isn’t shifted.

Hi.
Time period. 24h after connected.
I just checked my last logs,, for example:
19:39 day 21, lte link up, connected ( device was up at least for a month )
20:36 day 22, lte link down, disconnected.
Got an extra hour, but usually it 24h period +- 30secs to a few minutes.
Will check over full logs if when a manual disconnect occurred, if the time period was renewed.

1 Like

I wonder if my automated reconnection is too rapid and I need to add a 5s delay between disconnection and reconnection?

Hi.
As we say here, if it works, don´t touch it @Lynx " I leverage the dispatcher script functionality in ModemManager to immediately reconnect This works fine."
As the issue is not client side ( openwrt for you and myself with mikrotik router OS too ) I think your timing is just fine. I don't use any script with my couple of we826 and EC25 lte modem with openwrt, when LTE goes down by the ISP, the we826 will do the job to reconnect without any scripting. In the past I got same issue as you with E3372 and openwrt, ( 24h ) I solved the issue with mwan.
I just remember, as I said previously with another local ISP I dint have the period issue, the reason should be because this one use CGNAT for mobile customers, as my current ISP use public IP. That in my opinion the reason for renew the connection, and free their limited public IPs.
And for a charge, my Isp will provide to any customer a static IP.