Hi Felix,
just a small ping :)
> On Petr Štetiar <yn...@true.cz> [2016-10-21 11:06:03]:
> > Felix Fietkau <n...@nbd.name> [2016-10-20 12:09:36]:
>
> > On 2016-10-19 23:49, Petr Štetiar wrote:
> > >
> > > How to fix it for both use cases, with and without autoconnect feature?
> > > Introduce qmi_autoconnect config option?
> >
> > I think we probably need to introduce such an option as a temporary
> > measure.
>
> Ok, I'll do this. Is this variable name fine?
should I just send the patch with qmi_autoconnect variable name?
> > The problem with not using autoconnect is that once the link is gone for a
> > while, the link will be torn down and not re-established anymore. To deal
> > with that properly, we need some code to monitor the link and try to
> > re-establish the connection when it's gone.
>
> Even when enabled and usable, this autoconnect feature is as reliable as the
> modem firmware is. I'm seeing a lot of problems with such modems(freezing,
> unable to connect) and I generally do not trust them so I use some additional
> checking via my custom wan-connection-keeper daemon/script which runs
> following
> check in periodic intervals:
>
> check_connection() {
> local check_timeout=$(uci -q get
> wan-connection-keeper.core.check_timeout)
> local uci_check_url=$(uci -q get
> wan-connection-keeper.core.uci_check_url)
> local url=$(uci -q get $uci_check_url)
... snip ...
> echo oneshot > /sys/class/leds/reset-usb-hub2/trigger
> echo none > /sys/class/leds/reset-usb-hub2/trigger
... snip ...
> How to make it more generic as you propose. Move it inside netifd?
>
> config interface 'wan'
> option connection_check '/path/to/checkscript'
> option connection_check_interval 60
I can try to work on this one also. Thanks for your input.
-- ynezz
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
