CODEWITHSUNDEEP
iosobjective-ctimentp
Leonardo Marques
Leonardo Marques

Reputation: 3951

iOS-ntp returning same value as device

I'm using the iOS-ntp framework and I'm getting a weird behavior that I cannot understand. Currently its 13:14 but I changed the time on the device to 13:34 when I make the folioing calls:

NSDate *deviceDate = [NSDate date];
[NetworkClock sharedNetworkClock];
NSDate *networkDate = [NSDate networkDate];
NSLog(@"deviceDate  =%@", deviceDate);
NSLog(@"networkDate =%@", networkDate);

What I get is:

deviceDate  =2014-05-13 13:34:37
networkDate =2014-05-13 13:34:38

Obviously I expected:

deviceDate  =2014-05-13 13:34:37
networkDate =2014-05-13 13:14:38

How am I getting the same date value?

Thanks in advance.

EDIT: Snooping the connection I intercepted this packet from the server to the app:

Network Time Protocol (NTP Version 3, server)

Reference ID: 212.82.32.15

Reference Timestamp: May 16, 2014 14:56:40.999638000 UTC

Origin Timestamp: May 16, 2014 18:25:02.688373000 UTC

Receive Timestamp: May 16, 2014 15:15:14.862829000 UTC

Transmit Timestamp: May 16, 2014 15:15:14.862889000 UTC

After this the framework call returns 18:25

Upvotes: 1

Views: 1100

Answers (1)

Anya Shenanigans
Anya Shenanigans

Reputation: 94829

Edit It turns out that the lack of the config file was not the problem in this case. Please read further.

There is logic in the algorithm to decide that certain time stamps are invalid; this is used to determine if the time can be trusted. This decision is made by determining if the server clock was set less than 1 hour ago. It uses your current time as the reference point.

When I skew my clock forward by a couple of hours (and I'm currently in UTC+1 (Summer Time)), I never get a sync, because this time will always be out by at least a few hours, i.e. the test for this will never get a good value.

If you comment out the check that:

(-[[self dateFromNetworkTime:&ntpServerBaseTime] timeIntervalSinceNow] < 3600.0)

in the evaluatePacket method NetAssociation.m, you avoid this check, and can get a wider degree of offsets. I've linked a github reference to the patch that accomplishes this in relation to the master.

Being unable to sync with NTP once your clock is significantly out of whack is what can be considered a safety feature, but because we're just using it to calculate the delta between the system clock and the network clock, it doesn't actually give us anything in this case

It's relatively poorly documented in the framework, but you need to copy the ntp.hosts file from the framework resources directory into the project that uses the framework, and ensure that the file is copied as part of the Copy Bundle Resources part of the app's Build Phases.

If you don't copy the file, the framework has no time references to use and so never determines the offset to use, resulting in the OS time at all times.

The cocoapods version of the framework doesn't use this configuration file, and instead has the method networkDateWithServer:(NSString *)server, which allows you to explicitly specify the NTP server to use.

The framework could probably react in a more appropriate manner (e.g. logging the lack of the file) rather than just carrying on, but that's a design decision.

Upvotes: 2

Related Questions