I am working to get as many devices on my network to use my local Stratum 1 NTP servers instead of relying on the internet. Where does Tempest get its time config from, and can it be configured?
Does it get the config from NTP? How often does it poll the NTP server?
Thanks!
Last report that I heard was that it uses a hard-coded NTP server, ignoring anything presented by DHCP…
That’s a shame. Would love to see some future additions of a way to set a custom NTP server
Doing a packet capture, it looks like it is querying the DHCP provided servers
17:27:31.595074 eth0 In IP 10.0.0.37.123 > 10.0.0.6.123: NTPv3, Client, length 48
I also have a Stratum 1 NTP server and used to try capturing and re-writing the UDP time request to route to my NTP server. Caused more harm than good. All my security cameras stopped working and other IoT devices never booted. It seems like IoT devices, and their coders don’t want to support other sources of time especially if they are sensitive to differences across devices.
Ignore what I said about it using DHCP, its possible that is a red herring. I have another device IoTaWatt that I saw doing the same, however the application itself does not use the hosts NTP and has its own NTP stack. So I think a packet capture doesn’t prove anything either way
You need to capture traffic from the Hub and see if it connects to ‘anywhere’ other than WeatherFlow servers. Reserve a known stable DHCP address for the Hub’s mac address. Start your sniffer listening for traffic from the Hub. Power reset the Hub. See what you see.
Come to think of it, my aging memory recalls that the Hub doesn’t even have an NTP client module installed. It gets the time from the WF mothership via a web protocol. Feel free to search the forum to validate my recollection…
That is my recollection as well. The Hub tunnels to WF and everything goes through that tunnel. That’s why all the questions of ‘how does a WF system work if there’s no Internet’ come up.
A clean from-power-reset packet capture would tell the authoritative tale…
This is a capture of the dhcp discovery
The device does a request of the listed values and, if you pass them back it uses what you pass. I haven’t checked without passing option42 but it does use the all of the values I pass back from my dhcp server.
It also does IPv6 ICMP neighbor and router solicitation. So it appears to have some, if not full support for IPv6 as well. I’m not running IPv6 at the moment.
It doesn’t matter what the DHCP stuff does. What matters is whether the firmware has a hard-coded NTP server to query at the os level.
Do they specifically hit something like time.weatherflow.com (which ‘does’ exist, interestingly) in their NTP configuration under the hood, or does it do something through the tunnel that they establish between Hub and the WF servers…
You need to kill your WAN and power the Hub down/up while sniffing to see what it tries to do without Internet is available when it boots up. In the past multiple people did this which is why some of the original users here are trying to explain what was found way back when…
DHCP will provide a local NTP and DNS server if the dhcp service is configured/capable of providing that information.
The firmware hardcoded values I observe on my unit for ntp is 4.0.0.0 and dns is 8.8.8.8
It will use the dhcp supplied dns and ntp settings if they are present.
For DNS it will use 8.8.8.8 and the dhcp supplied DNS server.
In terms of time. It is likely that this is being pulled programmatically from the MQTT flow programmatically as the address 4.0.0.0 does not provide an NTP service.
When the NTP service ip address provided by dhcp the system starts broadcasting weather station obs and some administrative stats to the local LAN with the correct timestamp prior to any connectivity having occurred to the WF servers.
When there is no local NTP supplied the call to ntp on 4.0.0.0 and there is no evidence of separate calls to another ntp servers. Other prosumer/consumer products will not hardcode NTP ip address but will hardcode DNS addresses that provide a list of NTP servers from a the public pool.ntp.org farms. This behaviour was not observed here.
The MQTT connection sequence is started 6 seconds after the NTP service session completes.
In having NTP settings supplied by DHCP the startup sequence is a little less chatty (60 vs 120 packets) and the data broadcasts have correct timestamps from the outset making the data easier to use programmatically.
When DHCP NTP is not set the data broadcasts occur but the observation timestamps are set to equal the uptime counter in seconds. The MQTT session syncs up the clock at around 30 seconds after the failed call to the hardcoded NTP ip address.
I would conclude that a local NTP service would be most advantageous if you have a local console/automation/logger that gets its data from the Hub’s LAN broadcasts as opposed to the cloud.
The only DNS calls observed have been to mqtt.weatherflow.com. I checked through several months worth of records to confirm this.
There is no tunnel, the connectivity is done via an authenticated mqtt session and the payload is sent in the clear.
Thanks. I probably used the term ‘tunnel’ a bit loosely. I meant the session it establishes with the wf servers. The hostname mqtt does ring a bell. It’s just been so long the memory fades a bit, and I don’t have WF hardware any more so I can’t test current firmware here.
Some questions…
You lost me there. You are suggesting that they mqtt_subscribe to a topic from the WF MQTT servers to get the time ?
This is a good find for LAN-only weewx and wfpiconsole (UDP mode) users. Provide a local NTP server and set your DHCP to point there and LAN-only can happen immediately.
What are ‘some administrative stats’ specifically ?
Further to my earlier data, time from the hub does not conform to full NTP as it does not make use of more than one NTP server if it is provide more than one. That indicates that the system is using SNTP which is packet compatible with NTP. An SNTP update occurs once every 4 hours.
Read about SNTP vs NTP here: SNTP: All You Need To Know! | TimeTools
As for administrative stats. A couple of packets around wifi rssi which could be useful for debugging and monitoring if you use a locked down AP that doesn’t give this kind of info.
The time is published via WF mqtt system at an interval of approx 10 minutes and the hub receives that data with an accuracy of between 200 to 1500ms depending on network conditions.
I’m not going to reverse engineer their entire traffic flow for them. This response answers more completely what the original question asked.