Closed PureFallen closed 3 years ago
@PureFallen We just came across this issue internally in something completely unrelated; but it looks like OpenDNS now has a different endpoint for checking your IP address: https://myip.dnsomatic.com | See OpenDNS Troubleshooting KB Hope that's helpful.
DNS-o-matic is indeed owned by OpenDNS. Weird change with a lot of breakage.
We could eventually add this domain as a new alternative in the phad.conf
, through if (and at which priority in the list) is probably something for @bpennypacker to decide.
https://diagnostic.opendns.com/myip
is now back operating. The question is for how long that will be the case and if people with a corrupt phad.dat
are able to retrieve the external IP again.
Removing the Hostname from the config seems no longer required but i still smell the opportunity that this accident should be used to work on error handling for the case that something like this happens again.
Thanks for digging into this & providing a patch to remove it. I'll definitely look into adding some error handling etc. around the logic to get the external IP when I get a chance.
Recently OpenDNS removed the possibility to fetch someone's own raw public IP address using
https://diagnostic.opendns.com/myip
, whilediagnostic.opendns.com
asks for a login.Instead of trying a new address, PHAD fetches the html-code of the "fake 404"-page and inserts it as public IP into
phad.dat
:As result of that, PHAD fails to get the value afterwards, throwing an ValueError and causing PHAD to close. Depending how PHAD has been added to
./bashrc
, that might causes PHAD to loop, keep crashing python and starting from a new.Obvious Fix for now is to remove the no longer functioning OpenDNS URL from
phad.conf
, yet we probably will have to look into ErrorHandling for anything other then "unavailable". In order to get PHAD back working, user also have to deletephad.dat
manually after removing the URL as the error inside the dat-file still exists.