I've been trialling Pi-hole v6.0 beta on a Raspberry pi 3a+
Core vDev (development, e682f69a)
FTL vDev (development, cbd53445)
Web interface vDev (devel, 7acf4647)
It's seems to work well, so I decided to migrate my existing Pi-hole v5 to the v6 beta. It's only after I used Teleporter to export from v5 & import to v6, that I realised that Teleporter v6 doesn't support importing the DHCP Static leases, only the currently active leases.
Then when I looked at the DHCP configuration for v6, the DHCP Static leases seems to have been reduced to a text-box entry with one address per line - have I understood this correctly? why? This seems a somewhat significant reduction in useability?
Whilst I could find and cut & paste in my Static DHCP leases, isn't this rather a retrograde step??
and see if importing the static leases works thereafter? Unfortunately, I cannot test this myself right now as I don't have a valid v5 Tricorder archive including static leases myself right now.
edit The change is tracked here:
This is what has been added in the massive effort while porting everything one after another to the new v6 way of handing the config. We had quite a few discussions but in the end decided the extra features which are possible (see the examples below) cannot be achieved with a simple table we had before.
Okay, whilst I understand there are technical/operational reasons the Static DHCP leases have been reduced to just a text entry box, I am sorely disappointed by this.
The static DHCP leases is how I managed my LAN with all devices listed (even those with their own device based static IP assignment) and I could sort the list of assignments by IP or device name whenever I was checking out who had what IP & if there were any gaps etc etc. It also allowed me to manage IPs assigned outside the configured DHCP range.
Now, with v6, I'll find it very difficult to manage the list of LAN IPs (including those outside the DHCP range) as it's just a free-formatted & unsorted list of MACs/IPs/hostnames.
So I've tested your Teleporter static DHCP leases fix. It installed successfully on my Pi-hole v6 beta.
I went to my Pi-hole v6 beta & ensured the static DHCP leases edit-box was empty & verified this by refreshing the page.
I then used Teleporter to export from my v5 & import to my v6 beta - it completed successfully & the Pi-hole v6 static DHCP leases edit box was suitably updated.
One question - imported static DHCP leases are unsorted. They seem to be ordered exactly as per the v5 /etc/dnsmasq.d/04-pihole-static-dhcp.conf ? This is a file that doesn't seem to exist on my Pi-hole v6 beta, so I presume that has all changed?
One thing I haven't checked, is that your Teleporter static DHCP leases fix, also covers exporting the static DHCP leases back out of Pi-hole v6 - I'll try doing that now & then re-import it to v6 beta.
(I'm really going to miss/struggle with no easy management of static DHCP leases in v6)
Okay, just tested using Pi-hole v6 beta Teleporter to export everything, wiped out my edit-box of static DHCP leases, and then re-imported everything using Pi-hole v6 beta Teleporter, and my static DHCP list was restored okay.
So export/import seemed to work fine - although the report of what Teleporter imported in v6 beta (see attached image) seems much smaller than what it imported from the v5 file?
(complete aside - with both a Pi-hole v5 & v6 beta on my network, I have real problems logging into both as it keeps telling me "wrong password" & I have to SSH in & change the password. I think this is something to do with two different Pi-holes & cookies?? I guess the problem will go away when I upgrade my v5 to v6 permanently)
I will think about what we can maybe still do about this. But maybe it is rather a v6.1 thing. Sorry about that... The more changes we do, the more often we again have to start over with testing and I finally want to push this through the door because I am confident that is improves in many many other aspects. A bit of debris can be cleaned up with a (probably rather quickly) following v6.1.
Yes, the content is now stored inside pihole.toml (more on this file below)
This is ensured because it all lives in pihole.toml now (again, see below )
Yes, this is expected because pre-v6 we had all stuff floating around in many independent config files and their number has grown over time. Pi-hole v6.0 did a large consolidation effort and collected everything into the single-source-of-truth type of config file /etc/pihole/pihole.toml
I would strongly advocate for restoring the v5 method of managing the static DHCP leases (or something similar) as I found this to be ideal in Pi-hole v5.
Now, I'm going to have to resort to the horrible 'cludge' of maintaining an Excel spreadsheet with the sorted static DHCP leases in and then cutting & pasting into Pi-hole v6 as CSV text. That's kinda horrible isn't it??
I understand your point of view about the new interface to control the static leases, but I disagree with your opinion that this has a "reduction in usability".
In v5, static DHCP lease table allowed a quick management of entries, but it was only possible to add 3 fields:
one MAC address
one IP and
one hostname.
The new v6 DHCP lease configuration allows many other options:
Pi-hole v6 static DHCP lease options (click to open)
Addresses allocated like this are not constrained to be in the DHCP range specified above but they must be in the same subnet. For subnets which don't need a pool of dynamically allocated addresses, you can set a one-address range above and specify only static leases here.
It is allowed to use client identifiers (called client DUID in IPv6-land) rather than hardware addresses to identify hosts by prefixing with id:. Thus lines like id:01:02:03:04,..... refer to the host with client identifier 01:02:03:04. It is also allowed to specify the client ID as text, like this: id:clientidastext,.....
A single line may contain an IPv4 address or one or more IPv6 addresses, or both. IPv6 addresses must be bracketed by square brackets thus: laptop,[1234::56] IPv6 addresses may contain only the host-identifier part: laptop,[::56] in which case they act as wildcards in constructed DHCP ranges, with the appropriate network part inserted. For IPv6, an address may include a prefix length: laptop,[1234:50/126] which (in this case) specifies four addresses, 1234::50 to 1234::53. This (an the ability to specify multiple addresses) is useful when a host presents either a consistent name or hardware-ID, but varying DUIDs, since it allows dnsmasq to honour the static address allocation but assign a different address for each DUID. This typically occurs when chain netbooting, as each stage of the chain gets in turn allocates an address.
For DHCPv4, the special option id:* means "ignore any client-id and use MAC addresses only." This is useful when a client presents a client-id sometimes but not others.
If a name appears in /etc/hosts, the associated address can be allocated to a DHCP lease, but only if a separate line specifying the name also exists. Only one hostname can be given per line, but aliases are possible by using CNAMEs. Note that /etc/hosts is NOT used when the DNS server side of dnsmasq is disabled by setting the DNS server port to zero.
More than one line can be associated (by name, hardware address or UID) with a host. Which one is used (and therefore which address is allocated by DHCP and appears in the DNS) depends on the subnet on which the host last obtained a DHCP lease: the line with an address within the subnet is used. If more than one address is within the subnet, the result is undefined. A corollary to this is that the name associated with a host defined here does not appear in the DNS until the host obtains a DHCP lease.
The special keyword ignore tells Pi-hole to never offer a DHCP lease to a machine. The machine can be specified by hardware address, client ID or hostname, for instance 00:20:e0:3b:13:af,ignore. This is useful when there is another DHCP server on the network which should be used by some machines.
The set:<tag> construct sets the tag whenever this line is in use. This can be used to selectively send DHCP options just for this host. More than one tag can be set per line directive (but not in other places where "set:" is allowed). When a host matches any directive (or one implied by /etc/ethers) then the special tag "known"" is set. This allows Pi-hole to be configured to ignore requests from unknown machines using a custom config option dhcp-ignore=tag:!known in your own config file. If the host matches only a directive which cannot be used because it specifies an address on different subnet, the tag "known-othernet" is set.
The tag:<tag> construct filters which directives are used; more than one can be provided, in this case the request must match all of them. Tagged directives are used in preference to untagged ones. Note that one of <hwaddr>;, <client_id>; or <hostname>; still needs to be specified (can be a wildcard).
Ethernet addresses (but not client-ids) may have wildcard bytes, so for example 00:20:e0:3b:13:*,ignore will cause Pi-hole to ignore a range of hardware addresses.
Hardware addresses normally match any network (ARP) type, but it is possible to restrict them to a single ARP type by preceding them with the ARP-type (in HEX) and "-". so the line 06-00:20:e0:3b:13:af,1.2.3.4 will only match a Token-Ring hardware address, since the ARP-address type for token ring is 6.
As a special case, in DHCPv4, it is possible to include more than one hardware address. eg: 11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2. This allows an IP address to be associated with multiple hardware addresses, and gives Pi-hole permission to abandon a DHCP lease to one of the hardware addresses when another one asks for a lease. Beware that this is a dangerous thing to do, it will only work reliably if only one of the hardware addresses is active at any time and there is no way for dnsmasq to enforce this. It is, for instance, useful to allocate a stable IP address to a laptop which has both wired and wireless interfaces.
For some users, the original 3 fields were fine, but now Pi-hole can deal with a lot more complex entries. This is an evolution.
We intend to improve the current "text box", but at the moment, going back to the original 3 fields will cut the new options.
Just be patient and wait while we try to create a good interface to deal with so many different possibilities.
I was testing the page and (unintentionally) I entered a line containing spaces and tabs. I noticed FTL didn't remove these characters.
Since I was just testing the interface, I didn't bother to look at the logs to see if dnsmasq accepted the values or if the values caused any trouble. I just noticed the JSON was returned like this: