Hey,
On Tue, Jan 11, 2022 at 11:47 AM Enrico Mioso wrote:
>
> With this architecture it will be netifd itself that retries?
>
Yes. Or at least it could be netifd doing it, if you don't have any
other monitoring application.
> Is already there a way that provides an indication for netifd to wait
: Tue, 11 Jan 2022 11:17:11
From: Aleksander Morgado
To: Enrico Mioso
Cc: Peter Naulls ,
"ModemManager (development)"
Subject: Re: Extending OpenWRt ModemManager protocol handler
Hey,
In other words, I think the current situation isn't going to change so soon.
So I was wond
I am totally in agreement here.
It would be VERY nice. :)
Thanks!!
On Tue, 11 Jan 2022, Aleksander Morgado wrote:
Date: Tue, 11 Jan 2022 11:17:11
From: Aleksander Morgado
To: Enrico Mioso
Cc: Peter Naulls ,
"ModemManager (development)"
Subject: Re: Extending OpenWRt Mo
Hey,
> > In other words, I think the current situation isn't going to change so soon.
> > So I was wondering if we can provide a kind of short-cut, so the protocol
> > handler examines all bearers it finds, skipping all the modem device
> > management.
> > This would allow the code to be re-usab
Hey Enrico,
>
> In other words, I think the current situation isn't going to change so soon.
> So I was wondering if we can provide a kind of short-cut, so the protocol
> handler examines all bearers it finds, skipping all the modem device
> management.
> This would allow the code to be re-usabl
think?
Would this solution be acceptable to you?
On Mon, 10 Jan 2022, Aleksander Morgado wrote:
Date: Mon, 10 Jan 2022 15:44:09
From: Aleksander Morgado
To: Peter Naulls
Cc: "ModemManager (development)"
Subject: Re: Extending OpenWRt ModemManager protocol handler
Hey Peter,
That&#x
Hey Peter,
> > That's not really true, because that timeout is bound to the max time
> > required by ModemManager to probe the AT/QMI/MBIM ports, which I
> > believe is close to those 45s max per port (in parallel). Having an
> > infinite loop there doesn't help, as that max time required by MM is
thanks a lot Aleksander for the help and assistance.
On Mon, 10 Jan 2022, Peter Naulls wrote:
Date: Mon, 10 Jan 2022 15:04:51
From: Peter Naulls
To: Aleksander Morgado
Cc: "ModemManager (development)"
Subject: Re: Extending OpenWRt ModemManager protocol handler
On 1/10/
On 1/10/22 9:00 AM, Aleksander Morgado wrote:
Hey,
That's not really true, because that timeout is bound to the max time
required by ModemManager to probe the AT/QMI/MBIM ports, which I
believe is close to those 45s max per port (in parallel). Having an
infinite loop there doesn't help, as tha
Hey,
> >>> So here I am at my second attempt to build a solution to enable
> >>> multi-modems and
> >>> multi-bearers usage in OpenWRt, with re-connection handling for persistent
> >>> connectivity.
> >>>
> >>
> >> This doesn't do anything about multiple modems, but here's my patch for
> >> retry
On 1/10/22 8:46 AM, Aleksander Morgado wrote:
Hey Peter,
So here I am at my second attempt to build a solution to enable multi-modems and
multi-bearers usage in OpenWRt, with re-connection handling for persistent
connectivity.
This doesn't do anything about multiple modems, but here's my pat
Hey Peter,
> > So here I am at my second attempt to build a solution to enable
> > multi-modems and
> > multi-bearers usage in OpenWRt, with re-connection handling for persistent
> > connectivity.
> >
>
> This doesn't do anything about multiple modems, but here's my patch for
> retry. Without th
On 1/10/22 4:32 AM, Enrico Mioso wrote:
Hello!!
So here I am at my second attempt to build a solution to enable multi-modems and
multi-bearers usage in OpenWRt, with re-connection handling for persistent
connectivity.
This doesn't do anything about multiple modems, but here's my patch for
Hey Enrico,
>
> So here I am at my second attempt to build a solution to enable multi-modems
> and multi-bearers usage in OpenWRt, with re-connection handling for
> persistent connectivity.
>
> This time I wrote a simpler application which only monitors existing bearers,
> and tries to keep the
14 matches
Mail list logo
