Forum

I had a similar issue in the past, which the devs had since fixed. But now, the Pi again is no longer responding to access attempts by DNS hostname.

Software
XBian version: XBian 20150407-1
Overclock settings: default

Hardware
Device type and model: Raspberry Pi Model B 512 MB
Power supply rating: 5V, 1.2A
SD card size and make/type: 4 GB
Network: Ethernet
Connected devices: Powered hub, with external HDD

Problem description:
I can access my Pi with Samba, but for other devices that don't use Samba, but use DNS hostname resolution, I can't access my Pi by hostname (but I can access my Pi via IP address).

How to reproduce:
Ping by hostname on a system that resolves hostnames by DNS. nslookup reports that the server can't find the hostname.

I could work around the problem that had similar symptoms which I found earlier by altering the /etc/dhcp/dhclient.conf file. But this time, the dhclient.conf file has the correct data in it, so this problem potentially lies deeper. I began to notice this at the end of May, though it could have arrived any time in April or May.

Your making a mistake with running "nslookup hostname".
By running "nslookup hostname", your asking the DNS server to resolve a non existing hostname called "hostname".

Syntax is:


Looking at the response from nslookup that you posted before, it looks like the IP address for your DNS server is "1.1.1.1" but you can check by running below one:


So for example for the default hostname for XBian:


Or lookup IP address for the forum:


If you want to use DNS for resolving hostnames to IP addresses , you will need to configure your DNS server with A-records for all your hosts.
Or if you got a smart router/DHCP/DNS box, these will add DNS records automaticly upon DHCP renewal.

Alternativly if you dont want to use a DNS server but still want to resolve, you can edit the "/etc/hosts" file on every device and add lines for resolving names to IP (see 'localhost' entry as an example).
Ps. Windows location for the "hosts" file is "C:\windows\system32\drivers\etc\hosts".

(20th Jun, 2015 11:55 PM)deHakkelaar Wrote: [ -> ]Your making a mistake with running "nslookup hostname".
By running "nslookup hostname", your asking the DNS server to resolve a non existing hostname called "hostname".

Syntax is:

Terminal

nslookup <HOSTNAME_THAT_YOU_WANT_TO_RESOLVE_TO_AN_IP_ADDRESS> <DNS_SERVER_IP_ADDRESS>

Looking at the response from nslookup that you posted before, it looks like the IP address for your DNS server is "1.1.1.1" but you can check by running below one:

Everything I provided in my terminal output is an example. My hostname is not "hostname" and my DNS does not reside at "1.1.1.1". I only used those values to demonstrate the issues I'm seeing when I input the real values.

The real problem probably lies somewhere in XBian's DHCP client, since the DNS only serves the A records it has created as a result of DHCP integration (I'm using DNSMasq).

Last time I was able to narrow it down to issues with the /etc/dhcp/dhclient.conf file, and I will continue to try to identify the problem here, but this time, the dhclient.conf file has the correct data.

I dont believe this to be an XBian DHCP client issue.
The only thing dhclient does is acquire IP, mask, gateway, NTP, DNS servers and advertise its own hostname (the "send host-name = gethostname();" bit in "/etc/dhcp/dhclient.conf")

If you want to diagnose DNS, first determine whats your assigned DNS server(s) by checking the "/etc/resolv.conf" file.
Then use the address from the "resolv.conf" file to query:


If it doesn't resolve properly, on consol you could try and release the DHCP lease on the Pi, delete all entries for your Pi in your "DNSMasq" box (including stored/cached MAC addresses) and renew the DHCP lease on the Pi:

(22nd Jun, 2015 01:51 AM)deHakkelaar Wrote: [ -> ]I dont believe this to be an XBian DHCP client issue.

Definitely an XBian client issue, though perhaps not the DHCP client.

But, I upgraded packages on the 22nd, and the hostname business mysteriously works again. One of the following updates fixed the issue (most likely the xbian-package-kernel package) (from /var/log/apt/history.log):

(28th Jul, 2015 08:01 AM)palswim Wrote: [ -> ]Definitely an XBian client issue, though perhaps not the DHCP client.

So, a year and a half later, this is not an XBian client issue. I apologize for blaming you, XBian team.

As far as I can tell, my router (an old DD-WRT installation) loses its brains after some period of time, on the order of several months. If I reboot the router, everything works fine for another couple of months.

(30th Nov, 2016 08:11 AM)palswim Wrote: [ -> ]

(28th Jul, 2015 08:01 AM)palswim Wrote: [ -> ]Definitely an XBian client issue, though perhaps not the DHCP client.

So, a year and a half later, this is not an XBian client issue. I apologize for blaming you, XBian team.

As far as I can tell, my router (an old DD-WRT installation) loses its brains after some period of time, on the order of several months. If I reboot the router, everything works fine for another couple of months.

Thanks for coming back with the resolution.

Missed this one completely.

Yeah routers and consorts do have a habit of needing to be restarted periodically.

It may not be relevant at this late stage but I know there are issues with samba in later kernels. Don't have the details to hand. But..

The "temp" solutions is to either
1) Add the samba server to /etc/hosts
192.168.x.x <name of server> in Xbian
2) Hard code the server IP in Kodi as
smb://<IP address of server/<share name>