Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: gdhcp: Make DHCP client timeouts suspend aware (Daniel Wagner)
2. Re: [PATCH] vpn: Do not do mixed declerations and code
(Daniel Wagner)
3. Re: [PATCH] src: Test return value of inet_pton consistently
(Daniel Wagner)
4. Re: [PATCH] vpn: Export vpn_ipconfig_foreach as linker symbol
(Daniel Wagner)
----------------------------------------------------------------------
Date: Mon, 14 Dec 2020 09:25:07 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: gdhcp: Make DHCP client timeouts suspend aware
To: Denis Kenzior <denk...@gmail.com>
Cc: "Holesch, Simon (GED-SDD1)" <simon.hole...@bshg.com>,
"connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20201214082507.snktzydo3qjmk...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Denis,
On Wed, Dec 09, 2020 at 10:11:43AM -0600, Denis Kenzior wrote:
> > In this case the DHCP code needs to be made aware of the power state
> > transitions. In hindsight, CLOCK_BOOTTIME_ALARM was not the best
> > choice.
>
> Just curious what you have in mind? How would knowing the power state help?
I didn't really think it through. I just though it we might need to know
if we wake up and need to check the timers. But I suppose there is a more
elegant solution.
> > Anyway, I think the best way forward is to either revert the commit or
> > change it to use the original clock id. This will give some time to
> > figure out how to teach the DHCP the power states.
>
> Perhaps setting valid_lft on the address and having the kernel take it away
> automagically is the ticket. That way CLOCK_BOOTTIME can be used...
Yes, that's sounds like the right thing to do. Thanks for the tip!
Thanks,
Daniel
------------------------------
Date: Mon, 14 Dec 2020 09:29:42 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] vpn: Do not do mixed declerations and code
To: connman@lists.01.org
Message-ID: <20201214082942.hjtq4q5w337c4...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
On Fri, Dec 11, 2020 at 03:11:18PM +0100, Daniel Wagner wrote:
> gcc complains 'struct vpn_route' is declared within the code section.
> By declaring it at the begin of the function we can also avoid the
> additional helper variables.
Patch applied.
------------------------------
Date: Mon, 14 Dec 2020 09:29:54 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] src: Test return value of inet_pton consistently
To: connman@lists.01.org
Message-ID: <20201214082954.faazcvmsy3fgg...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
On Fri, Dec 11, 2020 at 03:24:01PM +0100, Daniel Wagner wrote:
> inet_pton return 1 on success and 0 or -1 on failure depending on the
> error it wants to return. Use either '== 1' or '!= 1' consistently to
> test if the call was succesfull. ConnMan doesn't destinguish between 0
> and -1.
Patch applied.
------------------------------
Date: Mon, 14 Dec 2020 09:30:10 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] vpn: Export vpn_ipconfig_foreach as linker symbol
To: connman@lists.01.org
Message-ID: <20201214083010.ju3zzrkzxtl73...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
On Fri, Dec 11, 2020 at 06:02:41PM +0100, Daniel Wagner wrote:
> Commit 95b25140bec7 ("vpn: Add WireGuard support") introduced
> a plugin dependency to __vpn_ipconfig_foreach. Because the linker does
> not export the prefixed functions, we need to rename it to
> vpn_ipconfig_foreach in order to export the linker symbol.
Patch applied.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- connman@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org
------------------------------
End of connman Digest, Vol 62, Issue 20
***************************************
