How to disable the DHCP server on a TP-link Deco mesh network
I recently moved house and, for the first time ever, was able to upgraded my broadband to fibre to the premises. This is great, and I now have a superfast internet connection. Only problem being that my old pfSense firewall/router cannot keep up with how fast it now needs to route the traffic.
When I did the original pfSense install, I got lucky with a USB 3 NIC that miraculously just worked first time with the intel atom based Dell Wyse nuc I had to hand. But after an unfortunate incident the NIC got damaged leading to me resorting to me moving to a VLAN based setup sharing the only onboard NIC. For the most part it ticked along fine but, now that I have a faster WAN connection, as soon as someone tries to use more bandwidth than the interface resets causing packets to drop. Interestingly nothing appears in the pfSense logs when this happens which has made it almost impossible to troubleshoot. An upgrade to pfSense+ has made it a little bit more reliable, but under high load the interface still is not up to it.
The move also coincided with me deciding it was time to purchase a TP-Link Deco mesh Wi-Fi system. The thought process behind this was twofold.
First off, I had been paying £10 a month for almost two years for a Wi-Fi extender from my broadband provider. Quick maths estimates that I had spent nearly £300 on a pretty mediocre Wi-Fi extender that I had zero control over.
Second. I was facing having to add all of my Wi-Fi based smart home devices to a new network again. This has, of course, organically grown over the past few years a couple of devices at a time and never had to move all at once.
The hope was the mesh nature of the Deco system would allow me to up or down scale the network for any further moves, and also never have to rejoin all the devices in one go.
The work around
Now I know that I could upgrade to a more suitable host, or even buy an actual netgate device, but I don’t really have the time to fully rebuild my network. So I came up with the genius idea. Why does pfSense have to be the default gateway? Could I not just turn off the DHCP server on the Deco side and allow it to do most of the heavy lifting and only have devices that need to talk to the other network talk to pfSense? This method would allow every day devices that are bandwidth hungry; the TV, The Wife’s phone etc; a direct route out to the fibre connection and then I can use my local DNS server to provide access to anything in another network that might need it.
ISP modem → TP-Link Deco (in router mode) ← pfSense as the DHCP server.
The only problem? You can’t turn off the DHCP server on a Deco mesh in router mode 🤦🏽. After surfing through the forums there have been many promises from, I am assuming, TP-Link support that it is an idea that has been passed on to R&D. But now over 2 years since these posts I am facing the same problem. This obviously means that it is not a high priority for TP-Link, again I assume, as people who wish to run their own DHCP server are only a small subset of their customer base.
The solution
After about half a day of sulking, The Wife was not best pleased with the lack of internet, I wondered what would happen if I created a small DHCP pool in the Deco system but then filled all addresses with fake devices. The question is what would happen if Deco wanted to hand out IPs but didn’t have any to give? Now, having two unconnected DHCP servers in a network is normally a big no no, but in theory this might work.
The first slight gotcha is that the smaller DHCP pool you can create on the Deco is 20 addresses. While I’d rather not have lost these 20 addresses, I deemed a roughly 7% sacrifice to be an acceptance exchange to using my own DHCP server. Filling the address pool took a good few minutes of me typing out static reservations on my phone.
The first few attempts were a bit of a flop. Apparently the MAC addresses 00:00:00:00:00:00 and 00:01:02:03:04:05 are not valid addresses. Go figure. I eventually resorted to a googling a fake MAC address generator, which gave me an address that Deco accepted as real. To keep things simple, I matched the last 2 digits of the MAC address with the last 2 digits of the final octet of the IP address. This isn’t strictly necessary, but it keeps the static address page looking pleasing, clean.
The slightly less pleasing part is I had to stack those 20 address right in the middle of my subnet. As pfSense already had static assignments both at the beginning and the end, I chose to use the range 192.168.x.150-192.168.x.169. In hindsight, I probably could have used 192.168.x.180-192.168.x.199 as nothing had yet been assigned there, but I have now typed everything out now, so it’s staying put. This also means I had to split my DHCP pool in pfSense to accommodate this mini pool. Once this has all been configured, it’s time to give it a whirl. Time to find out if I had found a hacky way around the problem, or had I broken the internet even more and annoyed The Wife further by not unpacking more boxes. Miraculously, it actually worked with my laptop picking up an address from pfSense, rather than not being able to connect as it previously has when I filled the entire Deco DHCP pool with fake MAC addresses.
How DHCP actually works
Before we dive into why this works, we should probably do a brief recap of how the DHCP request process actually works, so we know what we are looking for.
- When a device joins a network, it sends a message called a DHCP discover to port 67 of the IP address 255.255.255.255. This address is known as the broadcast address and the port is, surprise surprise, the one that a DHCP server will listen on. As the name suggests, this message is then broadcast to every device on the network. As the device currently has no IP address, it puts 0.0.0.0 as the source of the packet, but does put its own MAC address in.
- So if we have one or more DHCP servers listening in the network they will receive this message, on port 67, and respond to it. The server takes that mac address from the packet and has a look at its address table (and because it is all knowing) and if it finds the address then it will respond with the corresponding IP address. If it does not find the IP address, then it will look to see what the next available one is.
- The server then sends an Offer packet to this new IP address (using our device’s MAC address) and as switches work on MAC addresses rather than IP address the switches in the network forward this packet to our device. The Offer packet also has a few other bits of configuration bundled along with it.
- After our device has received the DHCP Offer, it will again broadcast to the entire network (to alert all listening DHCP servers of the intended IP address), again using the address 0.0.0.0 (because it hasn’t officially been given the OK to use the address yet). The DHCP server will then reply with a DHCP ACK or Acknowledge packet confirming that the device is good to use that IP address. This again happens to that IP address that the server had offered to the device. From this point, that is the IP address that will be tied to that particular MAC address until it expires (There are a few extra configurations passed as part of both the Offer and ACK packages, the expiry is one of these).
- The final step is any of the other DHCP servers listening in the network will now drop any addresses that had reserved for that MAC address, as they have now been told (by the broadcast DHCP Request packet) that the device is accepting a different address.
All of this can be seen in the screenshot below.
From the picture you can see that the DHCP server appears to be on the address 10.101.2.1 and the IP address that it is offering us is 10.101.2.226. I’m not too worried about redacting these IPs, as this packet capture was performed on a public Wi-Fi of a train. So any insight you can gather about the network has very little relevance to me.
Normally, it is a bad idea to have more than one DHCP server in the network. The reason for this is if they are not configured correctly then there is the risk of bad IP addresses or duplicates being handed out as the multiple servers do not keep track of address that they haven’t offered out. I know above I mentioned that you can have multiple DHCP servers, but this is more geared towards having redundant DHCP and is beyond the scope of this post.
Proper testing
After running the setup for a day or so, I started to wonder what was actually going on on the network. To test this, I decided to use Wireshark to test and see what actually happens when a device connects and tries to get an IP address.
From the packet capture, you can see that the process is pretty much the same. We have the Deco DHCP server on 192.168.X.254 and pfSense on 192.168.X.253. The only difference is there are a couple of additional packets sent from the Deco DHCP server. These packets are both NAK or Negative acknowledgment. This is the DHCP coming back to tell the device that it does not have any more IP addresses left to assign. If we only had the one DHCP server, then our device would not get and IP address and would not be able to connect to the network. As we do have a second DHCP server, it also receives the broadcasted packets and replies with a DHCP offer which, hopefully, our device accepts.
Something else to note is there is an extra DHCP Request and ACK/NAK reply in this packet capture. This is due to me clicking the renew DHCP lease button on macOS, which seems to start the process off by resending the current IP address as a Request.
Summing up/TL;DR
While there is no direct method to disable the DHCP server on a Deco mesh network, it is possible to create a tiny DHCP pool and exhaust it with fake MAC addresses with static assignments. This then forces the Deco DHCP server to negatively reply to any DHCP request made on the network, allowing for our preferred server to assign an IP address.
There is a minuscule chance that one day you may buy a device that has a MAC address that matches one of the fakes you have created. If this is the case, then you will probably want to go and replace that static reservation. However, the chances of that happening are extremely low, although slightly increased by the process of randomly generating new MAC addresses for privacy.
If this has helped you out, pop a comment below, as others may also find it useful. Likewise, if you 100% disagree with what I’ve written here, have your say below. Or better still rewrite the post and submit a PR against the GitHub repo and I will review and consider your opposing point of view.