@yogo1212 for the 'qmi' protocol of netifd there is surely a way to achieve what ModemManager does and interpret messages from the modem a la:
Wed Nov 2 20:38:54 2022 daemon.info [2716]: <info> [modem0] state changed (connected -> disconnecting)
Wed Nov 2 20:38:54 2022 daemon.info [2716]: <info> [modem0] state changed (disconnecting -> registered)
Wed Nov 2 20:38:54 2022 daemon.info [2716]: <info> [modem0/bearer3] connection #1 finished: duration 121s, tx: 258333 bytes, rx: 371928 bytes
Wed Nov 2 20:38:54 2022 user.notice modemmanager: interface wan (network device wwan0) disconnected
or:
Mon Oct 31 17:37:46 2022 daemon.info [2719]: <info> [modem0/bearer1] verbose call end reason (6,36): [3gpp] regular-deactivation
And react on that by immediately putting interface down, reconnecting and interface back up (if I am getting this right)?
This would bring the 'qmi' protocol up to speed with the 'ModemManager' protocol, and perhaps even surpass it since presently with the 'ModemManager' protocol netifd doesn't even bother to reconnect, which baffles me.