Automatic Reconnect

[Lynx de Cat]

Beyond my skill level but as a temporary fix the following works well
for me - namely just amend the 10-report-down script so that it ends
with:

```
IFUP=$(ifstatus ${CFG} | jsonfilter -e '@.up')

logger -t "modemmanager" "interface ${CFG} (network device
${INTERFACE}) ${STATE}"
proto_init_update $INTERFACE 0
proto_send_update $CFG

[ "${IFUP}" = "true" ] && ifup ${CFG}
```

That is, work out if the interface was up before it is set down, and
after it was set down, then bring it back up if it was up.

On Mon, Nov 7, 2022 at 3:11 PM Aleksander Morgado
<aleksandermj at chromium.org> wrote:
>
> Hey,
>
> >
> > So what I tried instead was to simply directly install the
> > ModemManager .ipk from OpenWrt master on my 22.03.2 environment. It
> > worked, and now with the updated Modem Manager with dispatcher script
> > as per:
> >
> > https://github.com/openwrt/packages/commit/bc754f31cfdb004eefa43038f8f0827922107fc6
> >
> > netifd correctly sees that the interface has gone down:
> >
> > 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
> > Wed Nov  2 20:38:54 2022 daemon.notice netifd: Interface 'wan' has
> > lost the connection
> > Wed Nov  2 20:38:54 2022 daemon.notice netifd: Network device 'wwan0'
> > link is down
> > Wed Nov  2 20:38:54 2022 daemon.warn dnsmasq[1]: no servers found in
> > /tmp/resolv.conf.d/resolv.conf.auto, will retry
> >
> > However, netifd does not seem to do anything at this point - there is
> > no attempt to reconnect.
> >
> > So this has only shifted the problem to netifd. Is there a line in
> > /etc/config/network or similar to tell netifd to immediately reconnect
> > (which was presumably the point of informing netifd that the interface
> > went down?).
> >
>
> Looks like there is indeed no automatic reconnection triggered via
> netifd, because of the explicit disconnection request that netifd
> receives when MM detects the network-initiated disconnection.
>
> Talked to jow last week about this in IRC, and I think the way to
> solve this would be to have a "watcher" process launched by the MM
> protocol handler on every connection attempt. Then, if MM detects a
> network initiated disconnection, it would kill this watcher process,
> which would instruct netifd to re-start the connection if it was set
> to auto. This new logic would tie the status of the netifd interface
> to the existence of this watcher process. I'd be happy to review
> changes doing this if anyone is up to the task!
>
> --
> Aleksander