@yogo1212 since your post above, @jow and I had a discussion on #openwrt-devel about this very issue here covering:
- general brokenness of wireless wan in OpenWrt right now because of the lack of disconnection handling in either ModemManager or qmi protocols
- ModemManager;
- @aleksander0m's patch to ModemManager; and
- uqmi and your proposed changes to the qmi protocol.
@jow gives some thoughts relative to netifd which might be useful in terms of fixing uqmi to properly handle disconnections.
Here are some titbits that seem relevant:
[11:21:12] [jow] maybe. problem is that neither mm nor uqmi really fit into netifd's expected process model
[11:21:17] [jow] what netifd really needs is:
[11:21:34] [jow] a process it starts in order to create/configure/keep running a network device
[11:21:45] [jow] when the process dies, the network device dies along with it
[11:22:03] [jow] this holds true for pppd, openvpn and various other tunnel protocols
[11:22:22] [jow] there's also protocols using one-shot commands (ip link ... or ip tunnel ...) to set things up[11:27:11] [jow] I could imagine a theoretical "uqmi monitor" subcommand
[11:27:24] [jow] it will start a daemon process that subscribes to events from thje given device
[11:27:34] [jow] and if it catches a disconnection event, it will exit(0) itself
[11:27:58] [jow] this "uqmi montor" daemon process could then be launched by netifd[11:31:21] [jow] I mean uqmi oneshot commands could be redesigned in a way that they firs try to communicate through the monitor process if one is found active for the device it is attmepting to talk to
[11:31:29] [jow] and falling back to the old way of doing things
Please see full log here: https://pastebin.com/raw/7ePH0W5N
One observation is that this assumption:
is apparently incorrect - netifd will not automatically reconnect. @jow suggested that in this instance ModemManager ought to reconnect, then a report-up script like the existing report down-script would need to communicate new details to netifd.
So actually the state of the ModemManager protocol is still broken in OpenWrt right now notwithstanding the patch because ModemManager expects netifd to reconnect, but netifd expects ModeManager to reconnect. And the poor user has to resort to dodgy DIY hacks like rebooting the router every 12 hours or reconnecting on ICMP failure.
So we are really needing knight in shining armour to fix up netifd qmi so that disconnection events are handled and modem is reconnected and new configuration details provided to netifd.
I can help with testing, subject to not wanting to brick my Zyxel NR7101.