Please forgive my impertinence and ignorant comments; I likewise rely upon my wife to tell me off for speaking before thinking and other inappropriate mannerisms, but that important feedback mechanism does not apply in respect of some of my online interactions.
Now I feel a bit like a bull in a china shop bandying about my ill-conceived thoughts and ideas here and there without really properly understanding the underlying issues.
I think what you see is just a reflection of frustration on my part in trying to get things up and running properly. I have so enjoyed setting up OpenWrt on my downstream router and access points, and it turned out doing the same on my 4G modem replacement has not been so easy.
For completeness, I enclose the follow-up conversation between @jow and @aleksander0m on #openwrt-devel, which describes how a 'watcher' process should perhaps be setup. @yogo1212 I presume this technique could also work for the 'qmi' protocol?
[13:30:34] <aleksander> oh wow, I missed a long discussion
[13:31:16] <aleksander> MM doesn't automatically reconnect, MM does not have any logic for that, it's not a connection manager
[13:31:32] <aleksander> MM only acts on what the upper layer connection manager requests to do, be it connect or disconnect
[13:31:57] <aleksander> MM will monitor network initiated disconnections, and report the disconnection to the upper layers so that they decide what to do
[13:33:31] <aleksander> jow, not sure if I understood it correctly, but are you suggesting triggering the reconnection from within the MM dispatcher script when it reports a disconnection? that's a bit convoluted
[13:38:49] <jow> aleksander: problem is that netifd regards mm to be the connection manager as it is not supervised by netifd
[13:39:04] <aleksander> "nobody likes ModemManager since it uses dbus and all these extra packages and it's really a big elephant" MM was never targeting devices with estremely low amount of memory, but a lot of openwrt devices have tonds of memory available and MM is not such a big elephant there
[13:40:15] <aleksander> jow, there's no connection management done by MM itself though, it's all done at netifd and protocol handler level
[13:41:03] <jow> aleksander: I don't want to repeat all the discussion again
[13:41:19] <jow> but in essence, netifd only does reconnections for supervised proto handler processes
[13:41:28] <aleksander> jow, the dispatcher script called by MM on disconnect (.e.g when a network initiated disconnect happens) was supposed to notify netifd that the "underlying" connection is down, so that netifd can report the iface as down
[13:41:58] <aleksander> ah, wrongly assumed that then
[13:42:49] <aleksander> what needs to happen to have it a supervised proto handler process? is that something that can be developed in the proto handler implementation itself?
[13:43:24] <jow> maybe you can get away with a simple brute force approach of simply calling ubus call network.interface down '{ "interface": "$CFG" }' && sleep 1 && ubus call network.interface up '{ "interface": "$CFG" }'
[13:43:32] <jow> in that disconnect notify script
[13:44:05] <jow> aleksander: basically you need some sort of process that exits when the underlying device loses connection
[13:44:20] <aleksander> doing that breaks the purpose of the disconnect notify script though
[13:44:35] <jow> aleksander: netifd will then kill the netdev, restart that process and await proto updates
[13:44:59] <aleksander> we could have a watcher process launched on a connect, and have that process killed by the disconnect dispatcher script
[13:45:06] <jow> yep
[13:45:23] <jow> netifd will restart the watcher process
[13:45:30] <aleksander> that's doable and clean, because the watcher process would be launched within the protocol handler
[13:45:40] <jow> but it is also assumed that this "watcher process" is also the "setup process"
[13:45:54] <aleksander> that's fine
[13:46:09] <jow> so the watcher would also need to do all the necessary things to initiate a connection, fetch details, trigger a proto update notify
[13:46:12] * danitool (~dani@94.73.56.247) has quit IRC (Remote host closed the connection)
[13:46:27] <aleksander> yes, yes, that's doable I think
[13:47:00] <jow> you will also only need this watcher process for non-ppp connection types
[13:47:37] <jow> for ppp, the proto handler already does proto_run_command /usr/sbin/pppd ...
[13:47:45] <jow> which has the required semantics
[13:47:55] <aleksander> yep
[13:48:58] <jow> (while looking at it: 22https://github.com/openwrt/packages/blob/master/net/modemmanager/files/modemmanager.proto#L159 - $username and $password should be quoted)
[13:49:50] <jow> nvm, they don't need to
[13:54:15] <aleksander> oh well, already did this: 22https://github.com/openwrt/packages/pull/19811
[13:54:31] <aleksander> want me to close that?
[13:54:40] <jow> keep it open, it does not hurt
).