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 (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Fri, 6 Sep 2019 15:22:17 +0200
From: Daniel Wagner <[email protected]>
To: Slava Monich <[email protected]>, [email protected]
Cc: Aleksandar Mitev <[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
Hi,
On 9/4/19 5:22 PM, Slava Monich wrote:
>> 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.
I agree. There are many small problems along the road.
> 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.
Okay, understood. If we going to mess with the current state machine we
need to keep a compact mode. I suppose compile time would be good enough?
>> 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.
Indeed, VPN can be pretty tricky. This needs a lot of testing.
@Slava: I highly appreciate your feedback!
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 47, Issue 4
**************************************
