Re: gdhcp: Make DHCP client timeouts suspend aware
by Holesch, Simon (GED-SDD1)
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
>