2.001 DNS resolution failing

[macmpi]

Hi,

It seems there is some failing DNS resolution mechanism happening between Volumio2 and some routers.
However such issue does not happen with plain Jessie Lite image, so there is probably something specifically linked to Volumio networking services or setup.

Installed 2.001 on a rpi3 (Hotspot turned OFF). Was working in one place (web radios, spotify, updates,...), and then moved it into another location having different ISP router.
After lots of investigations, it turns-out that Volumio DNS resolution fails in that location.
For instance, checking for system updates fails to go through with:
sudo curl -X POST --data-binary "device=pi&variante=volumio&version=2.001&uuid=<myUUIDhere>" http://updates.volumio.org:7070/downloader-v1/track-device
but works with
sudo curl -X POST --data-binary "device=pi&variante=volumio&version=2.001&uuid=<myUUIDhere>" http://149.210.234.235:7070/downloader-v1/track-device

Doing the first command either on a Linux-PC or same raspi3 with Jessie, works (Device uuid already tracked response)
So clearly it's a name resolution problem only with Volumio distribution.
Volumio seems to receive a LAN IP address as a response (first address of the DHCP server range): at least that's the address it uses in the curl request.

I confirmed /etc/resolv.conf contained proper ISP DNS addresses (and google's one).
I confirmed other settings (gateway, etc) were ok.
I even setup everything manually in /etc/network.interfaces (including DNS), with no more name resolution success.

A hack-ish way to get things sort-of running is to tediously add necessary machine names in /etc/hosts.
By adding addresses references to carefully searched Shoutcast, Volumio, etc names, I could get some services (Webradio, plugin install, system update check) working or so.
This further confirms name resolution issue.

There are indeed some cases where DHCP & DNS servicing may be tricky with some ISP routers.
That's a reason why networking manual entry is sometimes necessary (BTW, would be nice if UI could allow entering DNS info too).
However the fact that Jessie image does not encounter this issue, leads to think there is something wrong related to DNS resolution within Volumio networking.

Unsure how to do more investigations to help diagnose this a further level down for resolution.

[xipmix]

This might be the ordering of the nameserver lines, which could differ in the two locations.
In the failing location, can you try the 'host' command to resolve names, eg

$ host updates.volumio.org

and then try again after rearranging the nameserver lines?
Does the 'domain' option appear in the resolv.conf, or 'search', or both?

[macmpi]

Thanks for your interest in this.
I'll look when in front of the pi again.

However I suspect there might be issues with dnsmasq that was run at some point in the boot process, although the overall Hotspot is definitely turned OFF.

Some extracts of journalctl:

Oct 20 14:57:14 volumio systemd[1]: Starting LSB: start Samba NetBIOS nameserver (nmbd)...
Oct 20 14:57:14 volumio systemd[1]: Starting Restart Volumio Network...
Oct 20 14:57:14 volumio systemd[1]: Started Restart Volumio Network.
Oct 20 14:57:14 volumio systemd[1]: Starting LSB: Brings up/down network automatically...
Oct 20 14:57:14 volumio systemd[1]: Starting hotspot.service...
Oct 20 14:57:14 volumio systemd[1]: Started hotspot.service.
Oct 20 14:57:14 volumio systemd[1]: Starting dhcpd.service...
Oct 20 14:57:14 volumio systemd[1]: Starting dnsmasq.service...

Then it fails after a while (about 1mn30), but this is not graceful stop either.

Oct 20 14:57:19 volumio systemd[1]: hotspot.service: control process exited, code=exited status=1
Oct 20 14:57:19 volumio systemd[1]: Stopped hotspot.service.
Oct 20 14:57:19 volumio systemd[1]: Unit hotspot.service entered failed state.
Oct 20 14:57:19 volumio wireless.js[599]: stophotspotchild process exited with code 0

Oct 20 14:57:20 volumio wireless.js[599]: Stopped hotspot (if there)..

Oct 20 14:58:48 volumio systemd[1]: Stopped hotspot.service.
Oct 20 14:58:48 volumio wireless.js[599]: stophotspotchild process exited with code 0

I'm really surprised Hostpsot is launched as it is supposed to be OFF.
This may mingle some network configuration, and in particular DNS resolution.

Back to original specific DNS resolution issue, I get this message
Oct 20 14:59:53 volumio volumio[968]: info: Cannot download Available plugins list: Error: connect ECONNREFUSED 192.168.0.10:80
where 192.168.0.10 is erroneously passed by DNS service for an internet request.
I wonder if ECONNREFUSED comes from dnsmasq at some point (which is part of hotspot service).

Appreciate any thoughts.

[xipmix]

Pretty clear the resolution is wrong, as you say. ECONNREFUSED would be whatever host has that IP address refusing the connection to port 80 (most likely because nothing is listening there).

To understand what is going on with hotspot the best thing is to read wireless.js - it is fairly clear. systemd calls wireless.js with the 'start' argument. Inside wireless.js, hotspot is stopped and then the 'hotspot off' setting seems to stop it inside the start routine (startAP?).

The only thing that I can suggest further is investigating the role of all that stuff under /etc/resolvconf/ - I don't understand resolvconf at all.

[macmpi]

as you said

Inside wireless.js, hotspot is stopped and then the 'hotspot off' setting seems to stop it inside the start routine (startAP?).

I'm still curious about why hostpot it ever started in the first place, as it should not ever when setting is set to OFF.
Not starting it at all would avoid some failures (useless start of dnsmasq & dhcpd, and failures later), and help having a clean & lean standard client startup I guess.

[macmpi]

Now, the fun stuff is that host updates.volumio.org gets proper reply under command line, whereas volumio processes do not get proper resolution, unless I provide the info into /etc/hosts file!...

[volumio]

Hmmmmm interesting... I wonder what causes that!

[macmpi]

Maybe host command and volumio processes don't speak to the same side of the frankenstein-NAT (once started & failed with dnsmasq and dhcpd).

[macmpi]

Seems some ISP somehow block use of Google DNS in favor of their own.
This fix seems to solve the problem.
Please reopen if not fixed.