On Fri, 2016-04-22 at 10:02 -0500, Dan Williams wrote:
On Fri, 2016-04-22 at 16:40 +0300, matti kaasinen wrote:2016-04-22 16:12 GMT+03:00 Beniamino Galvani <bgalvani redhat com>:Do you mean that the board is getting a different address at every boot? In order to reuse the same lease, a persistent connection must be used (i.e. a connection written on disk and not the in-memory one automatically generated by NM at every boot).Usually it gets that old address at boot but changes it soon after that. My board is using NTP time, so I suppose this happens after NTP time synchronization if the original time was corrupted.On boot there's likely a valid lease from the previous run which can be renewed. When the time jumps forward, dhclient notices this and must expire the lease because it is no longer valid. dhclient has no choice but to enter the DISCOVER state and acquire a completely new one. One workaround: http://billauer.co.il/blog/2012/10/dhcp-ip-ntpdate-rtc/ It does seem a bit odd that dhclient cannot re-acquire the lease; I'm not sure if it's allowed by the standards to renew an expired lease or not. But you could argue a chicken/egg problem where DHCP delivers your NTP servers which then cause the time to jump forward which then kills the lease. So it seems like something to check into with dhclient and whether they have improved things here in recent releases.
Not sure that is related, but dhclient also gets confused when resetting the systemtime: https://bugzilla.redhat.com/show_bug.cgi?id=1093803#c13 Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part