Set the router clock with a GPS receiver for under $70

[kvic]

I will not be doing that.

The threat of having my NTP server used in a DDoS is too great. The config of the official NTP daemon has never made sense to me, especially the encrypted/secure peering.

Within the past year, Cloudflare was hit by a 400Gbps (!?!?) DDoS that employed NTP amplification.

I haven't thought of that...interesting. I dug up the cloudflare article about the 400Gbps attack. It's a good read.

It's a bug in command MONLIST of the NTPD. MONLIST reports the last 600 IP addresses that contact a NTPD server. Such a response is 206 times bigger than the request. An attacker spoofs its source IP address of the victim, and send MONLIST request to vulnerable NTPD servers. Hence, the amplified DDoS.

The bug has been fixed since NTPD ver 4.2.7p26. I checked mine, ver. 4.2.8p3). So should be fine here..but who knows what other bugs there might be. So perhaps worth a secure handshake if decided to open to a local community.

Phones need to acquire a GPS fix very quickly during E911 to get a decent area of uncertainty/probability... so they don't have that huge amount of time to search for SV's (there is a network PDE function that takes into account the AFLT cell-site rough fix to limit the SV search to get that quick-fix). So time is very important, not just for general CDMA call processing, but for E911 requirements in the US (and perhaps other countries)

Because of this, old mobile phones can be a decent time-reference, even without an active subscription...

SV..space vehicle? I thought PDE is partial differential equations. It's not but Position Determination Entity. AFLT...Advanced Forward Link Tri-lateration. WAAS..Wide Area Augmentation System. Thanks for the very nice alphabet soup..I need to look up dictionaries. lol (This ZTE article is a good survey of cellular positioning methods and demystify a few acronyms.)

The phone itself may get and keep accurate time. By the time, the clock is synced to the router over ethernet it's through NTP protocol. That's quite different from attaching a GPS receiver to the router through a serial interface. If the phone's clock or its GPS module can be connected to the router though a serial interface, perhaps it makes a difference.

 

[sfx2000]

Sorry, I'm bit more of a GPS geek than an NTP nerd

At the end of the day, it's all about time, eh? It was the GPS work that got me interested in high-resolution timing, and to this day, use the lessons learned to keep my servers in various locations all sync'ed up.

alphabet soup...

PDE - magic box from Qualcomm/SnapTrack that takes cell-site almanacs (cells generally are pretty much fixed in space, and time is distance from the cell site) and compares to GPS satellite almanacs to get a quick lookup

AFLT - using the cell-site searcher element, report all cells/sectors within range, and if possible, chip delay to those sites - good enough to get a coarse 2-d location...

Old-school GSM used this, CDMA IS-2000 went the next step...

The PD can take that info, and report to the handset's GPS element exactly which GPS birds should be visible, along with the appropriate long/short codes, and this hot-starts the GPS element - usually resulting in a 3-d fine location within 50 ft of ground truth within 12 seconds...

Pretty cool tech - and it's been around for some time...

Newer stuff is even more awesome

 

[ASAT]

My weekly plots. This is Asuswrt-Merlin running NTPD for clock synchronization, sourced from only a GPS receiver (NEMA+PPS). No Internet connection is required for clock synchronization.

 

[ASAT]

My other weekly plots.

 

[sfx2000]

Still a bit of jitter there - wondering if increasing the Total and Coherent Integration periods might settle that down a bit...

 

[sfx2000]

This might help with the uBlox Neo-7N receiver...

https://www.u-blox.com/sites/defaul...verDescrProtSpec_(GPS.G7-SW-12001)_Public.pdf

Taking that info, and then using ublox u-center, one can tweak the receiver quite a bit - since this is a stationary installation, there are modes that work "better" than the typical default configs.

 

[ASAT]

For your amusement here's the pictures. Now you can see how to synchronize the router's clock from a precise GPS time source, without an Internet connection.

Connected to the Asuswrt-Merlin router.

• USB cable, connected to the Asus RT-AC68U USB 2.0 port
• FT232RL usb-to-serial converter, yellow LED, clear heat shrink tubing
• RJ45 short cable soldered to the FT232RL pins: VCC, GND, TRX, RCV, DCD (No Ethernet here!)
• RJ45 coupler
• CAT6 cable, 35 meters long going to roof of building

Up on the roof of the building outside.

• Plastic box + Silicone sealant
  
• PVC pipe + elbows + zip ties
• CAT6 cable, 35 meters long coming from inside the building from Asus router
• RY725AI GPS receiver module is inside the sealed plastic box

 

[Lost Dog]

Ok... I have to ask. Why?

I've been following this whole thread but for the life of me I can't figure out why you'd need to do this. I read post #9 but it still does not explain why.....

Fantastic stuff and interesting to read.

 

[ASAT]

Ok... I have to ask. Why?

It is for my network of 33x IP cameras, inside and around the building. So the timestamps in the video feeds are all in sync with the correct time. It is my security surveillance system. Where I live, the Internet time sources is not very reliable. GPS time is always available, even without an Internet connection.

 

[Nullity]

Ok... I have to ask. Why?

I've been following this whole thread but for the life of me I can't figure out why you'd need to do this. I read post #9 but it still does not explain why.....

Fantastic stuff and interesting to read.

Why not? (disregarding the obvious scenerio where there is no internet to sync time with)

I have wondered this myself. AFAIK, there are no commonly used consumer-level services that fail because of a few milliseconds of timing inaccuracy.

The only service I have seen mentioned on this forum that requires accurate time (within ~30 minutes, not milliseconds) is Tor.

 

[RMerlin]

Why not? (disregarding the obvious scenerio where there is no internet to sync time with)

I have wondered this myself. AFAIK, there are no commonly used consumer-level services that fail because of a few milliseconds of timing inaccuracy.

The only service I have seen mentioned on this forum that requires accurate time (within ~30 minutes, not milliseconds) is Tor.

Active Directory can also be quite picky with timing. I had a customer who ran into issues because his NAS's clock had skewed too far away from their PDC, so users were no longer able to authenticate against the AD when trying to access a network share. But once again we're talking more than just 2-3 minutes here.

 

[Lost Dog]

It is for my network of 33x IP cameras, inside and around the building. So the timestamps in the video feeds are all in sync with the correct time. It is my security surveillance system. Where I live, the Internet time sources is not very reliable. GPS time is always available, even without an Internet connection.

Cool... makes perfect sense. Fantastic seeing workarounds like this!

 

[sfx2000]

@ASAT - well done - fun project - having a Stratum 1 Time Source is very handy, and sharing it across the LAN via NTP has very practical applications for keeping devices and log files/time stamps synced up.

Perhaps take to the next step with syslogd on an external drive

This is a good use for an older Router/AP that has been taken out of service (as part of the normal upgrade cycle), if the device can run OpenWRT - this is a great way to put something that would otherwise be recycled or set up on the shelf somewhere.

For those that do not have an Asus Router, RasPI is a good alternate - this is how I'm likely going to implement.

Via the Google, I found this - http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

 

[ASAT]

RasPI is how I'm likely going to implement. http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

The Raspberry Pi is the best way. The PPS output of the GPS module is wired to a GPIO pin on the Raspberry Pi, instead of the DCD pin on a usb-to-serial converter. So it is much more precise because there is no USB latency for the PPS signal. It goes direct to GPIO. I believe Raspbian Linux has kernel support for PPS+GPIO.

I finally bought another Raspberry Pi to try this and much more.

 

[kvic]

If planning to go for another round, I would suggest getting RY825AI instead. It additionally supports Beidou and Galileo. The systems by China and Europe. By 2020, both are expected to have global coverage. 825AI comes with built-in antenna for Beidou (not Galileo unfortunately). A study (which I no longer have it handy) found combining multiple systems will increase accuracy on positioning (not sure about time) compared to any single system.

 

[kvic]

I realised a typo in my NTPD build command. "--disable-deugging" instead of "--disable-debugging". lol. Also missed another option "--enable-accurate-adjtime"

With these two amended, runtime RAM usage further down to ~600KiB (from >1MiB..hooray!). Also spikes in both offset and jitter seem to be under better control.

The amendment applied some time between Oct 26 and 27.

 

[sfx2000]

If planning to go for another round, I would suggest getting RY825AI instead. It additionally supports Beidou and Galileo. The systems by China and Europe. By 2020, both are expected to have global coverage. 825AI comes with built-in antenna for Beidou (not Galileo unfortunately)

I'd consider Beidu and Galileo support optional as the constellations aren't fully built out at the moment - having GPS/GLONASS is sufficient - a nice tick-mark would be WAAS support, as it does provide a level of timing/position improvement in North America on top of what the GPS/GLONASS platforms provide.

Couple of interesting links...

http://www.nstb.tc.faa.gov/sms/

http://www.faa.gov/about/office_org.../service_units/techops/navservices/gnss/waas/

 

[kvic]

Digest in a single page..interesting numbers:

Error        Value
Ionosphere   4.0 meters
Clock        2.1 meters
Ephemeris    2.1 meters
Troposphere  0.7 meters
Receiver     0.5 meters
Multipath    1.0 meter
Total        10.4 meters

 

[ASAT]

Also missed another option "--enable-accurate-adjtime"

And I think this one enables libevent pthreads: "--enable-local-libevent"
Otherwise, you need to link to an external libevent package?

 

[kvic]

And I think this one enables libevent pthreads: "--enable-local-libevent"
Otherwise, you need to link to an external libevent package?

I don't have this flag enabled. I also don't have pthread support compiled in.

My rationale is that for a small LAN like a home, the loading on NTPD is tiny. It saves both binary size and runtime RAM usage.