Comments on: DHCP changing the IP address suddenly on embedded systems https://billauer.se/blog/2012/10/dhcp-ip-ntpdate-rtc/ Anything I found worthy to write down. Thu, 26 Mar 2026 13:15:15 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: Xavier https://billauer.se/blog/2012/10/dhcp-ip-ntpdate-rtc/comment-page-1/#comment-1328 Xavier Wed, 02 May 2018 09:42:58 +0000 https://billauer.se/blog/?p=3206#comment-1328 Hi ! thanks all this explanation. It was helpfull for me to find out what's wrong on my laptop. I've had the same kind of issue... only when I'm out of my country. At home, everything is fine. When I arrive in India, I've got the same problem than you. With same message on syslog. It only needed for me to set up time on my computer to .... local time and reboot. And then, everything is fine. Hi !

thanks all this explanation. It was helpfull for me to find out what’s wrong on my laptop.

I’ve had the same kind of issue… only when I’m out of my country.
At home, everything is fine. When I arrive in India, I’ve got the same problem than you. With same message on syslog.

It only needed for me to set up time on my computer to …. local time and reboot.
And then, everything is fine.

]]> By: Jean-Francois Dockes https://billauer.se/blog/2012/10/dhcp-ip-ntpdate-rtc/comment-page-1/#comment-1300 Jean-Francois Dockes Tue, 07 Nov 2017 14:50:58 +0000 https://billauer.se/blog/?p=3206#comment-1300 This does not work for me without editing the leases file to fix the dates. So for an even uglier, but working, hack, you can use the following shell function. It sets all dates to next year in the leases file. It seems that they will be reset to correct values in dhcp-lease-time seconds anyway (as far as I can see). I am not going to even pretend that this is very robust, but it seems to solve this very vexing problem for me. fixleases() { year=`date +%Y` year=`expr $year + 1` dt=`date +"$year/%m/%d %H:%M:%S"` leases=`echo /var/lib/NetworkManager/dhclient-*.lease` #echo LEASES $leases sed -i \ -e "/^ *renew/c \\ \\ renew 2 ${dt};" \ -e "/^ *rebind/c \\ \\ rebind 2 ${dt};" \ -e "/^ *expire/c \\ \\ expire 2 ${dt};" \ $leases } This does not work for me without editing the leases file to fix the dates.

So for an even uglier, but working, hack, you can use the following shell function. It sets all dates to next year in the leases file. It seems that they will be reset to correct values in dhcp-lease-time seconds anyway (as far as I can see). I am not going to even pretend that this is very robust, but it seems to solve this very vexing problem for me.

fixleases()
{
year=`date +%Y`
year=`expr $year + 1`
dt=`date +”$year/%m/%d %H:%M:%S”`
leases=`echo /var/lib/NetworkManager/dhclient-*.lease`
#echo LEASES $leases

sed -i \
-e “/^ *renew/c \\ \\ renew 2 ${dt};” \
-e “/^ *rebind/c \\ \\ rebind 2 ${dt};” \
-e “/^ *expire/c \\ \\ expire 2 ${dt};” \
$leases
}

]]> By: Matt https://billauer.se/blog/2012/10/dhcp-ip-ntpdate-rtc/comment-page-1/#comment-843 Matt Thu, 07 Feb 2013 19:10:25 +0000 https://billauer.se/blog/?p=3206#comment-843 It doesn't matter if it is an ugly hack if it gets the job done. There are no points for style. It doesn’t matter if it is an ugly hack if it gets the job done. There are no points for style.

]]> By: Baruch https://billauer.se/blog/2012/10/dhcp-ip-ntpdate-rtc/comment-page-1/#comment-804 Baruch Wed, 10 Oct 2012 13:50:18 +0000 https://billauer.se/blog/?p=3206#comment-804 I believe most monotonic clock implementations are also irreverent of time jumps as they look at things like rdtsc and the like so their time movement is constant. At least it was on my tests on intel cpus. The implementation on arm devices may differ. I believe most monotonic clock implementations are also irreverent of time jumps as they look at things like rdtsc and the like so their time movement is constant. At least it was on my tests on intel cpus. The implementation on arm devices may differ.

]]> By: eli https://billauer.se/blog/2012/10/dhcp-ip-ntpdate-rtc/comment-page-1/#comment-803 eli Wed, 10 Oct 2012 12:36:29 +0000 https://billauer.se/blog/?p=3206#comment-803 The DHCP client is dhclient (as it says all over the post). And in my case, the clock jumped from 1970 to 2012, so it surely remained monotonic. This was not time moving backwards, it was time jumping. The DHCP client is dhclient (as it says all over the post).

And in my case, the clock jumped from 1970 to 2012, so it surely remained monotonic. This was not time moving backwards, it was time jumping.

]]> By: Baruch https://billauer.se/blog/2012/10/dhcp-ip-ntpdate-rtc/comment-page-1/#comment-802 Baruch Wed, 10 Oct 2012 12:30:07 +0000 https://billauer.se/blog/?p=3206#comment-802 Which dhcp client is it? you could consider modifying it to use a monotonic clock on the system. I recently had a similar problem with nut upsd where if the time was moved backwards it would stop monitoring the ups for the duration of the gap. I guess that this problem will be prevalent in many applications as well. Most times people do not assume the clock is really going to move in any other direction than forward and in a constant rate. Which dhcp client is it? you could consider modifying it to use a monotonic clock on the system.

I recently had a similar problem with nut upsd where if the time was moved backwards it would stop monitoring the ups for the duration of the gap.

I guess that this problem will be prevalent in many applications as well. Most times people do not assume the clock is really going to move in any other direction than forward and in a constant rate.

]]>