Hard coded DNS settings for plugin download / software updates?

[Morini]

Hi,

I stumbled upon a network issue which got me scratching my head today.

Setting up this new receiver I've ironed out most of the client / server / kodi multiroom issues I have been experiencing (I understand what's causing the grief at least). Up until now my new E2 box has been sat on my main LAN while I was working on set up and solving the issues. This afternoon, satisfied all the client / server stuff is working correctly I moved the Gigablue box onto a different subnet where it will live permanently. This is where I ran into a weird issue where the box was clearly connected to the internet but the "plugin download" and "software update" were both complaining "no internet connection". I had already installed the speedtest plugin and the plugin to show internal / external IP address, both of these were working fine and it was obvious the box was properly connected to the outside world. The network test menu option was also giving green ticks for everything.

Cue going round in circles for a while (getting nowhere) until I eventually lost the will to live and fired up wireshark to determine what was really going on. On pressing the green button to "download plugins" it seems the box tries to resolve an address via google public DNS 8.8.8.8 rather than using the resolvers configured in network settings. I guess in most environments this will be "ok", but in my network I redirect any DNS requests to google DNS (ipv4 or ipv6) to my own caching resolvers. I have valid reasons for doing this, mostly it is about getting the numerous google devices I have on my network to play nicely with my home automation systems. Anyway, that's not really relevant to the problem. I am more interested in why there are hard coded DNS servers in the code? The reason 8.8.8.8 was not reachable by the E2 box is because the subnet my streaming devices live on isn't in the acl on my bind dns resolvers (on purpose).

I have "fixed it" (aka worked around it) by NAT'ing 8.8.8.8 to the correct DNS servers for the particular subnet the gigablue lives on. All the traffic on this particular subnet routes out via NordVPN, so in the interest of not leaking I'm NAT'ing 8.8.8.8 DNS requests to Nord DNS servers.

Anyway, this may be an enigma2 thing rather than an openvix thing, but my question is why is it necessary to hard code DNS resolvers rather than using the revolvers configured in network settings? There are scenarios where doing this can cause unexpected behaviour. Google are notorious for doing this, but this is the first time I've seen it elsewhere.

[twol]

I’m probably wrong, but I think all the E2 images access basic providers to initially check if there is a connection

[Morini]

I’m probably wrong, but I think all the E2 images access basic providers to initially check if there is a connection

Not quite sure what is meant by "access basic providers", though it may well be true I don't think that is cause and effect here. What I can say for sure is happening (according to the packet capture) is the box attempts to resolve an IP address through a hard coded DNS server address rather than using the resolver(s) it is configured to use. Like I say, I have seen other devices doing this but I don't think it is a wise strategy as it can cause weird problems.

There may well be a valid reason for doing it, I'm just struggling to think of any

[icemanv3]

Morini, I experienced this exact issue when I configured a VPN on OPNSense firewall to route all traffic from my boxes to the internet! It drove me mad, the box was clearly online, and weirdly, if I went to the CLI and did an "opkg update/upgrade" it worked and could get updates no problem. It seems to be something in the GUI code?

I left my network setup as is, moved to OpenATV image to test and there are no issues there.

Defo interestesd to see the outcome of this thread.

[Morini]

Morini, I experienced this exact issue when I configured a VPN on OPNSense firewall to route all traffic from my boxes to the internet! It drove me mad, the box was clearly online, and weirdly, if I went to the CLI and did an "opkg update/upgrade" it worked and could get updates no problem. It seems to be something in the GUI code?

I use OPNSense too and have a VLAN set up which routes all outbound traffic through NordVPN (it seems Nord block access to 8.8.8.8 on port 53). My e2 box and all Kodi client devices reside in this VLAN. Good point about the behaviour being different on GUI compared to cli.

I left my network setup as is, moved to OpenATV image to test and there are no issues there.

I briefly tried OpenATV before running into this problem in an attempt to solve a different issue. Preferred openvix, to be honest. Anyway, if you ever decide to switch back you can easily get it working by adding a NAT rule for destination 8.8.8.8:53. Ideally the hardcoded resolver is removed from the code, but it may be there for a reason? Who knows?

[maxben]

I find this hard coded Google DNS annoying too.

If I block Google DNS at router level the plugin and update servers fail to connect and cause an e2 crash when trying to connect.

I understand this is probably done to simplify things for the majority but for those of us who prefer to not use Google perhaps the devs can chip in here and advise how to change this manualy.

[twol]

This was done 7 years ago to check that the hardware was setup correctly and internet access available. Google was chosen specifically, as it was unlikely to be down unless there were internet issues and would provide a fast response
if you guys want it changed, what would you suggest…. and it has to work for everyone.
ATV added an online access check 6 months ago and use a mixture of IP addresses, (including google) depending on what they are checking…..and Yes, I have checked their code and so that comment is correct.

[Morini]

This was done 7 years ago to check that the hardware was setup correctly and internet access available. Google was chosen specifically, as it was unlikely to be down unless there were internet issues and would provide a fast response
if you guys want it changed, what would you suggest…. and it has to work for everyone.
ATV added an online access check 6 months ago and use a mixture of IP addresses, (including google) depending on what they are checking…..and Yes, I have checked their code and so that comment is correct.

I can sort of understand where you are coming from, but wouldn't a straight DNS lookup without specifying any specific nameserver be an adequate (in fact better) check to confirm correct setup and working internet access? That way you are also checking the E2 box has properly configured and working nameservers.

What appears to happening currently when I press the green button in the plugins GUI (to download the list of plugins) is the equivalent of :

>dig <domain name> @8.8.8.8

Where surely

>dig <domain name>

would suffice?

Granted, this is probably not an issue for 99.9% of users, but for people who are using hard wired vpns it can cause confusion. To be honest, for me it isn't a big deal as I can fix it on my router. I only asked the question because I am sceptical of the benefits of hard coding DNS servers in software.

[abu baniaz]

This issue has come up several times. The idea/motive was to check you can reach the internet instead of specific listed sites. We used to check a few sites and one of them was offline issues for a while which caused problems at the time.

We added a check that you can reach google's dns server. I suppose a check if you can reach google will achieve same objective. Please feel free to submit a pull request. If it works for everyone, hopefully it will be added. We are not like other images who say our way or the high way.

[Morini]

This issue has come up several times. The idea/motive was to check you can reach the internet instead of specific listed sites. We used to check a few sites and one of them was offline issues for a while which caused problems at the time.

We added a check that you can reach google's dns server. I suppose a check if you can reach google will achieve same objective. Please feel free to submit a pull request. If it works for everyone, hopefully it will be added. We are not like other images who say our way or the high way.

Yes, like I say this is probably absolutely fine for nearly everyone. You could call me and the two other guys who've run into this "edge cases"

I had a quick look at the code and I can see in lib/python/Components/OnlineUpdateCheck.py and I stand corrected, it doesn't actually do any lookup, just connects to 8.8.8.8:53. Ironically if this was cloudflare 1.1.1.1:53 it would work in my environment, just bad luck on my part. Probably easiest to leave it as is, I would think if anyone runs into this they will end up here and be able to fix it themselves.

[abu baniaz]

This is the commit where we changed it:
https://github.com/OpenViX/enigma2/c...eb37d8a46413ef

[Huevos]

What is the quickest way to know you have access to the public internet? Touch a known i.p.

We don't want to use a domain name because that would require a DNS lookup.

Why 8.8.8.8? Simple. If Google is down most likely the whole internet is down.

The connection is simple TCP/IP, nothing to do with DNS.

Prior to this commit, trying to reach the feeds without WAN access would lock the box up with an extended spinner.

[maxben]

The connection is simple TCP/IP, nothing to do with DNS.

Yet 8.8.8.8 remains as the primary DNS server after boot up.

[Morini]

The connection is simple TCP/IP, nothing to do with DNS.

Nope, from the code

def NetworkUp(self, host="8.8.8.8", port=53, timeout=2):

Port 53, DNS.

[edit]

Why not do the same thing, but to the nameservers defined in network settings? Nothing works without DNS resolution, so surely the most pragmatic approach is to connect to the defined nameserver rather than a hardcoded one?

I have no desire to go on a religious crusade here, I just thing the approach is flawed.

[birdman]

... it seems the box tries to resolve an address via google public DNS 8.8.8.8 rather than using the resolvers configured in network settings. I guess in most environments this will be "ok", but in my network I redirect any DNS requests to google DNS (ipv4 or ipv6) to my own caching resolvers.

Why not just configure the box to use those cacheing resolvers instead?
Then the request to 8.8.8.8 will get to Google.
Intercepting queries when you can direct them at source seems a little perverse.