Calling on all 4G/QMI Experts! wan IP refresh issue

@patrakov do you know the status of the fix you linked in terms of implementation in OpenWrt? It seems @aleksander0m and @jow chatted about this on #openwrtl-devel and a fix has been developed to help pass informaiton to netifd:

Talked to jow in #openwrt-devel about this, and I think I have a clean > way to solve this issue. Any process can notify netifd that the > underlying network is really disconnected, basically like this: > . /lib/netifd/ > proto_init_update $ifname 0; proto_send_update > > ifname there is the name of the netifd interface. > > What we could do is setup event scripts in ModemManager to be executed > upon some specific events; e.g. on bearer connection and on bearer > disconnection. ModemManager would call those scripts as appropriate, > e.g. providing additional info as input arguments to the script. So, > when a bearer gets disconnected, MM could call every script in > /etc/ModemManager/bearer-disconnect.d/ passing as arguments the modem > dbus path and the bearer dbus path. > > The openwrt package could provide a custom script in > bearer-disconnect.d that would: > ** find the ifname applicable to the modem object* > ** run the proto update sequence as above* > > What do you think of having something like that? > > We already support custom scripts for when FCC unlock is needed, > having event scripts for bearer connection/disconnection events would > probably be fine also. They could also be used e.g. to setup/cleanup > iptables rules on the specific connected interface and such, something > that is currently not really possible because the user may not know > which is the exact net interface of the modem being connected (even > less when using multiplexing as net interfaces are created on the > fly).

but the issue of having netifd reconnect was left hanging here:

Hey, On Tue, Jan 11, 2022 at 11:47 AM Enrico Mioso < at> wrote: > > With this architecture it will be netifd itself that retries? > Yes. Or at least it could be netifd doing it, if you don't have any other monitoring application. > Is already there a way that provides an indication for netifd to wait some time before retrying? Trying to bring a bearer back up immediately might not be so much productive. > I agree, immediate reconnection attempts are not always desirable. Also, there should be a way to configure the amount of retries so that they're not infinite, or if keep on retrying after some time (e.g. retry 5 times with 20s between retries and if they all fail, wait 10 minutes before restarting the new retry cycle). NetworkManager has all those kind of settings, but truth be told, no idea about netifd.

So @jow I'm keen to know what is the status of implementation of:

  • ModemManager communicating to netifd that connection has been lost

  • netifd reacting to loss of connection and reconnecting

I see this commit:

Could that please be pulled into 22.03? And what about having netifd react to loss of connection and reconnecting? Will that already happen?

Background is that in my case on 22.03.2 using ModemManager through luci-proto-modemmanager, owing to my ISP disconnecting me very 48 hours, I see:

Mon Oct 31 17:37:46 2022 [2719]: <info>  [modem0/bearer1] verbose call end reason (6,36): [3gpp] regular-deactivation

I lose internet connectivity, netifd doesn't seem to know connection is down and there is no automatic reconnection. Surely this affects quite a lot of users who have to come up with their own DIY reconnection scripts, whereas it seems the proper fix is pretty much all there if not already here.