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 <[email protected]>: > > > > > > > > > > > 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
