Seamless roaming between APs is broken by Pi-hole

I have a LAN with two wireless access points, of which one is the ADSL router. They normally hand over seamlessly to each other as clients move around.

The ADSL router does not offer the option to specify another DNS server on the LAN, so in order to introduce Pi-hole into the LAN, I turned off the DHCP server in my ADSL router and turned it on in the Pi-hole. After this change, clients can no longer roam seamlessly. They successfully authenticate and get an IP address from Pi-hole via one of the APs, but when they later try to connect to the other, they fail to get an IP address.

I'd be grateful for any ideas.

This sounds like a networking issue, rather than Pi-hole related.

Likely, your AP is stil relaying DHCP requests to your router instead of the new DHCP server, your Pi-hole machine.

Restarting the AP may sometimes work to fix it by having your AP request a DHCP lease through Pi-hole, but you may have to configure your AP or your router to explicitly relay DHCP requests to Pi-hole.

You'd have to consult your APs and/or router's documentation and support on how to achieve this.

The clients are granted IP addresses by Pi-Hole, as can be seen from the "Currently active DHCP leases" table under Settings/DHCP. It is when they later try to connect via a different AP (on the same subnet and with the same gateway) that they are not granted an IP. Therefore, the WiFi connection times out. They are still able to connect via the original AP, but not the second. This happens regardless of which AP they first successfully connect to.

I think you may be right that it is a networking issue, but I have tried a lot of things already to no avail so that is why I thought I would ask here. The Pi-Hole is the first DNS server I have tried to introduce into the network, so I am unable to say whether this behaviour is specific to Pi-Hole. When I find the time, I might try to set up a non-Pi-Hole DNS server on the RPi and see if the same problem arises.

Any other ideas?

This is not about DNS, it is about DHCP.

Did you consider:

Thanks, yes I have tried:

  • Restarting both APs
  • Releasing the DHCP leases from Pi-Hole
  • Rebooting the RPi Pi-Hole host
  • Forgetting the AP setting on clients
  • Rebooting the clients
  • Turning the DHCP server off and on again on Pi-Hole

How are the routers connected to the PI? And could you elaborate on the settings you used on each of the routers?

This is a schematic:

                           +------built-in AP-----WiFi clients
Internet --- ADSL router---+----Ethernet cable----Pi-Hole
                           +--Powerline adaptors--2nd AP--WiFi clients
                           +----Ethernet cable----other clients

Please note, all this works fine prior to introducing the Pi-Hole as the DHCP and DNS server.

The settings on the ADSL router (192.168.1.1) are to disable DHCP server. The second AP (192.168.1.2) is set to use 192.168.1.1 as gateway. Pi-Hole (192.168.1.x) has DHCP server turned on and is set to hand out a range of IP addresses 192.168.1.3-255. All clients are set to obtain IP and DNS server addresses automatically. Some clients, such as the Pi-Hole, have static IP addresses defined in the ADSL router (and when trying to use the Pi-Hole as the DHCP server, those static IP assignments were mimicked there too).

Thanks for that, but I don't get this, how does the second router connect to the pi? Over WiFi? Or powerline adaptor to a USB ethernet dongle on the pi?

The second AP is connected via ethernet cable to a powerline adapter. The powerline adapter in the other end is connected via ethernet cable to the ADSL router. The ADSL router is connected to the Pi via ethernet cable.

The settings on the ADSL router (192.168.1.1) are to disable DHCP server. The second AP (192.168.1.2) is set to use 192.168.1.1 as gateway. Pi-Hole (192.168.1.x) has DHCP server turned on and is set to hand out a range of IP addresses 192.168.1.3-255. All clients are set to obtain IP and DNS server addresses automatically. Some clients, such as the Pi-Hole, have static IP addresses defined in the ADSL router (and when trying to use the Pi-Hole as the DHCP server, those static IP assignments were mimicked there too).

Router: 192.168.1.1
AP: 192.168.1.2
Pi-Hole 192.168.1.X ?
DHCP Range 192.168.1.3-255 ?

Look like your DHCP range is overlapping your Pi-holes static address? Unless its a typo.

That's right. I've had my static addresses assigned within the dynamic range for decades and never seen any IP address conflicts. If you suspect this to cause my issue, I'd be interested to understand how.

To me this looks like a networking issue, yes. But somehow differently than what has been said here, so I'll elaborate.

First, I have to modify your graphic because it is not exactly correct. It suggests that the Pi-hole can directly connect to the "other clients". However, this is not the case. It has to go through the ADSL router (which acts as a switch here). And this is exactly where things may be going wrong.

                  | ------- built-in AP-----WiFi clients
Internet --- ADSL router
                  |||| --- Port 1 --- Ethernet cable----Pi-Hole
                  ||| ---- Port 2 --- Powerline adaptors--- 2nd AP --- WiFi clients
                  || ----- Port 3 --- Ethernet cable ---- other client 1
                  | ------ Port 4 --- Ethernet cable ---- other client 2

Is "other client" a switch in your schema above? Or are there multiple Ethernet cables going to the router using this one as a switch? (I assumed the latter in my modified schema)

Sorry for being that nasty, but it is important to get this exactly as any involved device may be altering (like filtering) the network traffic. Only if we know exactly which device is connected where to what, we can start iterating.

Question 2: If you assign a static IP to one of your devices and connect it to the 2nd AP, everything should work. Can you verify this? If so, it really is isolated to a DHCP issue.

Question 2.1: Can you access the Pi-hole from a client connected to the 2nd AP (when it has a static address)?

Normally statics IP within a DHCP range is will work if the static is assigned by the DHCP. Which I have a feeling was your previous case (i.e. the router). In this case the the static and dynamic assignments are being make by the same device. This device is awhere of what assignments have been made so it will not assign the smae IP to separate devices.

In your current setup the router has assigning a static IP to your DHCP and your DHCP is told it can assign that same IP to a device (i.e. a switch). In turn the assignments are coming from separate devices. Now what happens is the router will assign “3” to the pi-hole and then the pi-hole can assign 3 to whatever is wants. When a second device connect the router tell it to get an IP from “3” which is in use by two units.

A siomple google for "static ip within dhcp range" might bettter explain than I can.

https://superuser.com/questions/900074/does-the-dhcp-server-know-about-static-ip-addresses

I get that, but as I mentioned further up I replicated the static IP assignments from the ADSL router to the Pi-Hole when I activated DHCP in the Pi-Hole and turned it off in the router. So if a particular MAC address used to get 192.168.1.65 from the ADSL router, it now gets 192.168.1.65 from Pi-Hole.

I suppose there could still be a clash if both the ADSL router and the Pi-Hole attempt the same static assignment – but if that were the cause of my problem, how come that it works when the client first gets its IP assignment from whichever AP it first connects to and then the problem only manifests itself on switching to another AP?

I'll provide a full schematic, but I don't think it necessarily makes a difference since the problem I have observed is only with the clients that connect via one of the APs, not with clients connected via Ethernet.

                  | ------ built-in AP-----WiFi clients
Internet --- ADSL router
                  |||| --- Port 1 --- Ethernet cable----Pi-Hole
                  ||| ---- Port 2 --- CPL -- mains circuit -- CPL
                  ||                                          ||| -- Ethernet cable -- 2nd AP --- WiFi clients
                  ||                                          || -- Ethernet cable --- client
                  ||                                          | -- Ethernet cable ---- client
                  || ----- Port 3 --- Ethernet cable ---- Set-top box
                  | ------ Port 4 --- Ethernet cable ---- Unmanaged switch
                                                          | -- Ethernet cable -- client
                                                          | -- Ethernet cable -- client
                                                          | -- Ethernet cable -- Router for geo-unblocking --- client

Q2: I'll try this later, thanks.
Q2.1: I have accessed the Pi-Hole successfully from a client associated to the second AP, but I haven't tried this with a static IP – so will try that at the same time as I test your other question.

That covers the "may sometines work" part only.
Did you check if and how your AP and router handle DHCP relay?

The ADSL router is a rather locked down ISP box so it's not possible to tell whether it does/can do DHCP relay. The AP is DD-WRT so it can act as a DHCP forwarder. However, I have not activated this since everything is on the same subnet so I would not think DHCP relay is required. And, as I mentioned, regardless of whether the WiFi clients first associate to the DD-WRT AP or the ADSL router, they successfully get an IP from that first connection. It is when they attempt to connect to the other AP (either ADSL router or DD-WRT AP) that they are only able to authenticate but not get an IP.

DHCP broadcasts are only visible on the same network segment.
A DHCP relay forwards DHCP to another network segment, regardless whether that would use a separate subnet or not.
If your second AP would constitute such a segment, a client's broadcast for a DHCP server would never reach Pi-hole without a DHCP relay.

But that may indeed not apply here, since you've clarified that a client may succesfully acquire a lease through either of your APs (not just one, as I read your initial statement to mean).

I don't even think it's DHCP nor DNS then, it woud be wireless routing.
If your network is indeed just one segment, then a roaming client already holding a valid DHCP lease for the same network/SSID wouldn't be strictly required to acquire a new lease when switching from one AP to another.
All that has to be done is updating routing tables. Your Wifi APs along with your router and your client should take care of the hand-over.

Do you have any hints that your client would try to (re)negotiate a DHCP lease at all?

OK, I have now done some further testing. I changed the assignment of IPs so that DHCP only hands out addresses 192.168.1.20-192.168.1.255 and put the static IPs in the range 192.168.1.3-192.168.1.19. I added one of my WiFi clients as a static IP 192.168.1.3. I made the 2nd AP a "DHCP Forwarder" in DD-WRT parlance and gave the IP address to the Pi-Hole as the DHCP server.

Unfortunately, this has not rectified the issue.

Nope. The client can successfully connect via the 2nd AP, but when later trying to switch to the 1st AP (the ADSL router), it hangs on "Obtaining IP address" – as before.

Yes – accessing the Pi-Hole GUI is not a problem from anywhere, static or dynamic.

I have been interpreting the WiFi clients hanging at "Obtaining IP address..." as a sign that they are trying to renegotiate a DHCP lease, but please tell me if this is an incorrect interpretation.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.