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 ***************************************