Tp-link has a weird configuration on their routers that prevents disabling DHCP, and the router also doesn’t do local name resolution on the DNS.
It would be nice if pihole could passively monitor DHCP requests and responses to fill in local resolution.
I'm not sure if that is possible.
The lease request from the client is a broadcast packet and that could be looked at however, the response with the actual lease offer is unicast from the DHCP server to the client and the acknowledgement from the client to the server accepting the lease offer is also unicast.
What about monitoring the DHCP lease request for the host name and logging that into the database with the mac address to later be matched to the ip on DNS request?
I see no use case for this request that isn't already covered by existing features.
You already can enable Pi-hole's Conditional Forwarding to query your router for known local names.
And if Pi-hole is acting as DHCP server, it will already add the required records to its DNS server automatically.
That's the thing, a lot of TP-Link routers have neither a local DNS resolver, or the ability to disable the DHCP server.
I'm not sure if the entire Deco line is that way, or just the x60 that I have, but they all use the same app.
Are you sure for your router?
Check with below if your router creates DNS records (A, AAAA and PTR) for hostnames that are advertised by your clients during the DHCP lease transaction:
dig +short @<ROUTER_IP> -x <CLIENT_IP>
Eg:
pi@ph5b:~ $ dig +short @10.0.0.2 -x 10.0.0.9
avr.home.dehakkelaar.nl.
If so, Pi-hole's Conditional Forwarding would be sufficient to discover the hostnames behind the IP's that the pihole-FTL daemon knows about.
Your FR would mean you'd have to sniff/capture all port 67 UDP broadcast traffic all the time similar to below:
pi@ph5b:~ $ sudo tcpdump -nvi any udp port 67
[..]
17:31:45.361188 eth0 B IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 336)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX, length 308, xid 0xa1c25f7b, Flags [none]
[..]
Hostname (12), length 11: "avr"
[..]
If your router doesn't support disabling DHCP, you could still shrink its DHCP range to accommodate just your Pi-hole host's IP, configure a DHCP lease reservation for it, and have Pi-hole's DHCP use a range that wouldn't overlap with your router.
Some rare routers may force a certain minimum DHCP range - mostly, for two addresses (e.g. 192.168.1.2 to 192.168.1.3).
To avoid any DHCP clients to register with your router in that case, configure one fixed IP for your Pi-hole host's MAC, and fill the other slot with a bogus MAC.
@deHakkelaar Running that dig command against the router displays nothing.
Running nslookup against the router IP for a known local hostname also returns nothing.
@Bucking_Horn I never thought about making the pool so small and "disabling" it like that.
Unfortunately, and very annoyingly, the guest and primary networks share the same DHCP server even though they are isolated from one another.
I'm seriously thinking about just putting these in AP mode and putting another more fully-featured router behind the APs
I found this ("listen to DHCp broadcasts") an interesting idea and started investigating this in my small network. For this, I used a TP-Link WR841 which I had sitting in the cabinet. However, bad news: The "broadcasts" seem a lot less broad than thought: At least this router sends the broadcast only on the port it received the request. This is obviously a good idea to reduce unnecessary network traffic on all the other ports and shows that such a feature could easily fail while this wouldn't be simple to fix.
If you still want to use this router, one might be able to circumvent it by setting the pool to something like 10-20 (assuming 10 IPs will be enough for your guests) and block these IPs manually in the main network with IP reservations for devices that do not even exist. Ten is still a low-enough number for manual records.
However, I do agree on the idea of getting another router. If the setting are so limited ... who known how well the firewall, etc. works. Does this router even receive security updates?...
That is odd, the initial DHCP request from the client without a source IP 0.0.0.0 should be to the broadcast destination address 255.255.255.255 meaning it should be broadcasted on all switch ports for that network segment/broadcast domain ... to my knowledge.
And the reply from the DHCP service should switch to unicast instead of broadcast as depicted below:
pi@ph5a:~ $ sudo tcpdump -nvi any udp port 67 and udp port 68
[..]
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 0c:2f:b0:XX:XX:XX, length 308, xid 0x32d760d0, Flags [none]
[..]
Hostname Option 12, length 11: "hak-phone"
[..]
10.0.0.2.67 > 10.0.0.143.68: BOOTP/DHCP, Reply, length 312, xid 0x32d760d0, Flags [none]
[..]
Below is a Windows client of mine renewing its lease (which it does very often):
pi@ph5a:~ $ sudo tcpdump -nvi any udp port 67 and udp port 68
[..]
10.0.0.11.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1e:0b:XX:XX:XX, length 300, xid 0x7a45a3b6, Flags [Broadcast]
[..]
Hostname Option 12, length 6: "hak-pc"
[..]
10.0.0.2.67 > 10.0.0.11.68: BOOTP/DHCP, Reply, length 300, xid 0x7a45a3b6, Flags [Broadcast]
[..]
At least thats what I can make of it 
Nice from you for looking into it!
EDIT: Ow ps. above ph5a host also does DHCP service for my network.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.