Ping devices on the local network via hostname

Product support
,
32

@dillon1337 These entries are from the DHCP response, I did not modify it by hand/script.
My attempt was to change it via dbus, but I did not get it to work. The code at https://github.com/cemeyer/python-change-NM-dns was helpful, you just have to replace /0 with /1

33

@izavits I configured it via

sudo resin config write --type raspberry-pi --drive /dev/sdb dnsServers “XX.XX.XX.XX YY.YY.YY.YY”

the config.json on the mounted SD card looks like

$ cat resin-boot/config.json | jq
{
“applicationName”: “…”,
…
“dnsServers”: “XX.XX.XX.XX YY.YY.YY.YY”,
…
}

which is of course equal to the one on the running system

bash-4.3# cat /mnt/boot/config.json
{“applicationName”:“…”, … ,“dnsServers”:“XX.XX.XX.XX YY.YY.YY.YY”, …}

but the /etc/resolv.dnsmasq has still the 8.8.8.8

bash-4.3# cat /etc/resolv.dnsmasq
search domain1.com domain2.internal
nameserver XX.XX.XX.XX
nameserver YY.YY.YY.YY
nameserver 8.8.8.8

where is my mistake?

42

@moebius-team looks like 8.8.8.8 is added by default to the DHCP connections as a fallback, and it’s set in /etc/dhcp/dhclient.conf in the host.

I would not modify that file directly, as any changes would be lost after a host OS update. Checking with our team what would be a good solution for your connectivity issues.

50

Also, to help us troubleshoot, could you use nslookup for the entries/hosts that your are not able to resolve and paste back the output? In our understanding the resolution should always work, or never work, but not “sometimes”. The nslookup tool is available in the host OS.

57

I started by modifying the config.json in the boot partition to include "dnsServers": "192.168.1.1 8.8.8.8". It wouldn’t connect to the resin cloud without Google’s DNS and the 192... is my router. Using nslookup, I actually got it to resolve the address of philips-hue:

bash-4.3# nslookup philips-hue.home
Server:    127.0.0.2
Address 1: 127.0.0.2
Name:      philips-hue.home
Address 1: 192.168.1.16

Then I changed my router config so it no longer has the .home local domain. After I refreshed the wifi on my Mac, it removed the domain home from /etc/resolv.conf and I can ping philips-hue and get a response. After rebooting my resin device, it won’t resolve philips-hue. Do I need to manually refresh the network somehow? My etc/resolve.conf on the resin device just has nameserver 10.114.101.1 which is no way related to what I gave it. Now my Resin output looks like this

bash-4.3# nslookup philips-hue
Server:    127.0.0.2
Address 1: 127.0.0.2
nslookup: can't resolve 'philips-hue'
58

@imrehg thanks for your response

I have domains which are resolved correctly (XX… is the correct IP for moebius-ci-02.internal):

bash-4.3# nslookup moebius-ci-02.internal
Server: 127.0.0.2
Address 1: 127.0.0.2

Name: moebius-ci-02.internal
Address 1: XX.XX.XX.XX

and some which are not:

bash-4.3# nslookup dashing.internal
Server: 127.0.0.2
Address 1: 127.0.0.2

nslookup: can’t resolve ‘dashing.internal’

our 2 dns (YY & ZZ) servers are working correctly (ZZ… is the correct IP for dashing.internal):

bash-4.3# nslookup dashing.internal YY.YY.YY.YY
Server: YY.YY.YY.YY
Address 1: YY.YY.YY.YY

Name: dashing.internal
Address 1: WW.WW.WW.WW dashing.internal

bash-4.3# nslookup dashing.internal ZZ.ZZ.ZZ.ZZ
Server: ZZ.ZZ.ZZ.ZZ
Address 1: ZZ.ZZ.ZZ.ZZ

Name: dashing.internal
Address 1: WW.WW.WW.WW dashing.internal

59

Quoted from Bug #1449001 “systemd-resolved: please do not use Google public ...” : Bugs : systemd package : Ubuntu

I believe that it would be better to fail safe if no DNS server is configured – i.e. have DNS lookups fail; it’s better that the user is aware of their misconfiguration, rather than silently sending their queries to Google. The user can intentionally opt to use Google public DNS if they wish.