View Full Version : "Your Miraclebox Premium Twin has no internet access" after upgrade to 5.0.029
Sorry if this has already been reported, but I couldn't find any info on it. After doing software upgrade to 5.0.029, my box says "Your Miraclebox Premium Twin has no internet access, please check your network settings and make sure you have network cable connected and try again" if I try software update or download plugins. The same message appeared when I tried fresh installing 5.0.029 on a Miraclebox Premium Micro Hybrid, and it was solved by installing 5.0.028 instead. If I connect via SSH to the box, I can do nslookup and ping and wget, so the isn't *really* a problem with my internet access.
i presume you also ran a network test and some were red,have you retried rebooting box and router and the rerun network test to see if all green.
i presume you also ran a network test and some were red,have you retried rebooting box and router and the rerun network test to see if all green.
Network test runs all green. As I said, there is nothing wrong with the internet connection, I can use wget from the console and download things, so DNS and connectivity works, plus the issue is resolved by installing previous version, so it's not a router issue, it's an issue with version 5.0.029.
EDIT: Oh, and reboot does not help.
abu baniaz
16-10-17, 11:02
Attach your debug log please.
Please note:
Thread will be moved to the ViX-Team-Images-Support-Discussion section. It is best to use the image support section for image issues as problems/solutions are usually the same irrespective of receiver. It also helps others searching for the same issue although they may have another receiver.
Please read the thread in link below which explains things better.
http://www.world-of-satellite.com/showthread.php?33155-ALL-MEMBERS-PLEASE-READ!-New-method-of-posting-in-ViX-Support-Section (http://www.world-of-satellite.com/showthread.php?33155-ALL-MEMBERS-PLEASE-READ!-New-method-of-posting-in-ViX-Support-Section)!
No harm has been done, no need to apologise. Please bear in mind for future support questions.
Attach your debug log please.
Please note:
Ok, enabled debug logs, rebooted box, did check for updates which failed, disabled debug logging and pulled log file from box via FTP. It should be attached to this post, if I did it right :)
abu baniaz
16-10-17, 12:16
Your log shows this
< 173.706> [OnlineUpdateCheck][OnlineCheck] FAILED timed out
< 173.706> [OnlineVersionCheck] ERROR: -2
< 173.706> [OnlineVersionCheck] Error -2
We'll have a look at it.
Is your network setup in a unique manner?
No, I have a cable modem in bridge mode, and an ASUS router behind it, to which my box is directly connected. Never had any problems before.
abu baniaz
16-10-17, 12:45
We recently added a check for internet connectivity.
On the box do a ping to 8.8.8.8
On the box do a ping to 8.8.8.8
Yep, that was it, there was a static route set up in my routing table routing 8.8.8.8 and 8.8.4.4 back to the router. Totally falls under the category of "network setup in a unique manner", but I had completely forgotten about it's existence. Sorry!
Pinging googles dns servers to determine internet connectivity is flawed. I too have had static routes to block them in the past.
abu baniaz
17-10-17, 22:21
Which server do you recommend?
Pinging googles dns servers to determine internet connectivity is flawed. I too have had static routes to block them in the past.There is no ping involved in our test.
If you can come up with a better way to test connection to the internet that does not involve a FQDN lookup and checks a server of that reliability and longevity without changes we would be happy to implement it.
Maybe use googles IP address rather than their dns servers.
Maybe use googles IP address rather than their dns servers.Those IPs can change at any time. The IP of the DNS server cannot. Also this is a TCP handshake not UDP. So not sure why you are mentioning being a DNS. And if you have deliberately configured to block this IP I can't see how you feel this is an OpenViX error. It's like blocking the feeds IP and then moaning you can't reach the feeds.
Those IPs can change at any time. The IP of the DNS server cannot. Also this is a TCP handshake not UDP. So not sure why you are mentioning being a DNS. And if you have deliberately configured to block this IP I can't see how you feel this is an OpenViX error. It's like blocking the feeds IP and then moaning you can't reach the feeds.
I don't know how the internet test works but I seem to have the same problem, i.e. I get the "your box has no internet access" although the connection is fine. I have just tried the latest image but had to revert to my previous image (4.x).
I have a static route for 8.8.8.8 and 8.8.4.4 because I use smart DNS with a Chromecast, which is hardwired to google's DNS servers. I have not experienced any other problems with this static routing but it seems to prevent the new image from working properly.
I have the same problem on my Vu+ Duo2 since updating to version >5.0.27 about 2 month ago and want to voice my arguments here.
What I have understood is that you are now making some kind of network check.
And I can see that my firewall is blocking the access to ip 8.8.8.8 port 53.
This is in my overall network configuration correct and intended and I will not change that.
Because I have setup my own linux firewall server and on that server BIND9 is running as caching only nameserver for the local network.
So this server is the only machine allowed to connect to port 53 to specific dns servers in the internet.
All machines behind my firewall server inside the local network - that's also my 2 Vu+ Duo2s - are NOT allowed to connect to dns-port 53 to the internet.
I have this setup for 12 yrs now and had never problems with any software / hardware / system.
And from a security point of view I find it a reasonable setup.
So can't you implement your internet check in another way?
abu baniaz
07-12-17, 22:30
So can't you implement your internet check in another way?
Please suggest an alternative.
Please suggest an alternative.
Maybe a connection to port 80 (http) or 443 (https)? Any ip will do. These ports are normally open for outgoing traffic on any firewall - even self-configured ones.
Why did you choose a nslookup thru google's nameservers? Why not just do a "normal" nslookup thru the nameserver that is configured in the box's network setup?
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.