The issue I am facing:
I'm trying to add Option 66 to my Pi.holes DHCP server I've made a 10-TFTP.conf file and added the option to it and it worked for all of 5 minutes then suddenly stopped giving out the IP for option 66. I've also even added the option to the 02-pihole-dhcp.conf file to the same resault. It worked for all of 5 minutes and stopped. Even restarting the system does nothing now.
Details about my system:
8GB RAM
i5 4460S
What I have changed since installing Pi-hole:
Added Adblock Lists, Enabled DHCP, Enabled DNSSEC, Changed WebGUI Port to 8080. Server/computer is also running UISP (Ubiquiti's Network managment software)
Aha, your running an older nmap version 7.40 thats known not to work doing dhcp-discovery.
Could try run apt update/upgrade to see if a newer version nmap is available:
sudo apt update && sudo apt upgrade
You have above two same options configured in two different files.
Ditch that last one!
And dont edit the original "pihole" files manually!
They will get overwritten when making changes via the web GUI or Pi-hole updates.
That 10-TFTP.conf file will do just fine.
Also dont use double quotes " to enclose the 192.168.1.98 address eg:
EDIT: I made mistake, you should use double quotes as documented.
I copy/pasted your details from here and they must have inadvertently contained Windows CR codes or other hidden characters causing my attempt with double quotes to fail ... and also maybe your attempts!
Below works for me so should also work for you if you copy/paste below commands:
pi@ph5:~ $ sudo tee /etc/dnsmasq.d/10-TFTP.conf <<< $'dhcp-option=66,"192.168.1.98"'
dhcp-option=66,"192.168.1.98"
pi@ph5:~ $ pihole-FTL --test
dnsmasq: syntax check OK.
pi@ph5:~ $ sudo service pihole-FTL reload
pi@ph5:~ $
pi@ph5:~ $ sudo nmap -e eth0 --script broadcast-dhcp-discover
Starting Nmap 7.70 ( https://nmap.org ) at 2020-11-21 23:21 CET
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 1:
| IP Offered: 10.0.0.252
| DHCP Message Type: DHCPOFFER
| Server Identifier: 10.0.0.4
| IP Address Lease Time: 2m00s
| Renewal Time Value: 1m00s
| Rebinding Time Value: 1m45s
| Subnet Mask: 255.255.255.0
| Broadcast Address: 10.0.0.255
| Domain Name: dehakkelaar.nl
| TFTP Server Name: 192.168.1.98\x00
| Router: 10.0.0.1
|_ Domain Name Server: 10.0.0.4, 10.0.0.4, 10.0.0.4
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.44 seconds
EDIT2: Ow ps. I noticed when running nmap on the same host that runs the DHCP service, that TFTP option disappears in the nmap output after a minute or so for some unknown reason.
But running nmap from a client machine, it shows that TFPT option consistently
Welp I'll be Honest I dont know what changed but its working now but only from certain clients. But the ones I want working are working haha Thanks for the help there mate!
I see the (yet experimental) pihole dhcp-discover as a tool to find out whether other DHCP servers may also propagate DNS servers that could potentially be used to bypass Pi-hole.
Requesting arbitrary DHCP options may certainly be possible and useful at times, but it's well beyond Pi-hole's scope.
Thats just the DHCP server side which seems to do its job according to nmap.
Its the other v5 Pi thats amiss and not reporting that TFTP option for unknown reason.
Or did I understand you wrong ?
EDIT: ow forgot to mention, I also had the v5 instance function as the DHCP server with same results.
But had in mind that I experienced mixed results before if run the dhcp-discover on the same host that does DHCP.
Thats why I parked the DHCP service on the old Pi so I could run dhcp-discover on the newer Pi with DHCP service disabled.
Reload isn't sufficient when you change any of the config files. You need a full restart of the process (we directly inherited this from dnsmasq where this is the same).
I restarted the pihole-FTL service on the old Pi including the TFTP option.
Same results when do a pihole-FTL dhcp-discover on the newer Pi .. no TFTP.
And again nmap on the newer Pi does show the TFTP option.
EDIT: if its a biggy, dont bother!
Its as Bucking_Horn said before totaly not necessary to display all options.
Its good enough to see DHCP servers active on the net and importantly what DNS servers are advertised.
According to DL6ER's link, the test requests all DHCP options as supported by dnsmasq anyway (apart from the real vendor-specifics, I guess).
However, there are only three mandatory DHCP options a server has to supply with a DHCPOFFER (lease time, server identifier and message type).
All other options may only be presented on request, and even have to be omitted if a DHCP server cannot provide them (see RFC2131 section 4.3.1), so the exact outcome may depend on your dnsmasq configuration.
TFTP parameters (from DHCP's BOOTP predecessor) are a special case though, as they may appear as either a DHCP option or in their respective dedicated separate fields.
Maybe that's why they fail to display reliably (also with nmap)?
The dhcp-discover requests a full DHCP lease. All available information should be contained (even vendor-specific content). All DHCP data is encoded using a type-specific encoding. What I meant is:
All DHCP options dnsmasq understands are also understood by FTL in the way of being able to interpret them. E.g., we can decode something like 4679e5d0a5b664e to
dns-server=192.168.2.1,192.168.2.2
In addition, we support the (still only drafted) WPAD configuration extension
All other (i.e., vendor-specific) options do typically not contain any hints to the specific formatting. FTL will only tell you something like
Unknown option <optcode> with length <length (bytes)>
So, just I get this right: You enabled TFTP in dnsmasq (or pihole-FTL) and a scan from another device didn't pick up these options in the DHCP scan of FTL?
If this is true, I will try setting up a TFTP server myself tomorrow and check what I can find.
If your asking me, yes thats what I experienced.
Enable DHCP + TFTP option on one Pi running pihole-FTL v4.
And do the discovery from another Pi running pihole-FTL v5.
Do you think you actaully need an active TFTP server for the discover to work ?
As posted before, I can see the TFTP option 192.168.1.98 in the reply when do a tcpdump on the host doing the pihole-FTL dhcp-discover but it just wont show.
But it does show when do a nmap dhcp-discover.
Ah, looking at this again, sure, that's the reason.
@deHakkelaar this is also what is/was happening here:
Without dissecting this now in detail, the 192.168.1.98 is the bootp.server (string with fixed length of 64 bytes). Thereafter, you see many 00 (this is the bootp.file field, fixed length of 128 bytes) and finally 6382 5363 (DHCP magic cookie).
