Automatic Reconnect

[Lynx de Cat]

Quick follow-up question - with this inside the 10-report-down script:

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}

The reconnection from disconnect up to usable connection takes 5
seconds. Is there any way to speed that up at all?

On Thu, Nov 10, 2022 at 9:18 AM Aleksander Morgado
<aleksandermj at chromium.org> wrote:
>
> Hey,
>
> >
> > 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.
>
> QMI autoconnect is explicitly disabled during the MM connection
> attempt because if IP settings change, we wouldn't be able to reapply
> them properly because no one would notice the disconnection; that's
> the main idea. Also, "autoconnection" is something not in MM's scope,
> so that's why we manually try to manage the connectivity, also so that
> errors in the connection attempt are properly propagated to the user.
>
> >
> > 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).
> >
>
> Ah, that could indeed work.
>
> --
> Aleksander