I have ntp blocked by my router or isp. It can’t be enabled at the router.
I rely on /usr/bin/http-time in OSMC to set the time.
On my Raspberry Pi 2 running OSMC, I have been able to get things to work by changing the timeout=4 in http-time, to timeout=10.
Every time you guys put out a new version I have to make this edit to get it to work. Could you permanently change the timeout in the script?
I think the root cause is that my router doesn’t provide a DNS cache. So this adds some delay.
In /usr/bin/http-time, I have to change this line –
DATE_STRING=$(LANG=C wget --server-response --timeout=4 --max-redirect 0 --spider “$server” 2>&1 | egrep -o ‘^ Date:.’ | sed ‘s/^ *Date: *//g’)
to this line –
DATE_STRING=$(LANG=C wget --server-response --timeout=10 --max-redirect 0 --spider “$server” 2>&1 | egrep -o ‘^ Date:.’ | sed ‘s/^ *Date: *//g’)
More likely to be the ISP, than the router; most soho routers would just automatically allow ntp. The real solution is to contact your ISP and ask them to unblock ntp or if it is the router, I would consider replacing it.
It will be up to sam_nazarko as whether to make this change, but it would be better if you had a more permanent local fix. This would be my suggestion:
Now on startup the edited version will run, even after updates. I would check from time to time there have be no changes to /usr/bin/http-time, you can use diff for this. So if you were diff the files now, you can see just the timeout change that has been made:
A 10 second timeout seems excessive and indicates some sort of DNS or network problem. You’re better off to try to figure out what that is, as 4 seconds is already a long timeout for a query that should complete in a small fraction of a second.
Do you use DHCP or Static configuration ? The first part of the script waits until connman reports the network is up - in the case of DHCP that means that it has received a lease confirmation from the DHCP server.
At that point your network connection should be up and running and there shouldn’t be any delays. Do you still get a timeout if you manually run the following command ?
time wget --server-response --timeout=4 --max-redirect 0 --spider "www.google.com" 2>&1 | egrep -o '^ *Date:.*' | sed 's/^ *Date: *//g'
If it does succeed what does time report for ‘real’ ?
Thinking it might be network related.
I tried the following commands on a much faster Debian 10 system on the same LAN.
I only use static addressing on all my systems, including OSMC on the Pi 2.
BTW, even the 10 second timeout wont work if I check for updates automatically on the Pi 2. Somehow checking for updates will result in reaching the http-time 10 second timeout.
ping -c 5 google.com
PING google.com (216.58.194.142) 56(84) bytes of data.
64 bytes from dfw06s49-in-f14.1e100.net (216.58.194.142): icmp_seq=1 ttl=55 time=16.3 ms
64 bytes from (216.58.194.142): icmp_seq=2 ttl=55 time=15.8 ms
64 bytes from (216.58.194.142): icmp_seq=3 ttl=55 time=15.6 ms
64 bytes from (216.58.194.142): icmp_seq=4 ttl=55 time=15.6 ms
64 bytes from dfw06s49-in-f14.1e100.net (216.58.194.142): icmp_seq=5 ttl=55 time=15.3 ms
— google.com ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 15.341/15.722/16.288/0.337 ms
Blanked out some info because “Sorry New Users can only put 5 links in a post.”
Looks ok, this shouldn’t make any difference but google.com & www.google.com are different IPs (216.58.206.142 & 172.217.169.36; could be a routing issue with your isp, so could you please try pinging the following hostnames from your pi:
tested wget to www.google.com is real >5 secs, but when I use the IP returned in another wget, it is real .051 secs. I found this link, it looks very close to what I’m seeing. ipv6 related stuff.
I’m unclear what you’re saying. Amongst other things, the link describes how you can specify the -4 flag to use IPv4 and the -6 flag to use IPv6. Last time I looked, IPv6 was disabled on OSMC, so wget -6 should give you a “network unreachable” error.
Could you also be more specific about what you mean by “but when I use the IP returned in another wget”. Which IP are you talking about?
As @Tom_Doyle mentioned above, it might be a problem with your ISP, but before you try anything else, I’d recommend that you reboot your router.
I just now edited on the Pi /etc/resolv.conf
options timeout:1
nameserver 8.8.8.8
When I run the time wget www.google.com, I get real time delay of 1.169 seconds.
So much better!
So somehow something before the IPv4 nameserver 8.8.8.8 is checked, something else times out for 1 seconds.
BTW, this is also true on my Debian 10 system, in addition to the OSMC Pi.
My LAN is 100Mbps ethernet, and I have a DSL router/modem supporting only IPv4.
You need to be clearer about what you’re doing because running the command wget www.google.com is not the same as running wget --server-response --timeout=4 --max-redirect 0 --spider “www.google.com”.
Please also answer Tom’s questions and indicate whether you’ve rebooted your router.
So I conclude that as in the OSMC script /usr/bin/http-time, line 24 of the file,
wget --server-response --timeout=4 --max-redirect 0 -spider “$server” …
will first try an IPv6 address. That will timeout.
then tries the IPv4 address. That works.
I have now changed the wget command, to include “-4”
Now everything works in less than 0.2 seconds every time.
So please change the script to add the option ‘-4’ to the wget command in the http-time script.