Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH 0/6] Re: Propose patch for perpetual online check
for connected services (Aleksandar Mitev)
2. Re: [PATCH 0/6] Re: Propose patch for perpetual online check
for connected services (Aleksandar Mitev)
3. Re: [PATCH 0/6] Re: Propose patch for perpetual online check
for connected services (Slava Monich)
----------------------------------------------------------------------
Message: 1
Date: Wed, 4 Sep 2019 16:48:28 +0300
From: Aleksandar Mitev <[email protected]>
To: Slava Monich <[email protected]>
Cc: [email protected], Aleksandar Mitev <[email protected]>, Daniel
Wagner <[email protected]>
Subject: Re: [PATCH 0/6] Re: Propose patch for perpetual online check
for connected services
Message-ID:
<CAAk4MJitfRkcpJs1QZgN+PPg4=GJP+zmwUCon=ZCzkZNHy2=x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for thinking this over :)
As of v1.37, when a service reaches the READY state, then the online check
is started. If it succeeds, the a transition to ONLINE state happens. You
are right in thinking that my proposed change will cause a downgrading to
READY again, but you see, according to the state machine, another round of
online checking will begin, possibly promoting the service back to ONLINE
it it ever succeeds (ex. the Internet disruption was temporary). In
general, this is a chance for any of the other services in READY state to
take over.
I am not sure and can never be on how applications will react to such a
transition, as I would guess it is up to, how well the application is
written, and provided it ever needs such information about which is the
default service atm (I can imagine most of the apps just need internet,
that is all). Yet, given the fact, that most applications already react to
switching of connections (i.e. the wifi goes away failing back to cellular)
I do not expect major headaches.
Finally, if a failed online check is not reliable enough to determine
Internet reachability, then it can be disabled altogether and replaced with
a simple ping check (from a separate service) as in the case of mwan3 tool
for Openwrt. However, in that case one will miss the checking of DNS
working.
Please share more details if you think I am missing smth here.
Best,
Aleksandar
On Tue, Sep 3, 2019 at 11:38 AM Slava Monich <[email protected]> wrote:
> > From: Aleksandar Mitev <[email protected]>
> >
> > ...
> >
> > So my proposed change is to monitor the internet reachability at regular
> intervals,
> > using the same technique that connman uses now at the connecting phase.
> However,
> > since this checking will eat some data inevitably, we would not want to
> run it
> > on the cellular connection, at least (which is last resort anyway and no
> fallback
> > can be made). That is why the config option I added is based on network
> interfaces,
> > allowing you to choose only those devices that would make sence to
> continuously
> > check for Internet reachability.
>
>
> IIRC, a service first becomes "ready" and then if online check succeeds,
> transitions to the "online" state. Therefore, if a repeated online check
> fails, the service has to become "ready" again, as if online check never
> succeeded in the first place.
>
> That's still a rather significant change, since it introduces a new
> "online" -> "ready" transition in the service state machine. Application
> software may not be ready to handle that.
>
> However it won't solve the problem of silently losing the Internet
> connection, because transition to "ready" state doesn't cause reconnect.
> The service just happily stays in the "ready" state and that's it.
>
> Not to mention that a failed online check doesn't mean that you're not
> connected to the Internet. It only means that the online check service
> is down or unreachable (e.g. blocked by a corporate firewall or local
> authorities).
>
> Am I missing something?
>
> -Slava
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20190904/5cedd6dd/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 4 Sep 2019 16:50:47 +0300
From: Aleksandar Mitev <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected], Aleksandar Mitev <[email protected]>
Subject: Re: [PATCH 0/6] Re: Propose patch for perpetual online check
for connected services
Message-ID:
<caak4mjh-f7e12pbfpcmcjjnosuaw7ho+4huxk39wdo0pyg7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
> Would you mind to respin your patches withtout the
InterfacesPerpetualOnlineCheck config option?
Yes, starting that now.
On Mon, Sep 2, 2019 at 10:21 AM Daniel Wagner <[email protected]> wrote:
> Hi Aleksandar,
>
> On Tue, Aug 27, 2019 at 03:30:40PM +0300, [email protected]
> wrote:
> > Ok, let me describe our use case that led me to come up with the
> proposed change:
> > We have a setup with Ethernet, Wifi and Cellular and want to have
> Internet access
> > in any case. This would mean that if an interface fails or doesn't have
> Internet
> > reachability, a switchover should be made to the next one. Of course,
> Ethernet
> > is the most preferred, falling back to Wifi, and if Wifi is not reliable
> source
> > of Internet, then go to the last resort of Cellular.
> >
> > Everything is running fine with the current version of connman, except
> that, if,
> > for example, Ethernet is the current default source of Internet, and the
> router
> > we are connected to, stops routing packets for some reason, then we lose
> Internet
> > connectivity and our connection the device is no longer active.
> > But connman would not react and continue using the Ethernet connecion. I
> have seen
> > this on my Android phone as well: when I am connected with Wifi and the
> ISP
> > decides to cut my router's Internet access, then the phone would not
> switch to cellular
> > and no application would recieve notifications for indefinite time.
> >
> > So my proposed change is to monitor the internet reachability at regular
> intervals,
> > using the same technique that connman uses now at the connecting phase.
> However,
> > since this checking will eat some data inevitably, we would not want to
> run it
> > on the cellular connection, at least (which is last resort anyway and no
> fallback
> > can be made). That is why the config option I added is based on network
> interfaces,
> > allowing you to choose only those devices that would make sence to
> continuously
> > check for Internet reachability.
>
> Thanks for the more verbose explenation on what you want to
> achieve. This sounds like a reasonable thing to expect from
> ConnMan. Overall, I think we don't need to add a new config
> options. Instead just depend on the default OnlineCheck option. If
> that is set ConnMan should continuously do the check. Would you mind
> to respin your patches withtout the InterfacesPerpetualOnlineCheck
> config option?
>
> > >[1] https://git.merproject.org/mer-core/connman
> >
> > I was not familiar with this fork of connman. Did not test it but looked
> > at the code and I did not find the continuous check after the service
> goes to
> > ONLINE state. I may be missing smth here, though.
>
> I just might have remembered it wrong.
>
> > As for the config option - sure, it could be removed (meaning that all
> > interfaces would be treated as enabled for checks) or reduces to a
> > simple global switch that would enable continuous online check after
> > going to the ONLINE state. However, please consider the usefulness of
> > our use case here.
> >
> > >> Attached is the proposed patch (based on tag 1.37).
> > >
> > >The patches were attached to this mail. Did you use git send-email to
> > >send out the patches?
> >
> > No, I just used my email client. Now using the git send mail. Hope this
> > is the right way to send patch proposals along.
>
> Looks good now :)
>
> Thanks,
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20190904/7203020d/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 4 Sep 2019 18:22:37 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Cc: Aleksandar Mitev <[email protected]>, Aleksandar Mitev
<[email protected]>, Daniel Wagner <[email protected]>
Subject: Re: [PATCH 0/6] Re: Propose patch for perpetual online check
for connected services
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 04/09/2019 16:48, Aleksandar Mitev wrote:
> Thanks for thinking this over :)
>
> As of v1.37, when a service reaches the READY state, then the online
> check is started. If it succeeds, the a transition to ONLINE state
> happens. You are right in thinking that my proposed change will cause
> a downgrading to READY again, but you see, according to the state
> machine, another round of online checking will begin, possibly
> promoting the service back to ONLINE it it ever succeeds (ex. the
> Internet disruption was temporary). In general, this is a chance for
> any of the other services in READY state to take over.
Are you sure that another service WILL actually take over when some
other service is stuck in the READY state? That's the key point.
If such a handover doesn't happen then this transition back to READY is
useless. It will be just generating additional network traffic and
that's it.
If handover does indeed happen then it's a major change of behavior and
must be configurable. We (Sailfish OS) consider READY as of the
"connected" states. We don't need and don't want to automatically switch
from WiFi to mobile data if WiFi gets stuck in the READY state. We still
consider it connected and let the user to turn it off and switch to
mobile data, if the user notices that it's not actually working.
> ...
>
> Finally, if a failed online check is not reliable enough to determine
> Internet reachability, then it can be disabled altogether and replaced
> with a simple ping check (from a separate service) as in the case of
> mwan3 tool for Openwrt. However, in that case one will miss the
> checking of DNS working.
>
> Please share more details if you think I am missing smth here.
>
Have you considered the VPN scenario? When VPN is connected, you may not
be able to run online check for the transport interface - it won't have
any routes to anything other than local subnet and the VPN server.
Cheers,
-Slava
> Best,
> Aleksandar
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 47, Issue 3
**************************************
