When I try to either log into YouTube or play a video from within Kodi, a progress window shows for two full minutes followed by nothing.
Both my OSMC installation and my Linux Mint desktop are on the same LAN, and both use DHCP.
Pinging youtube.com succeeds from both an OSMC terminal and my desktop.
Pinging www.youtube.com succeeds from my desktop, but fails from an OSMC terminal:
osmc@osmc:~$ ping -c 3 youtube.com
PING youtube.com (216.58.220.142): 56 data bytes
64 bytes from 216.58.220.142: seq=0 ttl=56 time=28.969 ms
64 bytes from 216.58.220.142: seq=1 ttl=56 time=28.404 ms
64 bytes from 216.58.220.142: seq=2 ttl=56 time=28.530 ms
--- youtube.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 28.404/28.634/28.969 ms
osmc@osmc:~$ time ping www.youtube.com
ping: bad address 'www.youtube.com'
real 1m32.578s
user 0m0.000s
sys 0m0.010s
osmc@osmc:~$ time wget -O /dev/null www.youtube.com
--2015-04-29 21:29:16--2015-04-29 21:32:10-- http://www.youtube.com/
Resolving www.youtube.com (www.youtube.com)... failed: Name or service not known.
wget: unable to resolve host address ‘www.youtube.com’
real 1m4.745s
user 0m0.040s
sys 0m0.020s
A debug log of me trying to play a video through Kodi is at http://paste.osmc.io/semutolapi.dos, but to me this issue seems to be at a deeper level than Kodi.
I’m running OSMC on a Raspberry Pi 2.
I’m happy to take direction on assisting further with the resolution of this issue.
Both of my devices are on the same LAN, and both are set up to obtain DNS details from the DHCP server. Of those two devices, one of them (my desktop) is correctly resolving www.youtube.com.
How would you recommend that I alter this DNS setup? Should I try it at the DHCP server level, or give the OSMC box the explicit DNS server address (which seems to mean also giving it a static IP address)?
If I do a Google search for that warning, I’m led to believe that the DNS response for www.youtube.com is larger than something on the OSMC system expects (presumably 512 bytes, according to this), so the request is just getting silently dropped…?
so there seems to be merit in that idea. Is there some way to get the system accepting larger DNS responses? I’m up-to-date with all system packages (i.e. apt-get upgrade does zero operations).
Someone else reported some DNS issues recently. Good find here.
By default, we proxy DNS through ConnMan locally (it’s effectively the equivalent of NetworkManager + dnsmasq). There may be a bug in this system. Try editing (won’t exist by default) /etc/connman.prefs and adding:
Assigned the same permissions and ownership as /etc/connman.conf (0644/root/root).
Restarted connman.
Restarted the entire OSMC system.
Sadly, there’s no change. DNS responses to www.youtube.com are still being “truncated,” and the request is repeating in TCP mode. nslookup handles this additional lookup gracefully; ping doesn’t.
Interestingly (perhaps), doing the same nslookup on my desktop, the first response is still truncated but everything else (including ping) still survives this occurrence, because everything seems to “pick up” the second response.
On this basis, it seems that something on the OSMC system just isn’t handling the size of the response for www.youtube.com (which in my case is apparently 1,096 bytes).
Is there any way to force the OSMC system to perform all DNS requests over TCP in the first place? This would prevent the UDP requests failing due to large response sizes, in turn preventing the need to re-request over TCP.
On further thought, this would only be a stop-gap solution. I guess the underlying system should just be able to gracefully handle DNS responses being larger than can fit in a UDP packet, and work properly when a DNS request is re-issued over TCP. My desktop does this, and my XBian box does this. I’d prefer to help work towards this solution for OSMC.
First, the drop-in is experimental at the moment. You may wish to edit /usr/bin/start-network directly and add --no-dns-proxy (temporarily to test, as apt-get dist-upgrade does not want this file to be edited by users).
You should check your DNS servers are set in /etc/resolv.conf, instead of ‘127.0.0.1’ after you restart the service and --no-dns-proxy is working properly.
I’m not too clear on which line I need to edit in this file. The last five non-empty lines look like this:
fi
exec /usr/sbin/connmand -n -I eth0 --nodnsproxy --config=/etc/connman.conf
else
exec /usr/sbin/connmand -n --config=/etc/connman.conf
fi
I would guess that I’d be adding the --no-dns-proxy flag to one of these lines, but I note that there’s already a --nodnsproxy flag on one of them. Should I be adding that to the lower line as well?
At the moment, my resolv.conf file doesn’t have the expected entries:
You need to add it to the line in the else clause.
I would not expect /etc/resolv.conf to be populated automatically unless you were using DHCP. I’m not sure if ConnMan updates /etc/resolv.conf in line with DNS when configured statically or from DHCP.
--nodnsproxy added to the connmand line in the else clause, and system restarted.
resolv.conf now shows my nameserver.
ping www.youtube.com now works as expected.
The YouTube plugin can now play videos.
So in other words, my immediate issue is now resolved. Thanks for your assistance. I guess this strongly suggests a bug in the device-local proxy nameserver?
but even after restarting the system, my issue wasn’t resolved until I made the manual modification to /usr/bin/start-network, which I understand will disappear with upgrades.
Have I missed a step to making /etc/connman.prefs effective?
That should be fine, provided you’re on the latest version of ConnMan (we may not have pushed this to release yet). Either that or iit seems to be a bug we need to look into there.
I’ve reverted the change to /usr/bin/start-network and rebooted.
/etc/resolv.conf now no longer contains the address of my actual nameserver.
The device-local proxy nameserver is active again.
ping www.youtube.com still works though.
So it seems that my version of connmand (1.28) doesn’t honour the connman.prefs file.
It also seems that the device-local proxy nameserver is now okay. Not sure why; maybe some DNS data is now cached on the system. If things fail again, I guess I’ll re-introduce the --nodnsproxy flag to /usr/bin/start-network.
The version of network-osmc with the connman.prefs option has not been pushed out to release yet. That’s why the dnsproxy=no option is not working for @LxP.
I’ve pushed out an update to the network-osmc packages which adds support for /etc/connman.prefs as Sam described it, so if you check for and install updates you should find that you can then use dnsproxy=no in connman.prefs to permanently disable the use of the connman dns proxy.
It does look like a bug in the dns proxy in connman, I’ll open a ticket with them about this and see if this is a known issue or not.
By the way could you try the test here and see what results you get with the dnsproxy still enabled ?
osmc@rpi2:~$ dig +short rs.dns-oarc.net txt
rst.x3964.rs.dns-oarc.net.
rst.x3974.x3964.rs.dns-oarc.net.
rst.x3980.x3974.x3964.rs.dns-oarc.net.
"86.12.135.41 DNS reply size limit is at least 3980"
"86.12.135.41 sent EDNS buffer size 4000"
"Tested at 2015-04-30 10:08:26 UTC"
osmc@osmc:~$ ping www.youtube.com
ping: bad address 'www.youtube.com'
osmc@osmc:~$ dig +short rs.dns-oarc.net txt
rst.x4090.rs.dns-oarc.net.
rst.x4058.x4090.rs.dns-oarc.net.
rst.x4064.x4058.x4090.rs.dns-oarc.net.
"203.26.25.4 DNS reply size limit is at least 4090"
"Tested at 2015-04-30 10:33:15 UTC"
"203.26.25.4 sent EDNS buffer size 4096"
Unfortunately, no apparent response size restrictions in that report. My desktop on the same LAN has no problems accessing www.youtube.com, and the dig output from that machine is pretty much identical:
$ ping -c 1 www.youtube.com
PING youtube-ui.l.google.CoM (220.244.223.108) 56(84) bytes of data.
64 bytes from 10-50-30-108.tpgi.com.au (220.244.223.108): icmp_seq=1 ttl=59 time=17.4 ms
--- youtube-ui.l.google.CoM ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.404/17.404/17.404/0.000 ms
$ dig +short rs.dns-oarc.net txt
rst.x4090.rs.dns-oarc.net.
rst.x4058.x4090.rs.dns-oarc.net.
rst.x4064.x4058.x4090.rs.dns-oarc.net.
"Tested at 2015-04-30 10:38:11 UTC"
"203.26.25.4 sent EDNS buffer size 4096"
"203.26.25.4 DNS reply size limit is at least 4090"
so perhaps that test instead looks at an upstream DNS resolver (e.g. that of my ISP) rather than the device-local DNS proxy.
connman.prefs is now effective after installing the most recent updates. Thanks.
Are you sure you have dns proxy disabled above ? Did you restart the connman service or reboot ?
Because you will not have nameserver 127.0.0.1 if the dns proxy is turned off, you should see the dns servers assigned by your DHCP server. (I assume you use DHCP)
If you are definitely still seeing this issue with dns proxy off (and correct nameservers shown in resolv.conf instead of 127.0.0.1) then that rules out connman as the cause of the problem.
What dns servers are being assigned by your DHCP server - is it assigning your router/gateway as a dns server ? Check in networking in OSMC settings. If so your router is acting as a dns proxy and could potentially be causing the issue, even though other machines on the network seem ok.
Or it may be directly assigning your ISP’s DNS servers.
What happens if you leave dnsproxy=no, go into network settings, change from DHCP to Static IP (again I’m assuming you’re using DHCP) and manually change your DNS servers to 8.8.8.8 and 8.8.4.4 ? I would be very surprised if it didn’t work then.
