Time Advertisement on OpenWrt - bugs and misfeatures

Be aware that there is no solution to this. You need to have the network up for ntp to work, but there is now way to anticipate (and select an according service ordering) how long that takes (ethernet, static vs dynamic, PPPoE, LTE, ...) - and there's always the possibility that the WAN interface will 'never' come up (WAN cable disconnected, trouble with the ISP, etc.), waiting to start hostapd is not an option here, as you may need it to debug your WAN issues and/ or want LAN/ WLAN capabilities even without a functional WAN uplink.


Would it be possible to separate out the two network startups so the AP startup can be moved to after NTP starts?

No, if your ISP is down (cable disconnected, PPPoE rejecting, any reason at all), the WAN link will never come up - but you don't know that in advance, nor how long it will take to get an uplink. Changing the sysv sequencing won't help that (PPPoE will always take longer than busybox ntpd getting started), but at the same time you can't keep hostapd disabled forever.


Maybe I don't understand how the current set up (where it brings them both up in S20network) allows the AP to come up after a wired failure, but separating them would make the AP never come up after a failure. If anything, I'd expect the opposite.

How/why would you remove an AP from its VLANs and bridges coming up anyways?

Ummmmmm...What if the NTP server was reachable over the AP/WWAN connection instead...or a tunnel? :thinking:

Nonetheless, as @slh noted, this is normal behavior and seems like an attempt to solve one of those chicken-or-the-egg paradoxes of computing with embedded devices.

Well...there are solutions...if time were that serious to the user:

  • the OP needs a RTC with battery; or
  • perhaps can obtain the time from a GPS unit
  • A second device with battery backup

To be honest...I've seen few real-life business or consumer situations that required such high availability of network time.

1 Like

Running wifi with no parameters will restart the wireless without disrupting the rest of the networking. Also wifi will come back up a lot faster than after service network restart. See if that re-syncs the hostapd time.


An RTC with a battery would indeed be the perfect solution, just that basically none of the router like devices support this. GPS or radio clock receivers (e.g. DCF-77) would technically be easier to add (just expensive and maybe not quite up for the job in the typical mounting locations), but reading their status usually takes even longer than WAN to come up and ntp doing its job.


You might set the radio disabled, initially. After start of network, check WAN, and run NTP as a single shot, to adjust time. Then enable radio, and start wireless. Disable radio again in /etc/config/wireless.
A professional, expensive solution would be connection of a DCF-77 receiver via USB.

As mentioned before, on average this takes longer (at least 60s, in practice often around 3 minutes - even if your DCF-77 receiver comes with battery/ quartz backup, initializing it probably takes longer than connecting to WAN and~) than querying the exact time via NTP. This is a great (expensive) solution to get a highly accurate time base, but it's not a quick way.

This is very helpful. Way less overhead.

Now my workaround in /etc/rc.local end with: sleep 60 ; /sbin/wifi

In effect, the boot order is
bring up WAN
bring up WLAN (TA time is wrong)
bring up NTP (corrects system time but not TA time)
sleep 60
restart WLAN (TA time is better)

I used DCF-77 radio clocks already over 30 yrs ago, over serial, and over tcp/ip later on. Provided exact time base, after very few seconds, in worst case.
For a price :slight_smile:

You have to consider the case of the dcf-77 clock being completely powered off as well. Time- and date are encoded over a 60s datagram, so that's the minimum time it will always take to get the current time after powering up the dcf-77 clock, so statistically speaking 90s (as you won't always be lucky to start your clock exactly on a full minute) - more if your first decoding pass failed.

This situation obviously changes, if your dcf-77 clock is battery powered and merely keeps a quartz clock up to speed, then you can return results immediately (at least after the drivers have been loaded).

1 Like

OK, the Hopf clocks had quartz and battery backup. Pricewise not reasonable for openwrt-device.

Is there any software for OpenWrt to scan for and sync to a neighboring AP that sends a time reference? That's the point of this system-- receive time with only a WiFi radio even if you don't have access to its network.

Indeed this is the point. The WiFi AP should be an inexpensive, hopefully universal source of the time. The DCF-77 approach is interesting, but not applicable here. I've actually had terrible experience with WWVB clocks in San Diego, they pretty much only work outdoors.

My eventual goal is to put a software-only solution into OpenWRT that correctly implements Time Advertisement and is on by default. Getting it to work as advertised is the first step, and I'm found the "wifi" trick works pretty well.

However, this requires installing the full wpad package, which is not the default. Also, Luci doesn't seem to work 100% when full wpad is in place, and some CLI configuration is required. Can anyone shed any light on why a stripped-down version is installed by default, and what it would take to make the appropriate enhancement?

This is explained throughout the documentation for embedded devices. If you need advanced configurations like: enterprise, or whatever config you need wpad for - then hence you install it if your device has space.

Enhancement of what (kinda hard to guess; and you never say what it is your're trying to set)?


I'm trying to find RFCs or docs on this...can you provide a link, please?

It is part of IEEE802.11v which was developed around 2010 but only recently incorporated into hostapd.

Previous thread here: Non-Broadcom router recommendations for Time Advertisement

The beacon frame from an AP always included a time variable called TSF which is the number of microseconds elapsed since the AP started. It counts up continually and every 78 days it will roll over.

802.11v adds a data tag (Information Element) to the beacon frame which pins the zero startup time of TSF as an absolute GMT time and date. So by adding these two together, any WiFi receiver in range of the AP can determine the GMT time and date. In order for this to work, the AP needs to have a correct GMT clock. Additionally, it appears that hostapd only reads the system GMT clock once on AP startup and does not correct the TSF / IE if the clock later changes.

So hostapd as it stands now has a good chance of broadcasting an incorrect time, which is worse than no time at all.

Thank you for the explanation of the reason for the mini-hostap rather than the full one. I've been looking at the wpad mini source code, and I see the Time Advertisement code in src/ap/beacon.c. I'm wondering what is the reason that the full wpad package is required to support Time Advertisement? It would be very nice to use the standard wpad mini package.

Indeed, that's why I'm restarting hostapd with "wifi" after NTP sets the clock.

You make an interesting point about clock drift. The TSF timer isn't synchronized to NTP like the router system clock, so it might drift a bit over a long time. This seems like a design flaw in the IEEE standard, but a minor one. It should be easy to have, say, a cron job that restarted wifi every day or so.