Hi All,
Tried to access the admin UI just now and it was unresponsive. Updated pi-hole and raspbian, rebooted, did pihole -g, rebooted again and still the issue persists, UI appears but none of the counters load. Did an nslookup and instead of the usual "pihole" the default server is now "0000mps.webpreview.dsl.net" - no idea what that is.
Any ideas?
Many thanks,
Jeff Smith
Sounds like you have an infection / malware: http://cyberwarzone.com/beware-of-0000mps-webpreview-dsl-net-it-is-used-to-spread-malware/
I didn't actually go to the site (no one should!) but I did test that they do have port 53 open so they're probably hijacking DNS and using it has an method to infect other computers on your network.
I'd get that straightened out before worrying about your web UI 
Possibly. I did see that article but all my systems are ssh key access only and a lot would have had to go wrong for me to be compromised. Am thinking something else but happy to be wrong.
Jeff
This may be related to a recent reversion in code we made. We used to stack the deck with the /etc/pihole/gravity.list file and place a token pi.hole entry so that if you ever pinged or tried to nslookup/dig your pi-hole address, you'd get back pi-hole. We felt that the adlist wasn't the best place for our name, so we took it out. If you head /etc/pihole/gravity.list the first entry, and the one that dnsmasq returns as the DNS name of your Pi-hole, will most likely be that foreign address. This is a good thing in that it indicates operational status.
Next would be a pihole -d and then pass us the token with your debug ID so we can check our server for the debug log if you agree to upload your logfile.
Dan,
You are correct that the site indicated is the first entry in gravity.list, great to know. As I didn't know what was happening last night, I shut off my router but let everything else remain on. This morning I powered the router back on the UI is responsive and working as expected. This is unexpected because I had rebooted the router several times last night but the UI remained unresponsive.
I am unclear if the log is cumulative. If it is, I ran one last night and this morning. If not, you will only see this morning when it is working as expected again. In looking at it, I see a lot of these lines which seem interesting:
2016-11-02 21:20:30: (mod_fastcgi.c.2702) FastCGI-stderr: PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/admin/data.php on line 197
Debug log token = shi6cqx2lo
Thank you,
Jeff
Thank you, the logs are individual and do time out after 24 hours for user privacy. I took a look at the latest, and the errors are indicative of a large Pi-hole access log. That would explain why you were able to access the UI after an overnight shutdown. There is a cron process that will clear the Pi-hole access logs overnight so that they are clear every morning. We're in the process of upgrading the script to handle larger log files, and this issue should be fully resolved when we are able to release that upgrade. You may notice that the UI does become slower later in the day or evening as the logs fill up, let us know if that seems to be the condition you are seeing.
Thanks and keep us updated please.
Dan,
Thanks for the explanation, makes perfect sense. Has slowed down a bit tonight but not like last night where it was just unresponsive. Uploaded a new log for your review.
Debug log token = nfopsnoeoj
Jeff
It indeed does look like you're affected by the log size situation. The timeout values being exceeded in the PHP logs usually happens when the files just grow to be too bug for the parser to handle. We're working on a resolution for that.
Sorry for resurrecting an older thread, but I wanted to point out that I had also been wondering why nslookups were reporting that the server was 0000mps.webpreview.dsl.net. In my research I found the same thing diginc found (which immediately concerned me). However I found that Dan's explanation as to why the Pi is returning that server holds true for me as well.
If anyone else happens to come across this thread wondering why what appears to be a malicious domain is providing nslookups, now you know-- it's just your Pi.
That said, I am curious why it is that the first entry in gravity.list appears as the server providing digs/nslookups. I've been meaning to dig into PiHole's code over the last few weeks, so this is as good a reason as any.
Thanks for the clarification on this issue, Dan.
That will be fixed in the release we are currently preparing.
Fantastic! Thanks for the info, DL6ER.
