I installed OpenWRT on a Netgear Nighthawk router. It's an excellent hardware and software combination. Thanks to some helpful tips here, I installed the full HostAPD package (wpad and hostapd-utils), configured manually, and it works. Sort of. There are a couple issues.
First, the boot order is wrong. It brings up the network (S20network) first, which brings up both the wired and wireless interfaces, then later brings up NTP (S90sysntpd). By the time NTP has set the time properly, hostapd has set up its initial clock, based on the old incorrect time (usually from the previous boot.) So the broadcast time is wrong.
I worked around this by adding a "sleep 60; /etc/rc.d/S20network restart" to /etc/rc.local. It's a kludge but it works. Is there a more elegant way? It seems like, ideally, it would start up the wired interface, then bring up NTP, then start up the Access Point.
Second, even with the restart, the time is off by about 7 seconds. I believe this is because of the real time to start up hostapd, sampling the system clock and then (7 seconds) later setting the Access Point's TSF timer based on a stale clock.
It would be good to synchronize the clock with the TSF at startup, but I haven't found the right place in the code where this happens. I suspect there is some interface with the firmware that I don't understand, but I can't find any references to the TSF Timer in the hostapd code at all.
Where to go from here? Should these be reported as bugs somewhere?
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.
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?
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:
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.
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)
Interesting.
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
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).
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?
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.
