Hello Guest, if you are reading this it means you have not registered yet. Please take a second, Click here to register, and in a few simple steps you will be able to enjoy our community and use our OpenViX support section.
Page 1 of 2 12 LastLast
Results 1 to 15 of 30

Thread: Hard coded DNS settings for plugin download / software updates?

  1. #1

    Title
    Forum Supporter
    Donated Member
    Join Date
    Dec 2010
    Posts
    70
    Thanks
    11
    Thanked 7 Times in 6 Posts

    Hard coded DNS settings for plugin download / software updates?

    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.

  2. The Following User Says Thank You to Morini For This Useful Post:

    Widower2008 (18-06-24)

  3. #2
    twol's Avatar
    Title
    Moderator
    Join Date
    Apr 2012
    Posts
    8,618
    Thanks
    1,009
    Thanked 2,964 Times in 2,305 Posts
    I’m probably wrong, but I think all the E2 images access basic providers to initially check if there is a connection
    Gigablue Quad 4K & UE 4K
    .........FBC Tuners:
    ------------------> GT-Sat unicable LNB to 1.5M dish(28.2E)
    ------------------> Gigablue unicable LNB to 80 cm dish(19.2E)
    .......................
    Vu+ Uno4KSE, Dreambox dm900
    AX HD61, Edision Osmio 4K+, Zgemma H9Combo, Octagon SF8008 , gbtrio4k, h9se using unicable ports
    Zgemma H9 C/S into Giga4K

  4. #3

    Title
    Forum Supporter
    Donated Member
    Join Date
    Dec 2010
    Posts
    70
    Thanks
    11
    Thanked 7 Times in 6 Posts
    Quote Originally Posted by twol View Post
    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

  5. #4

    Title
    Member
    Join Date
    Jul 2013
    Posts
    57
    Thanks
    0
    Thanked 2 Times in 2 Posts
    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.

  6. #5

    Title
    Forum Supporter
    Donated Member
    Join Date
    Dec 2010
    Posts
    70
    Thanks
    11
    Thanked 7 Times in 6 Posts
    Quote Originally Posted by icemanv3 View Post
    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.

    Quote Originally Posted by icemanv3 View Post
    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?

  7. #6

    Title
    Forum Supporter
    Donated Member
    Join Date
    Nov 2014
    Posts
    347
    Thanks
    108
    Thanked 124 Times in 78 Posts
    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.

  8. #7
    twol's Avatar
    Title
    Moderator
    Join Date
    Apr 2012
    Posts
    8,618
    Thanks
    1,009
    Thanked 2,964 Times in 2,305 Posts
    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.
    Last edited by twol; 23-03-24 at 15:46.
    Gigablue Quad 4K & UE 4K
    .........FBC Tuners:
    ------------------> GT-Sat unicable LNB to 1.5M dish(28.2E)
    ------------------> Gigablue unicable LNB to 80 cm dish(19.2E)
    .......................
    Vu+ Uno4KSE, Dreambox dm900
    AX HD61, Edision Osmio 4K+, Zgemma H9Combo, Octagon SF8008 , gbtrio4k, h9se using unicable ports
    Zgemma H9 C/S into Giga4K

  9. #8

    Title
    Forum Supporter
    Donated Member
    Join Date
    Dec 2010
    Posts
    70
    Thanks
    11
    Thanked 7 Times in 6 Posts
    Quote Originally Posted by twol View Post
    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.

  10. #9
    abu baniaz's Avatar
    Title
    Moderator
    Join Date
    Sep 2010
    Location
    East London
    Posts
    23,541
    Thanks
    6,517
    Thanked 9,224 Times in 6,287 Posts
    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.

  11. The Following User Says Thank You to abu baniaz For This Useful Post:

    Morini (23-03-24)

  12. #10

    Title
    Forum Supporter
    Donated Member
    Join Date
    Dec 2010
    Posts
    70
    Thanks
    11
    Thanked 7 Times in 6 Posts
    Quote Originally Posted by abu baniaz View Post
    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.

  13. #11
    abu baniaz's Avatar
    Title
    Moderator
    Join Date
    Sep 2010
    Location
    East London
    Posts
    23,541
    Thanks
    6,517
    Thanked 9,224 Times in 6,287 Posts
    This is the commit where we changed it:
    https://github.com/OpenViX/enigma2/c...eb37d8a46413ef

  14. #12
    Huevos's Avatar
    Title
    Administrator
    Join Date
    Jun 2010
    Location
    38.5N, 0.5W
    Posts
    13,945
    Thanks
    2,062
    Thanked 5,145 Times in 3,395 Posts
    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.
    Help keep OpenViX servers online.Please donate!

  15. #13

    Title
    Forum Supporter
    Donated Member
    Join Date
    Nov 2014
    Posts
    347
    Thanks
    108
    Thanked 124 Times in 78 Posts
    Quote Originally Posted by Huevos View Post

    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.

  16. #14

    Title
    Forum Supporter
    Donated Member
    Join Date
    Dec 2010
    Posts
    70
    Thanks
    11
    Thanked 7 Times in 6 Posts
    Quote Originally Posted by Huevos View Post
    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.
    Last edited by Morini; 23-03-24 at 20:25.

  17. #15
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by Morini View Post
    ... 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.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.