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
(Holesch, Simon (GED-SDD1))
2. Re: WireGuard plugin doesn't work: __vpn_ipconfig_foreach: symbol not
found
(Evgeny Zinoviev)
3. Re: gdhcp: Make DHCP client timeouts suspend aware (guy...@me.com)
----------------------------------------------------------------------
Date: Thu, 10 Dec 2020 10:42:40 +0000
From: "Holesch, Simon (GED-SDD1)" <simon.hole...@bshg.com>
Subject: Re: gdhcp: Make DHCP client timeouts suspend aware
To: "connman@lists.01.org" <connman@lists.01.org>
Cc: "conn...@connman.net" <conn...@connman.net>
Message-ID: <20201210104240.ga6...@rbgwcw0251.bsh.corp.bshg.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Dec 10, 2020 at 09:23, Hugo Portisch wrote:
> Hi,
> I found no other way to create a issue like on GitHub.
> It's about this commit:connman/connman.git - Connection Manager
Hi,
I guess this is the best way to reach out.
> Why DHCP timeout alarm timer should run in suspend/power off status??
The issue this commit was trying to solve is, that the client kept the
IP address even after the lease expired. The timer that was previously
used, stops completely during suspend and resumes after wakeup. This
behavior could cause the DHCP server to assign the same IP address again
and you'd have two clients with the same address.
Here are the relevant parts of RFC 2131:
> 4.4.5 Reacquisition and expiration
> If no DHCPACK arrives before time T2, the client moves to REBINDING
> state and sends (via broadcast) a DHCPREQUEST message to extend its
> lease.
> [...]
> If the lease expires before the client receives a DHCPACK, the client
> moves to INIT state, MUST immediately stop any other network
> processing and requests network initialization parameters as if the
> client were uninitialized.
One option would be to use CLOCK_BOOTTIME (instead of
CLOCK_BOOTTIME_ALARM, see timer_create(2)), which continues to run
during suspend, but doesn't wake up the system. But I'm not aware of a
way to prevent the client to use the IP address right after wakeup.
That's why I used the CLOCK_BOOTTIME_ALARM clock.
> When a device is sleeping and or powered off it should remain sleeping and
> not wake-up by a DHCP timeout.Therefor is a WOL package to wake-up the system
> over network. There is no reason to request DHCP updates when sleeping!
> We have now the issue if our users (+20k) do have a device with a RTC
> assembled he can not power off or send the device to suspend anymore.These
> alarm timers for DHCP wake up the device within 1-5 minutes.
> This behavior is not acceptable! There is and was never a reason why keeping
> the timeout timer running when the device is in a low power mode.
> The option to remove CAP_WAKE_ALARM in connman.service does not solve the
> issue. It even make it worse as there are no DHCP updates request send at all.
Yes, without the capability, the client isn't allowed to create the
CLOCK_BOOTTIME_ALARM timer.
> So only way is to revert this commit.
Another idea, not sure if acceptable: Can the client release the IP
address before going to low power mode? Alternatively we could use
CLOCK_BOOTTIME to not wake up, but this isn't completely conformant with
the RFC.
> Please feel free to add a issue on your tracker https://01.org/jira/browse/CM
> as I am not able to register and login!
>
> Thank you very much,Team CoreELECPortisch
>
------------------------------
Date: Thu, 10 Dec 2020 16:18:23 +0300
From: Evgeny Zinoviev <m...@ch1p.io>
Subject: Re: WireGuard plugin doesn't work: __vpn_ipconfig_foreach:
symbol not found
To: connman@lists.01.org
Message-ID: <dcb0872b-ea70-3fc3-18b6-c9efc759a...@ch1p.io>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel. I think it's GNU ld linker. I checked Void Linux's build
system, built the package myself and couldn't find any evidence that it
uses gold linker in the process of building connman.
On 12/4/20 3:56 PM, Daniel Wagner wrote:
> Hi Evgeny,
>
> On Wed, Dec 02, 2020 at 03:24:46PM +0300, Evgeny Zinoviev wrote:
>> Hi everybody.
>>
>> I'm using connman 1.38 on Void Linux with musl-libc. I was trying to connect
>> to my WireGuard VPN using connman but the wireguard plugin crashes on load:
>>
>> 2020-12-01T20:51:31.96059 daemon.err: Dec 1 20:51:31 connman-vpnd[502]:
>> Can't load /usr/lib/connman/plugins-vpn/wireguard.so: Error relocating
>> /usr/lib/connman/plugins-vpn/wireguard.so: __vpn_ipconfig_foreach: symbol
>> not found
>>
>> Everything else is working fine.
> There were a bunch of reports about this but we could never really pin
> point it down. The quick workaround is to build the plugins as
> 'builtin'. This avoids the module code.
>
> As far I can tell it's something with the linker. What linker do you
> use? Is the gold linker?
>
> Thanks,
> Daniel
> _______________________________________________
> connman mailing list -- connman@lists.01.org
> To unsubscribe send an email to connman-le...@lists.01.org
------------------------------
Date: Fri, 11 Dec 2020 05:57:49 -0000
From: guy...@me.com
Subject: Re: gdhcp: Make DHCP client timeouts suspend aware
To: connman@lists.01.org
Message-ID: <20201211055749.2885.38...@ml01.vlan13.01.org>
Content-Type: text/plain; charset="utf-8"
You may want to change the code to trim DHCP renew intervals to something that
is acceptable for your application. DHCP servers can be configured to give very
short DHCP leases which appears to be the case in your scenario. I have worked
on connman based solutions for sleepy battery operated devices where we don't
honor DHCP intervals less than one hour. But to ignore them completely can
lead to serious problems where another device gets assigned your IP address. In
the short-term, perhaps your user can increase the DHCP timeout. In a study of
a large number of DHCP servers, the bulk of them will be set to 24 hours. Short
DHCP leases are one of the evils that battery operated and/or sleepy devices
need to account for and plan for. Hope this is helpful.
-g
------------------------------
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 14
***************************************
