-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
All connectivity intermittently stops working when using OpenDNS #819
Comments
Can you please try upgrading to the version from here and testing again to see if the behaviour remains? Thanks |
Will give that firmware a shot a little later this week and provide some feedback. I do recall looking at system logs a few weeks back to try and check what my IP was being discovered as. There were a few providers it was using and some were coming back with no results while others were producing the correct result but I was never seeing an incorrect result. I also have cross referenced my actual IP against what OpenDNS thinks it is (using another connection on another router to get access to OpenDNS) when the problem is happening and I can confirm that I have found them to be the same. Besides, if I understand OpenDNS correctly it should err on the side of allowing me access to everything instead of blocking everything if it does not recognize the source of DNS requests. More feedback once I give that new build a test run. |
So installed the June 1st build on Friday night and have had some time to play around with it. Certainly seems to be more reliable when it comes to OpenDNS connections. From my side I've not made any adjustments other than opening up the OpenDNS whitelist to a lot more of the IP providers that Gargoyle uses (checkip.org | dslreports.com | ifconfig.co | ip.seeip.org, etc...). I just found them using logread after boot. I did already have a few in my whitelist though. I have found that I can reliably get the required behaviour if I ensure that the WiFi connection that Gargoyle will use for WAN access is present before Gargoyle boots. There is still a glitch when I change the DNS provider from OpenDNS back to the ISP default DNS or vice versa. It seems that when I go from OpenDNS to the ISP DNS then no DNS provider is assigned and in the status area on the web interface it appears as a dash. I need to go back to the DNS config area, make no changes at all and then click save changes. This appears to reset the network interfaces and bring them back up (according to the logread) and this results in a DNS server being assigned (the router IP). When I go from the ISP DNS server to the OpenDNS servers I find that the WAN DNS server is successfully set to the OpenDNS servers after clicking save changes but it simply does not work. I need to wait about 10 seconds and then click save changes again (bring down all network interfaces and then bring them back up) and then it works. I've been able to reliably repeat this behaviour. |
Using 1.11 On a Linksys WRT1200AC. WAN connection coming from another WiFi router so WiFi running in client+AP mode.
Using DNS-o-matic to push my new IP to OpenDNS and have OpenDNS configured to whitelist some sites but block most.
I have found that when I enable OpenDNS and force all users through it then it will work with whitelisted sites about 1 out of every 5 boots. Interestingly if I ssh into the unit and try to ping google.com (whitelisted) from the command line then it will sometimes work even when an external device connected over WiFi with DHCP does not. On the other hand sometimes both the ping from the command line and pings from external devices do not work. I've never seen it such that pings from and external device work but the command line does not. Every now and then I get lucky and connectivity works as expected for external devices but nothing is guaranteed for the next reboot. I've had to disable OpenDNS because of this but I would really like to be able to keep it.
Please let me know if there is any debugging that I can do to provide you with more info to help investigate it more.
The text was updated successfully, but these errors were encountered: