Repeated failure to retrieve time from NTP server

[9h1zz]

Mauro,

Today the situation is even worse - I cannot obtain a response from any of the listed servers.
All result in "GetLastError returned 10060". Even from the Swiss and Saudi sites, which worked yesterday.
The diagnostic log merely confirms that after 5 seconds, this message is generated.

I have tried running BktTimeSync 1.4.0 from yet another XP computer in a totally different location
with a different high speed (microwave link) ISP. The result is still the same.

All listed NTP sites respond to a "ping".
Using "tracert", all NTP sites report their access path. The only nodes in the paths I see
that are common to those which I examined from all machines (and locations/ISP) are interoute.net
84.233.225.121
89.202.146.97

After several years of successful use of BktTimeSync, I had been promoting its use
for other ham operators in Malta. I will contact them and see whether they are experiencing
problems. I had been informed a few days ago, by a new user here, that he was unable to
synchronize time on his PC using BktTimeSync.

Could it be possible that a new version of the server software is being introduced
or even that the system itself may have been hacked?
Should this problem be escalated?

73 Robin, 9H1ZZ

[iz2bkt]

I tried to reload on the server BktTimeSync, Please try to download and install it.

http://www.iz2bkt.com/BktTimeSync/BktTimeSyncEn.htm

[9h1zz]

I have reloaded, but the problem is still there. If anything, worse. Very frustrating.
Most of the NTP sites now return an error code 11004, but a few show 10060. Every minute.
One of the latter (Turkey) which I left running, suddenly reported successful synchronisation.
Those sites which I have checked, all return "pings" and tracert path listings.
I have checked with other users here in Malta and we all have similar problems with Bkt.
Some guys have now abandoned BktTimeSync and are using alternative software.
For us, right now, we find BktTimeSync is broken, unreliable and consequently unusable.
Can it be fixed?

Robin, 9H1ZZ

[iz2bkt]

The error 11004 is a problem with the DNS server does not resolve the name correctly.
The error 10060 is a timeout error.
It seems that BktTimeSync not work only in Malta, other OM have no problems, also, if the problem started a few days ago, the program has not had any changes.
I try to see if it can increase the timeout, but I need to test if I can do tester sending you private messages with various versions to try.

[9h1zz]

OK Mauro. I can test whenever you wish. Use my normal email
for any attachments.

As for timing, in checking the Diagnostic Log, when Sync does work, the "good" response appears in the log
within the same second as the request (reply < 1000millisecs?). When there is no response (error messages),
the log shows no return during 5 seconds. I have never seen any reports between these two extreme values.

Now, although I am not familiar with current Internet architecture, I have done some more research........
Generally, Internet connection/speed here is very good. Malta is physically linked by fiberoptic cables to Palermo.
Looking at tracert, I can see we are in fact always being directed to interoute.net in Palermo (84.233.225.121).
I would then expect that data would then be switched to an internal Italian node in Palermo for onward
routing to MIX (in Milano) and distribution in north Italy.
However the tracer shows that instead of an internal Italian node in Palermo, the trace is actually routed
to 89.202.146.97 which is in NORWAY !!
The requested domain name shown in tracert (xe-2-3-0-0.mil-cal-score-1-re0.interoute.net) apparently
does not exist (according to whois), so I assume that the default node chosen by interoute.net is the Norwegian one.
Somehow, the trace makes its way back to MIX and gets to Torino.
This unusual route could have some specific security restrictions which allow the tracer, but not real data.

If my reasoning is correct, this might explain the problem, and could be due to an incorrect routing table entry in Palermo.
Does that seem likely to you?
If you agree, I can ask my ISP to get GO Datastream (the Malta International Internet gateway) to investigate.

73 Robin

[iz2bkt]

Also I think tath the problem is in routings Internet from Malta seen then that the problem occurred a few days without updating the program and in other parts of the world it works well.

The timeout is set to 5000ms BktTimeSync and should be more than sufficient.

I tried to recompile BktTimeSync with a new compiler, but I do not think this solves the problem, you can download version 1.4.1 from :http://www.iz2bkt.com/BktTimeSync/BktTimeSyncEn.htm

[9h1zz]

Version 1.4.1 gives the same result. Access to Turkey NTP is still working today though.

Internet users don't have access to any network tools to check what is really happening.
MS-DOS commands like "ping" and "tracert" are really all we can rely on. "Whois" and
"Reverse whois" or other assistants like "isitup" can help a bit, but are not always updated.
Every time I look, I get different responses or access refusals.
Do you happen to know if there are any users of your TimeSync software near Palermo ?
Possibly we could use them to check access and routing from there.

I will complain again to my ISP, to see if they can find out what is happening and get it corrected.

[iz2bkt]

There are many users in Italy but BktTimeSync is free and I do not know in detail the call and locations.

In Italy when there are problems involving the ISP are very difficult to solve because the ISP's call center will always say that for them it is all ok.

[9h1zz]

Hi Mauro,

I contacted some users in several countries, and all confirmed that most NTPs (including inrim) were responding for them. From Malta, the only NTP giving consistent time responses was in Turkey.

I checked yesterday (and today) and suddenly all NTPs are responding again!!!!

Again I have changed nothing. Tracert performed on various NTPs show the same paths as before.
Pings all report, as before, with steady responses and 50-100 ms. The only conclusion I can reach is that an update has been made in mid-February to NTP server softwares or to interoute and that there was a bug, which has been recognized and is now eliminated.

Hopefully, this situation will not arise again, since we still do not know who/what was responsible for causing the problem (and curing it 2 weeks later!).

Thanks again for your help.

73 Robin, 9H1ZZ