On Thu, Dec 10, 2020 at 09:23, Hugo Portisch wrote:
I found no other way to create a issue like on GitHub.
It's about this commit:connman/connman.git - Connection Manager
I guess this is the best way to reach out.
Why DHCP timeout alarm timer should run in suspend/power off
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
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
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
> Please feel free to add a issue on your tracker https://01.org/jira/browse/CM as
not able to register and login!
> Thank you very much,Team CoreELECPortisch