Dear Aleksander,
I have a further question about all of this.
My script works in that I see disconnect reported at 11:18:08 and then
wan back up 11:18:13, but that is a fairly slow reconnection. My modem
RG502Q-EA in Zyxel NR7101 supports automatic reconnect with something
along the lines of 'qmicli -p -d /dev/cdc-wdm0 --wds-set-autoconnect
enabled', and wouldn't that permit a faster reconnection? My Huawei
B818-263 reconnected in between 1 and 2 seconds. But if we have the
modem autoreconnect, then doesn't ModemManager need to monitor the
reconnect, get the new IP settings, and pass on the new IP settings to
netifd. And how would this work? Is this functionality already handled
and is so how do I enable it? I notice at the moment that I the
autoconnect settings seem to be disabled with the netifd ModemManager
protocol.
By the way my IFUP modification to the 10-report-down script already
checks whether the interface was up before reporting the disconnect,
and only brings the interface back up if it was previously up. So it
already handles the state where the interface was brought down by the
user (it will not reconnect then, since ifup was not true).
Kind regards,
On Tue, Nov 8, 2022 at 8:30 PM Aleksander Morgado
<aleksande...@chromium.org> wrote:
>
> On Mon, Nov 7, 2022 at 4:56 PM Lynx de Cat <lynx.lig...@gmail.com> wrote:
> >
> > 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.
> >
>
> This could indeed fit more or less your usecase, don't see why not.
> You could also check whether the user had configured 'auto' for this
> interface, because if auto is not set, there should be no
> autoreconnection triggered. Also, you would need to differentiate
> between a user-triggered disconnection (i.e. a ifdown) and a
> network-initiated disconnection, because in the former you should not
> attempt to reconnect.
>
> So, I see how this could solve your problem, but it also hides
> completely the autoreconnection logic that netifd already has, and
> would require a lot of quirks to make it work as everyone expects it
> to work. A better solution, IMHO, would be to have netifd monitor the
> watcher process that I suggested in a previous email. It's a more
> complex solution though, but it's really the way of autoreconnection
> that was envisioned when the MM disconnection dispatchers support was
> introduced.
>
> --
> Aleksander
