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 (Slava Monich)
2. Re: [PATCH] gresolv: fix ASAN runtime error. (Mickael GARDET)
----------------------------------------------------------------------
Message: 1
Date: Tue, 3 Sep 2019 11:38:36 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Cc: [email protected], Aleksandar Mitev
<[email protected]>, Daniel Wagner <[email protected]>, 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
> 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
------------------------------
Message: 2
Date: Tue, 3 Sep 2019 13:13:31 +0200
From: Mickael GARDET <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [PATCH] gresolv: fix ASAN runtime error.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Daniel,
Yes I think so.
Thanks,
Mickael
Le 02/09/2019 ? 09:09, Daniel Wagner a ?crit?:
> Hi Mickael,
>
> On Wed, Aug 28, 2019 at 10:45:16AM +0200, Mickael GARDET wrote:
>> ../git/gweb/gresolv.c:331:7: runtime error: left shift of 169 by 24
>> places cannot be represented in type 'int'
>> connmand2[3417]: eth0 {add} route 192.168.2.0 gw 0.0.0.0 scope 253 <LINK>
> Since ntohl returns the uint32_t type, I changed your patch to this:
>
> -#define DQUAD(_a,_b,_c,_d) ( ((_a)<<24) | ((_b)<<16) | ((_c)<<8) | (_d) )
> +#define DQUAD(_a,_b,_c,_d) ( (((uint32_t)_a)<<24) | (((uint32_t)_b)<<16) | \
> + (((uint32_t)_c)<<8) | ((uint32_t)_d) )
> #define V4MATCH(addr, a,b,c,d, m) ( ((addr) ^ DQUAD(a,b,c,d)) >> (32 - (m)) )
>
> #define RFC3484_SCOPE_LINK 2
> @@ -326,7 +327,7 @@ static int addr_scope(struct sockaddr *sa)
> {
> if (sa->sa_family == AF_INET) {
> struct sockaddr_in *sin = (void *)sa;
> - guint32 addr = ntohl(sin->sin_addr.s_addr);
> + uint32_t addr = ntohl(sin->sin_addr.s_addr);
>
> if (V4MATCH(addr, 169,254,0,0, 16) ||
> V4MATCH(addr, 127,0,0,0, 8))
>
>
> Hope that's okay with you. It should fix at least the problem you reported.
>
> Thanks,
> Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 47, Issue 2
**************************************
