Recommended Order of Boot/Reboot Operations?

Help
1

Greetings PiHole Discourse! :wave:

I'm hoping to find some guidance, general experience insight, and/or recommendations from you all. I love my PiHole dearly but sometimes it's a little nit-picky when power cycling comes in to play.

Here's some context. I travel full time and have wired up my Pi (along with router and cellular gateway) to be used while stopped. With no real need for my wireless LAN while in motion (and the preference to not have those components rattled to death), I typically power them off, take them down, and store them somewhere soft while actively traveling down the road. To be transparent, I have not typically followed protocol for turning off the Pi via correct shutdown APIs — until this evening I sort of figured just ripping the power wouldn't hurt the thing too bad. I'll follow that more in the future.

Hardware wise it's a very vanilla install running on a Pi Zero W with a USB adapter for an ethernet connection to the router (wifi disabled) and power being provided by a standard USB cable from the vehicle's 12v socket.

Anyway, the issue I tend to have is with the correct order of operations with getting my router booted up and my Pi booted up in such a way that the Pi correctly establishes a connection to the router, declares its IP address, and begins the DNS server. It seems like if I power up the Pi first, then power up the Router (having had the ethernet cable connected between them the whole time), the Pi will fail to establish even an IP address on the network — presumably because the Router wouldn't have been fully booted yet — but will never recover or reattempt once the Router is online? I think I have better luck if I disconnect the ethernet line, fully boot the router first, boot the Pi, then connect the ethernet line between the two.

I'm not really versed on the internals of the Pi and/or the PiHole software, and I do think there's a failure to establish an IP address / presence more than a failure for the DNS listener to kick online (I should've done some manual pings when the Router was up but the Pi wasn't talking to it but at least in the Router's web dashboard it was not showing a client for the Pi)... but I'm mostly just curious for some experienced voice(s) to give me a recommendation or two regarding the best boot sequence for the router and Pi to play nice together.

As an alternative I can probably also wire up the Pi to be powered 24/7 and just unplug the ethernet line when I switch to active travel (still putting away the router) but I'm not sure how well the Pi / PiHole software plays with the sequence of "running well on ethernet... ethernet gone... ethernet back several hours later, everything else fires back up" (?)

Thanks!

--
Jon

2

Or leave the pi at home?

3

This is my home :stuck_out_tongue: 'travel full time' in the sense that I don't have a traditional 'home' somewhere to go back to. Plus I like my little Pi :laughing:

4

Pi-hole is not responsible for its host OSes network connection. Which OS do you use and which network stack?

I btw strongly recommend to not simply pull the power cable of the Pi instead of shutting it down. You will face data corruption up to an unbootable system earlier or later. This is not only the case because you might break e.g. Pi-hole's database writes or logs in the middle, or those of other processes and services, but also since Linux uses a filesystem chance: All data written to disk is passing a cache layer to speed up writes and to bundle smaller writes which reduces disk wear. When you plug the power cable, the cache is not written to disk, leading to incomplete or corrupted data. If you just did a kernel or bootloader upgrade your Pi might not come up again. There is filesystem journaling on ext4 (not on the FAT boot partition most RPis have) from which recent changes can be restored, but it is a bad idea to intentionally rely on this :wink:. If console access is not always feasible, one can also use a GPIO attached shutdown button.

2 Likes
5

Wise words on power-pulling. I will heed them for sure. I'll either shut it down properly or convert it to just always stay online (foreverrrrrrr :laughing:). I'll have to play with it a bit. I'm a little more apt to just have it run all the time then just plug in the ethernet line when I need it, but I guess that point is moot if it doesn't establish a connection well that way either.

Totally fair enough, I was hoping to get more of just some guidance/wisdom from the community here more than expecting any actual sort of responsibility from the Pi-hole layer.

I'm running Raspbian 10. Not sure what you're meaning by which network stack (v4 if that's what you meant). I did go ahead and run a debug / upload in case that helps, though I'm not entirely sure who's got the keys to that info and who doesn't :sweat_smile:

6

If your RPi is acquiring its IPv4 address via DHCP, your router's DHCP server has to be up and running before your RPi broadcasts for a DHCP lease.
Make sure to configure your router to hand out a fixed IPv4 address (DHCP lease reservation) to your RPi.

If you did configure your RPi for a static IPv4 address instead, then startup order should not matter, but make sure that your router does not hand out that IPv4 to other clients, either by by also configuring a DHCP lease reservation for your RPi's IP, or by using an IP address for your RPi outside of your router's DHCP pool.
On Raspberry Pi OS, static IPs will be defined via /etc/dhcpcd.conf.

1 Like
7

Interesting. Thanks for the thoughts! My Pi is currently setup as the DHCP server for the network and has its own static IP (confirmed in /etc/dhcpcd.conf) which is where things getting annoying on booting the router. If the router and rpi don't connect the right way I have to connect to the network with a manually-assigned IP then try to figure out if the rpi even established its IP address on the network (which is statically defined but in many cases still doesn't show up as if the rpi failed to declare anything).

I too felt like startup order shouldn't much matter with a static IP like that but it's feeling more and more like something lower in the stack ends up having an issue if I boot the rpi before the router's ready/on

8

Hmm, how do you recognise that the Pi has not established a connection to the router? When it assigns a static IP itself then it should be reachable and have an internet connection as fast as the router is up, given both share the same subnet/IP range. Of course clients you may use to connect to the Pi first need to send a DHCP request to get an IP from Pi-hole.

Was there indeed no IP assigned then? Can be checked with ip a. If so, the dhcpcd logs may give a hint:

journalctl -u dhcpcd
9

I get the feeling you are describing two different things:
What I read is your devices are not getting into the network. The Pi-hole is static; you have already written that, but your devices are not getting an ip address from the pi if it boots first and then you are manually configuring them with static addresses?

Surely you are not getting into the Pi and, again, manually assigning it an ip address? I mean how could you if the Pi is not working as a DHCP server?

Simple answer: Boot the router, then the Pi, then all devices. Because if your devices do not see a DHCP server as soon as they are turned on, they will assign one randomly.

edit
Does your router KNOW the Pi's IP address is static?

2nd edit

Sorry for not reading and concentrating on your OP.
The pi DOES NOT LIKE being shut down for hours and then trying to get the correct time for DNS look-ups.

1,000 seconds and it goes sideways. Either leave it on so its RTC is, somewhat, synced, or solder the GPIOs and get a battery powered RTC for it.

1 Like
10

The router doesn't list the Pi in its client list and I can't reach it via its static IP via ping, ssh, etc.

For sure. Since I'm trying to figure out what happens in various situations while the Pi is my DHCP server, I'll typically switch my Mac to set a manual IP address (outside of the Pi's DHCP range so I know for sure when I set an IP vs. when it's DHCP-set) then work directly with the router to try to figure out what's going on. I'll often switch back to DHCP at some point to see if the PiHole is handling DHCP from there on..

Right. Really my Mac is the only machine on the network at all, so... debugging as noted above.

My router knows the DHCP server is set to the Pi's static address, but I think my router has no bearing on IP addresses once I turned off its DHCP server function. E.g. it also had "reserved addresses" but I believe that was only for the DHCP side.

What I've found in the last couple of days is two major pieces. For starters, the simple answer does tend to work.. with a caveat. "Boot the router, then the Pi, then all devices" + "make SURE that when you kill the Pi, you do it with a shutdown command, not a power drop". When I follow that pattern, I tend to have consistent results. I know that's what everyone recommends already, just making sure it's called out as the full equation of "the simple answer" :slight_smile:

In my experience, the simple answer does not work consistently when pulling the power on the Pi. The simple answer in that case is at best, spotty.

The other case that I wanted to cover is the Pi (or PiHole?)'s ability to reconnect to the network if the router goes offline or reboots while the Pi/Hole is online and running. In my case, I can leave the Pi powered 24/7 but still want to take the router down during travel. In this case, I've never had luck with the Pi reconnecting to the router after the router is offline or reboots (time span of < 30 seconds to multiple hours). Doesn't make a ton of sense to me as to why, but I've noticed it consistently. If the Pi stays up but the connection to the router gets cycled, the Pi doesn't seem to connect (at the IP layer) regardless of it having its own static IP configuration.. and subsequently the DNS service is not available.

The bad side effect there being that if something weird happens with the router and it has to reboot or etc., the Pi won't reconnect which means I can't reach the Pi to shut it down properly anymore :frowning:

--
Jon

PS. Thank you both for the insight and willingness to help me along here!

11

I'm really confused now too.

If the Pi has a static address, the LAN side of the router is also, static (because It is not the DHCP server) all devices are on the same IP range they should talk.

Regardless, you can unplug the pi from your shut down router and into into your laptop and talk to it directly. Then shut it down properly. It will not hurt the Pi. It will just see a new device when it saw none just a moment before.

It is the simple answer because:
You did not tell us what router you are using.
We do not know your LAN settings (because it really seems like your router is not playing nice, if everything is static/manually set up).

If you travel, a lot and, basically, use the router for only one device, just let it handle DHCP.

Letting the Pi do that, just let's you see device's names in its logs instead of just IP addresses; but you know what the device is, so...

12

Same! :rofl:

Ah, totally fair! My apologies. It's the Asus AC68U running their firmware (never did get around to loading Merlin).

Yeah I suppose that makes sense as a backup if I fail to shutdown the Pi before the router (or other circumstances) — however I'm not exactly confident that 'the Pi will just see a new device when it saw none a moment before' given that it doesn't do that when the Router is that new device again.

I can replicate the scenario by just unplugging the ethernet line between the router/Pi for a few seconds then plugging it back in. The router (nor the other devices on the network) aren't able to reach the Pi at that point :confused:

Actually.. great point there. Hadn't thought of that. Basically I'm just using it for one device right now but plan to use it for others in the coming couple of months. Still sort of trialing this setup and want to keep it to just my laptop until I get a better sense of feel for how everything should work.

That said, I could even go further and just not use DHCP at all. It's a limited number of devices that I have ready access to, I could just manually assign each device's IP and preconfigure the DNS server to the Pi too. Interesting idea. Thanks!

--
Jon

13

But you said static addresses do not always work.
Just to be sure I have paid attention:
You are running Raspian v10 on a pi zero.
You have a cellular gateway wired to the router on the WAN port.
You have disabled the WIFI on both the Pi-hole and the gateway.
The pi-hole is wired to a LAN port and you use the router for wifi. But even if you plug in your laptop on a LAN port it, sometimes, sees neither the router nor the Pi-hole an sometimes just the Pi-hole is unreachable?
Just curious: is Bluetooth also disabled on the pi-hole?

And what is the USB charger power rated for in amps?
Is a quality charger or something like one sold at drugstores?

Are you using an inverter for the router, or is it 12v and you are using 12v from the car?

When you assign a static address, you should see some address already there. It is in the same range as the gateway's range?
The router and the gateway are set to different ranges, right?

Try this next time you cannot see the Pi: turn off the gateway, if you do not have a spare cable, use its cable and plug the laptop into a lan port and see if the pi is reachable.

If that does not work, disable IPv6 on the router. Apple prefers IPv6 and it is easiest to set it up, correctly, when you first install pi-hole, you see its IPv6 address then, and direct the router to that address too.

I guess the last ditch is you have a crappy USB to Ethernet adapter.
I know most tutorials show them being used, but I use wifi and it works fine.

14

Just to clarify, this is specifically regarding the workflow where the Pi is wired in and working fine, then the ethernet connection to the router is broken for some period of time, then plugged back in to the Pi. In that situation:

Raspbian v10 on P0w :white_check_mark:
Cellular gateway to Router WAN :white_check_mark:
Disabled wifi on P0w and Gateway :white_check_mark:
P0w wired to LAN port :white_check_mark:
Router emitting only wifi in the mix :white_check_mark:
Plug laptop into router sometimes it sees neither router nor P0w :yellow_circle:
:arrow_right_hook: I can always get my computer to 'see' and talk to the router (and use the web interface) via manual IP setup. Having to do it via manual IP setup is itself an indicator that the P0w, while connected via wire to the router LAN port, isn't talking to the network. But once I do get the laptop talking to the router / connected to the network, the 'chatting with the router' all goes well, but neither the laptop nor the router can ping/see/talk to the P0w.

Yes. Eliminating 2.4ghz interference all around :stuck_out_tongue:

It's running off 12v directly from the vehicle through a quality 12v-to-USB converter (which, to my knowledge, just down-steps the voltage from 12 to 5)

I'm not sure what you mean by 'when you assign a static address you should see some addresses already there'. On the router side I disabled DHCP fully and just told it that the DHCP server is at 192.168.1.146. On the Pi side I told it that its static address is 192.168.1.146 and enabled the DHCP server.

The latter question occurred to me last night but yes, I believe they're set to different ranges. The gateway uses 192.168.12.1/24 and the router uses 192.168.1.1/24. I should double check to make sure both are for sure using /24.

I'll experiment with this a bit more here in the next couple of minutes. Along with the IPv6 as well (though I don't think I've ever been given an IPv6 LAN address throughout this whole process)

:joy: I hope not! I actually did watch the LED indicators on the adapter last time I was trying to get it to reconnect and they did spark up when I plugged the cable back into the Pi. Green (right) was solid (...which should indicate a working connection :facepalm:) and yellow was blinking at a slow, steady rate. Maybe once/second. I feel like if there was actual packet movement and correspondence going then yellow should've blinked more rapidly / randomly, but that's only a guess on my end.

Aside from all this, thanks again for continuing to dig in with me here, @LilRedDog. I appreciate you brain-efforts on this tremendously.

15

Alright.. well.. this is interesting.

I went ahead and fired up my router fully then plugged in the Pi (I shut it off properly last time) but didn't involve my cellular gateway in the mix at all this time around — just left it off. It has terrible signal at the moment anyway. Well lo and behold, things booted up normally and I started a ping to the Pi while watching the router web dashboard. Unplugged the Pi's ethernet, watch the ping begin to fail.. waited about 10 seconds, plugged it back in, and the ping started coming back through. Repeated with more like a 2-3 minute break (long enough for the router's web dashboard to agree that the client is no longer connected), plugged it back in, and within 15 seconds the ping was coming back again. So that's.. surprising.

Going to have to experiment more with the Gateway being in / not in the mix :thinking:. More to come —

16

When you go into your adapter settings, to set up a static address, there should be numbers you overwrite, especially over Ethernet..

And I would try to plug the, misbehaving, P0w directly into the laptop and see if it talks to the laptop then when it will not go through the router. We need it acting up. If you can talk to it, then go back to obtaining DHCP automatically, and see if the P0w assigns an address.
That steady blinking that was not random might indicate it is trying to get out but it isn't. Eliminate the router as a problem.

The firmware is all up to date? That includes Raspian and not just the Pi-hole and the router. Do that first.

Update-Raspian first, then pi-hole, reboot.

You could have corrupted the SD card but not so bad that it disabled it completely. But we need to narrow it down. If the P0w talks to the laptop, then we know It is somewhere in the router. If it will not talk, directly, to the laptop, the P0w is corrupted.

17

That is interesting. Is the gateway set to only be a gateway and not do anything else?

18

Sort of in the middle of dogfood'ing everything to see what happens but re: the gateway I believe it's being both a cellular modem and a NAT/router (so my router adding its own NAT layer means everything is double NAT'd... not an issue for my use-cases but good to know). It's also an AP but I have the radios disabled. I unfortunately get very little control over the hardware :confused: it's an all-in-one box that I had to sniff the web UI of to even find an API that allowed me to disable the wifi radios :facepalm:

19

No, you do not want that.

Lookup how to set up that particular gateway to passthrough mode.

What model is it?

20

Blarg. I swear this same exact process didn't work for me a couple of days ago :confused:

In attempting to get things more smooth with having the Pi powered 24/7 but with the router/gateway being transient, I left the Pi running while I killed the router and gateway then specifically followed the order of:

  1. Boot gateway fully
  2. Boot router fully w/o P0w ethernet line connected (P0w still running)
  3. Connect P0w to fully booted router
  4. Connect laptop to wifi

Laptop connected to wifi just fine with DHCP and an IP address from the PiHole, long-running ping to Pi started coming back just fine. Grr! I swear this didn't work before. Maybe I blew a step or something. At least I can document this now.