Surf SOHO 2.4gHz band apparently inop - PiHole issue

This is just a head’s up for RaspberryPi/PiHole users - sometimes RaspberryPi PiHole needs to be rebooted. Until it is, you get some weird symptoms.

The 2.4gHz radio appeared to be completely inoperable. The first symptoms were a good WiFi signal but an inability to reach the internet. After that I could not even get a WiFi indication. (Kindle, two different models.) I even considered PiHole early and removed its DNS address and let the router pick one automatically. That didn’t work and left me considering a broken 2.4gHz radio.

What I checked and tried.

  1. The router’s AP/Settings have 1 6 11 channels set and I have tried Channel Widths of 20, 20/40, and 40. (20 always worked previously.)
  2. I downloaded a diagnostic report.
  3. Since this happened soon after adopting Firmware 8.1, I reverted to 8.0.2 and loaded the previous configuration.
  4. I have several devices that should function on the 2.4gHz band - MacBook Pro and Amazon FireStick; none worked on 2.4gHz, with either firmware.
  5. Oddly, my FireStick is set to 5gHz and to go through the PiHole. That worked okay in 5 but not in 2.4gHz; I presume Amazon has embedded a backup DNS address for such issues, but I can’t be sure.

What finally worked was my attempt to switch to the RPi/PiHole screen and finding it blank. I had to unplug the RaspberryPi and replug it to reboot. After that, the PiHole screen showed up everything else worked fine, too. In retrospect, I should have noticed that the RaspberryPi wasn’t in the Status/Client List. I’m back on Firmware 8.1 and everything’s working.

I hope my mistakes can help new people troubleshoot some problems.

I’ve read pulling the plug on the Pi is not advisable I think due to potential memory card corruption or something.

I always ssh into it and do a « sudo shutdown »

Have you kept the PiHole updated? There have been major releases in the past few months.

1 Like

With the kind of problem I described I couldn’t get into it direct or ssh, so I had no choice. As to versions, I’m keeping it on 4.x until the bugs are gone - I like the idea of 5 capabilities, but I’m not ready yet.

Hi. @stego is correct about the risks associated with “pulling the plug,” although I understand you had no choice. A corrupted SD card is a likely result.

We have many installations out there and all are stable at these revs:
image

Question: Are you running Jessie, Stretch or Buster?

NB: I moved this threat from SOHO to “Everything Else.”

1 Like

I’m running Buster.

It appears it may be time for me to upgrade to v5.

OK. Good. Buster is fine. Jessie is not.
Don’t hesitate to PM me if you run into a problem. Glad to help.

Rick

1 Like

Thanks. I’ll probably do a backup Buster image first.

You can certainly do that. But sometimes its just easier to blow it away and start fresh – particularly when things have been acting “goofy.” It’s not much work to reimage. Just an idea … :grinning:

1 Like

Just did pihole -up, and I’m running 5.1.2. That’s the easy part - now I have to learn the changes.

1 Like

I setup several Pi-holes the other week. Zero issues. Not using Raspberry WiFi, instead have hardwired, and am disabling WiFi and Bluetooth to save on power.

@Jaywalker @Rick-DC Simple 1-liner Backup method for proper shutdown of a Raspberry Pi in case of no longer being able to ssh in and/or log in : with peripherals:
I add this to a Raspberry Pi 3B/3B+ 's config.txt file whenever I set one up:

##### ADD TO /boot/config.txt
# (default is GPIO 4 (pin 5) ) pin26 is BCM numbering. Use physical pin 37 ( see https://pinout.xyz ):
dtoverlay=gpio-shutdown,gpio_pin=26

To trigger shutdown, use a standard wire with female-female Dupont connectors to connect your defined pin above to a ground pin momentarily.

Don’t know why they never made this feature more visible…I’ve seen tons of blog posts about creating a button with a python script running as a systemd service, which obviously isn’t at all needed.

Right, I think that should trigger an orderly shutdown. Good work!

We’ve never done that because (1) so many of them we touch are remote and it’d be essentially impossible and (2) it’s not much of a job to rebuild it if the thing crumps. Actually, they’ve been pretty stable – very few real problems. The only issue we’ve had, say within the last year or so, was upgrading the software w/o paying attention to the OS (Jessie is no longer supported.)

I appreciate your contribution. :blush:

I have pulled the power on a couple raspberry pis (and had power loss) many times in the past month. not one has become corrupt, yet. knock on wood.

It does sound like a useful idea.

Before this, I haven’t bothered with alternate shutdown methods because pulling the plug has never caused me problems - wasn’t aware it could - and I always have an image I can use to re-flash that SD card or a replacement.

Sure. That usually works. But there are periodic writes to the micro SD card. Guess what happens when the power goes out in the middle of a write. :neutral_face: