Kodi is not able to resolve my NFS server by hostname on OSMC.
Kodi on Raspbmc has no problem. Further, if I ssh into the Raspberry Pi, OSMC has no trouble doing the resolution or mounting the NFS server outside of Kodi.
From kodi.log:
01:24:00 T:3024400384 ERROR: Unable to lookup host: ‘gravity’
Why might Kodi on OSMC be unable to perform this lookup? I even copied the Raspbmc /etc/resolv.conf (with its search lines and DNS settings) to the OSMC installation and the problem remained.
EDIT: I used the hosts tag in advancedsettings to specify my server’s IP address manually and it worked. So there’s something funny going on with name resolution on Kodi+OSMC that’s not there for either Kodi or OSMC alone…
nslookup will use one of the DNS servers. Specifying the DNS server to be used may highlight where the problem is. For example, if my DNS server (primary), was 192.168.1.100, I would do:
nslookup gravity 192.168.1.100
I personally don’t really advise using hostnames. If you must, I’d recommend you add the IP address to /etc/hosts to save resolution time and make it more reliable as well.
Looks like this is related to IPv6. ping and host always work, but nslookup fails unless I tell it to also accept AAAA records. See below.
This also explains why setting IP address in /etc/hosts doesn’t change anything; that resolution path ignores IPv6 answers whether from DNS servers or from /etc/hosts
So the question now is, Why does Kodie on OSMC not look for IPv6 DNS records? Somehow that was changed between raspbmc and OSMC.
osmc@osmc:~/.kodi/userdata$ ping gravity
PING gravity (2001:...): 56 data bytes
64 bytes from 2001:...: seq=0 ttl=64 time=0.934 ms
osmc@osmc:~/.kodi/userdata$ nslookup gravity
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
*** Can't find gravity: No answer
osmc@osmc:~/.kodi/userdata$ nslookup -q=AAAA gravity
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
gravity......net has AAAA address 2001:....
Authoritative answers can be found from:
nslookup is considered obsolete. ipv6 support was just hacked into and is buggy. nslookup is done.
busybox’s applet nslookup works with ipv6 much better.
and ad nfs in kodi. on my installations kodi can’t connect to ipv6 nfs as well - nevertheless the host configuration is ok and working as should (including nfs ipv6 connections). @crcarlin
are you sure on Raspbmc wasn’t problem and the server was accessed via ipv6? Kodi’s NFSClient uses for name lookups class CDNSNameCache and that class firstly checks if parameter is not IP already (by function with support of IPv4 ONLY), then it tries NETBIOS name lookup and by gethostbyname which usage for ipv6 is highly discouraged.
and now when I wrote all this - I have to say sorry for not believe. tried wheezy (I assume raspbmc was based on wheezy) - and it works. after some digging with toolchains I found that nfs-common (and probably also libnfs4) included in Jessie is broken. (1:1.2.8-9)
try simple rpcinfo -p ipv6hostname
with jessie included 1:1.2.8-9 I get rpcinfo: ipv6.private: Name or service not known. again wheezy if fine, but so is nfs-common 1.2.8-1 I just compiled (http://git.linux-nfs.org) works ok.
as xbmc uses libnfs-dev (libnfs4 on jessie) I haven’t tested this yet with another version (wheezy supplies libnfs1 and xbmc needs to be recompiled/relinked - or GitHub - sahlberg/libnfs: NFS client library can be used) but I assume the problem will be there.
(btw: xbmc’s DNSNameCache.cpp should anyhow be changed to use getaddrinfo() and getnameinfo() respectively - will do it later)
wasn’t your ipv6 domain name just ipv6 alias for ipv4 host?
as the code itself handles ipv4 addresses ONLY.
this could never work for native ipv6 addressing.
Yeah, the complications of name resolution under Linux… I’m not even certain it was going over DNS since (as I understand it) there’s an rpc name resolution that rpcinfo is using.
Anyway, my server listens on both ipv6 and ipv4. The domain name is only registered to the ipv6 address, though. It has an AAAA record but not an A record. I suspect that’s why Kodi’s log said it was unable to lookup the host, it was only looking for A records just like nslookup.
Like I said, using advancedsettings.xml to explicitly set the host to an IPv6 address made it work. I guess that’s separate from the strIpAddress code you found above?
Taken together, could this mean Kodi under raspbmc was avoiding DNS altogether and just going trough some sort of rpc lookup, maybe finding an IPv4 address directly?
everything what I would say is just speculation (without touching the actual system), but as you was telling, I remembered of this :
fs.nfs.nsm_use_hostnames
it is sysctl parameter telling to nfs internal operations (specally mount and lockd that use of “names” is allowed without resolution at first (originally it was used for multihomed hosts and “trust” to names, but who knows).
anyhow, if you specify explicitly the address then the part of code I copied is avoided because your record is considered “translated” already. and this weird IPv4 only code happens if resolution needs to be done. so probably this is the answer “why” it was/is working.
03:31:08 T:1950519296 DEBUG: OnKey: return (0xf00d) pressed, action is Select
03:31:10 T:1950519296 ERROR: Lookup - fd00::1
03:31:10 T:1950519296 DEBUG: SECTION:LoadDLL(libnfs.so.4)
03:31:10 T:1950519296 DEBUG: Loading: libnfs.so.4
03:31:10 T:1950519296 DEBUG: NFS: Context for ipv6-media/exportnfs/src not open - get a new context.
03:31:10 T:1950519296 DEBUG: NFS: Connected to server ipv6-media and export /exportnfs/src
03:31:10 T:1950519296 DEBUG: NFS: chunks: r/w 1048576/1048576
at the end, jessie nfs-common and libnfs4 works with ipv6, but is very strict about proper DNS configuration.
both client and server need to have direct ipv6 records so NAME.DOMAIN → IPv6, but also reverse records.