I’m having real trouble with Vera getting the correct time.
I have a piece of code that should allow vera to grab NTP time: os.execute("sync_time.sh")
Hoever, whenever I run it - I just get the message ‘received empty response’ and the vera time just stays wrong (it’s not even off by a round number of hours - it just seems to be random. For example now the time is 22:22 but vera is reading 18:01 - although strangely, Vera has the correct day and date to the left of the time in the UI)
Can anyone help?
This all started as initially, I did manually set the time in vera - but when ever I power Vera down to do stuff, the time gets lost.
I understand it may be to do with port 123 (which I have attempted to forward). (My router is an Airport Extreme and I am running VeraLite UI5)
Vera attempts to sync the time each time it gets and ip address, at boot, when NetworkMonitor starts, you don’t need to do it manually.
In your case most probably you have a firewall that denies outbound connections to any ports except a certain range.
You will have to add to that range also
[b]- UDP port 37 for rdate
not
UDP port 123 which is for ntp[/b]
Port forwarding is for inbound connections which is not the case!
Not said yet is that Vera doesn’t have an NTP client installed by default. Unless you have explicitly installed one, there isn’t one. Vera, indeed any stock OpenWrt, uses rdate instead. The ports for which, see cj’s reply.
I need to do some digging re:airport extreme as I am sure I am going through the correct proceidure to open ports 37 and 123 - but they don’t seem to be actually open. Certainly Vera is not managing to get the correct time/date.
Anyone else had trouble with airport extreme / vera?
My work blocks UDP port 123 outgoing, so it’s not unheard of that an ISP might block NTP, but then you would find that your other computers are also unable to use NTP, which I bet you’d notice.
I don’t recall a setting anywhere in the Airport configuration that controls outgoing firewall ports anyway. The only settings I recall are for incoming port mapping, and you don’t want to mess with them. As long as you have NAT turned on (“Share an IP address”) the stateful connection tracker built into any NAT implementation should know how to feed the response back to the right host on your LAN.
(I still can’t fathom why my work blocks NTP. I mean, really, it’s not like it’s a common vector for exploits.)
The problem I have had lately is a flaky ISP connection.
Occasionally Vera reboots itself, I am not sure what triggers this … maybe the log file gets to big … If my ISP is acting up at the time I get the wrong time … then things that are supposed to run at certain times of the day, or base on night time, do not work properly. Vera should schedule a later check if the original time request fails.
I need to do some digging re:airport extreme as I am sure I am going through the correct proceidure to open ports 37 and 123 - but they don’t seem to be actually open. Certainly Vera is not managing to get the correct time/date.
Anyone else had trouble with airport extreme / vera?
Could it be something to do with my ISP?
Thanks[/quote]
I have used the Vera units behind AIrport Exptremes without any problems… So it may be your ISP.
[quote=“RichardTSchaefer, post:6, topic:170558”]The problem I have had lately is a flaky ISP connection.
Occasionally Vera reboots itself, I am not sure what triggers this … maybe the log file gets to big … If my ISP is acting up at the time I get the wrong time … then things that are supposed to run at certain times of the day, or base on night time, do not work properly. Vera should schedule a later check if the original time request fails.[/quote]
It’s an important function, I’m no programmer so I dont know what remedies are possible but some logic as you describe would certainly be desireable as a future enhancement.
Proper NTP daemons do exactly that: they run all the time, keep trying on failure and then nudge the clock if it drifts. Which is why they are better than rdate IMO, it being a one-off thing.
This odd decision to use rdate and not NTP was done by the OpenWrt people, and MCV has inherited the fallout.
MCV’s repository of packages fir Vera3/Lite hasn’t got ntpd in it, so you would have to go to the OpenWrt repository to install it.
Still no luck - I am opening port 37 on my airport extreme as per the attached screen shot - do these settings look good to you?
When I do go to a web site that facilitates port checking (you get signal dot com)- it still says that port 37 is closed.
I have no idea why this isn’t working. Are there ports that will definitely be open which I can check with this web site to make sure I am getting an accurate result?
You should not have to port forward. That is for inbound connections from the outside world to your home. Vera does not listen on port 37. Vera makes outbound connections that get NATed via your Airport Extreme.
Most likely your ISP is blocking port 37. Can you try the following command: “telnet tock.greyware.com 37”
If you get a timeout, that means your ISP is blocking port 37.
On my Mac, I get:
MacBookPro:~ testuser$ telnet tock.greyware.com 37
Trying 71.252.193.26...
Connected to tock.greyware.com.
Escape character is '^]'.
??.Connection closed by foreign host.
Stay away from port mapping. It is probably making the situation worse. Port mapping is only of use when you need to redirect unsolicited incoming packets to a particular host. In this case (NTP and rdate) the response comes in from the internet to your Airport and your Airport knows which machine on the LAN to route it to because it saw the request go out moments ago.
Whatever the box in between your Airport and the Internet—an ADSL or cable modem—may be doing its own blocking. If it has a configuration interface, see if it has its own firewall.
Otherwise it’s really likely to be your ISP, so check with them.
As far as a workaround, install an NTP client, which uses UDP port 123, which might not be blocked:
PING tock.greyware.com (71.252.193.26): 56 data bytes
64 bytes from 71.252.193.26: icmp_seq=0 ttl=117 time=189.518 ms
64 bytes from 71.252.193.26: icmp_seq=1 ttl=117 time=149.785 ms
64 bytes from 71.252.193.26: icmp_seq=2 ttl=117 time=172.094 ms
64 bytes from 71.252.193.26: icmp_seq=3 ttl=117 time=155.277 ms
64 bytes from 71.252.193.26: icmp_seq=4 ttl=117 time=169.875 ms
64 bytes from 71.252.193.26: icmp_seq=5 ttl=117 time=176.641 ms
64 bytes from 71.252.193.26: icmp_seq=6 ttl=117 time=181.898 ms
64 bytes from 71.252.193.26: icmp_seq=7 ttl=117 time=149.828 ms
64 bytes from 71.252.193.26: icmp_seq=8 ttl=117 time=149.080 ms
64 bytes from 71.252.193.26: icmp_seq=9 ttl=117 time=149.033 ms
64 bytes from 71.252.193.26: icmp_seq=10 ttl=117 time=150.591 ms
64 bytes from 71.252.193.26: icmp_seq=11 ttl=117 time=159.535 ms
64 bytes from 71.252.193.26: icmp_seq=12 ttl=117 time=148.482 ms
64 bytes from 71.252.193.26: icmp_seq=13 ttl=117 time=148.037 ms
64 bytes from 71.252.193.26: icmp_seq=14 ttl=117 time=157.201 ms
64 bytes from 71.252.193.26: icmp_seq=15 ttl=117 time=157.008 ms
^C
— tock.greyware.com ping statistics —
17 packets transmitted, 16 packets received, 5.9% packet loss
round-trip min/avg/max/stddev = 148.037/160.243/189.518/13.042 ms
I’m on Virgin Media and I can confirm they do not block any ports, and certainly not NTP. I’ve not had to configure anything (other than timezone) on the Vera Lite for it to keep time. Not a big help, sorry.
I logged into vera and I pasted the code you kindly gave me into the ‘test Luup code (Lua)’ box and got the error ‘code failed’. I am probably being a total numptie - could you spell out what I need to do?