|
|
On Wed, 9 Nov 2005, Jason Haar wrote: > Jason Keltz wrote: > > In your case, the time is always going forward (at least that is what > > you would expect), but in this case, the time went backward! I'm > > wondering even if ntpdate hadn't made a change at that time whether > > when ntp made an eventual adjustment to the time whether this would > > cause a problem. > > > > I wonder why there is no effect for you... James? > > I can't answer for James, but it *should* actually do any time checks as > UTC - that way there are no daylight saving issues/etc. The local clock > changes forward/backward by an hour, but no change occurs in UTC. > > If OpenVPN (internally) uses UTC (or unixtime) there should be no issue OpenVPN uses the time() function for speed and portability, which is basically the number of seconds since a reference point back in the 1970s. It doesn't appear to be skewed by different time zones, not sure about daylight savings time effects. OpenVPN is in fact sensitive to time backtracks -- in the worst case, the replay protection code could lock up the tunnel. The current 2.1 branch has a small change (not yet backported to 2.0) which will not update OpenVPN's internal representation of the time unless the new time would be greater than the previous representation. This forces the internal time to never backtrack. If the system clock backtracks, the internal time will hold at the same value, waiting for the system clock to "catch up" before it starts incrementing again. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |