Openwrt Tor client time synchronization

Hello Forum,

I followed these instructions from the documentation to route all my client traffic through tor.

Router: GL-inet GL-MT300N-V2
OpenWRT: OpenWrt 23.05
Tor Client: latest version

Its working correctly. My traffic and my DNS requests are sended over tor.
The only Probleme is that my router cannot "remember" the time after a restart. The clock sets back to the installation date and time after a reboot. I do not want to use a public NTP server.

Now I have to sync the time manually with the "sync with browser" Button (My browser gets its time from my host and my host gets its time from sdwdate) after this I need to do "service tor restart" on the ssh console of my router and then Tor is starting without the time error.

Log after a reboot:

daemon.warn Tor[1376]: Received microdesc flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by X days, X hours, X minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.

Is there a solution for this without using a public NTP Server?

The common approach would be using a time server, either a public one or a private ntpd instance in your own network.

Alternatives involve (battery backed) rtc addons or radio (e.g. DCF77)/ GPS based time sources.

1 Like

Can you use a local / private NTP server?

Thank you for your answers :slight_smile:

I thought about an local NTP server too but the problem is that I don´t know where to host this service. If its on my PC this could make thinks a little easier since I only have to remember starting my PC first and then my router. I think I will give this a try.

How do you realize such a battery backed rtc solution for a cheap router like mine?

If you have a Win or Linux host on your local network with a rtc, you could set it to serve time from it’s clock to your router.Then you add your service tor restart to /etc/rc.local.

you can attach rtc to spare gpio pins.
or buy usb gps dongle
or both.

Apart from the example above, the easy option would be adding a GPS receiver or (e.g.) DCF77 receiver via USB.

…but anything running linux can provide a local ntpd instance, even an esp32 could.

My approach would probably be a USB GPS receiver, they are reasonably cheap (<10 EUR delivered) and keep it all working self-contained on the router. An I²C RTC/ using GPIOs 4, 5 45, 46 would also be neat, but requires a bit more tinkering (hard- and software) than plugging in a ready-made USB GPS receiver and installing the ntpd software. Obviously a combination of both would yield 'perfection', the question is always about what's good enough.

…and in practice, I cheated, by using an x86_64 system as my router, which comes with a battery backed RTC by design.

1 Like

…I’m frugal

Not really, I paid less for the ((almost un-)used) x86_64 system, than it would cost me to get a gl-mt300-v2 delivered (before even thinking about I²C RTCs or GPS receivers).

…and I didn't buy it for RTC features (neither do I use it for tor or VPN tasks or anything else that would need a correct time base before being able to query a remote ntpd), but because I needed (sqm/cake) performance (something mt7628 would not be able to deliver, not by more than an order of magnitude). x86_64 does not need to be expensive (even new alderlake-n/ n100 systems aren't, in comparison to more traditional routers that could achieve similar performance), nor does it need to be wasteful in terms of power consumption (mine uses less idle power than my AP).

Frugal as in using what I already have available that can accomplish the task at zero cost.

Yes there are linux systems in this network but nothing that is used like a server. This setup (PC + Router) is only started if needed. And for reasons I had to setup my local ntp server in a vm. So before I start my router I need to start the host and wait for the vm to boot (which is not that much time but I simply not want to remember which device I have to start first). So I came to the conclusion that this is not the right way for me. The router has to get his time by itself somehow.

I will consider this, thank you.

I did a bit of research after your posting and found a device with model number "VK-172" that seems well documented and is even cheaply available. Do you have experience with sync times with such a gps dongle? Does it take as long as a gps location sync with a mobile phone?

And I found a "USB RTC for Raspberry Pi" device that some stores have. This device has a slot for one of these flat pancake like batteries that are one most computer mainboards too. If some device like this could work with openwrt and my gli net router?

yes I am even think about getting a different hardware solution with a build in rtc. But if I can make it work with my existing hardware and a cheap dongle it would be nice too. And maybe I can learn something.

I am too thats why I live with a device that can deliver blazing fast 10 Mbits avg downstream with openVPN :smiley: And with Tor 1 Mbits at best :smiley:

Are you telling us that your router is the only active device in your network in your default use case?

Builtin RTC is very rare. The addon board is 3.3v as in ESP32 and arduino worlds. That is if you have nearby geek store.

Yes. This is a travel router which is commonly used only by a few clients. And in my case it is only one client. And like I said its not a good workflow if I have to start a client with an build in rtc only to sync the time for the router. So the router has do know the time. Its is my goal for this use case.

And I can´t understand why. In some parts of the world the ISPs NTP feds manipulated time information so you can´t use tor network or other NTP servers that easy. Not to mention a situation where you have no internet connection at all and want to run a network for a local facility or something like that. For me its strange that a router (which is basically a normal computer) does not have a literal clock.

Got it. :exploding_head:

Tried gps, outside mount. That still took forever to give a good fix given where I am in a literal hole in a bush. I know you don’t want to use public time services, but wonder if ntpdate pointed at the ip of in rc.localmight work in a pinch.

On a side note, the OpenWrt One project might interest you with it’s onboard rtc.

1 Like