Teleporter doesn't import Static DHCP leases?

General Beta 6.0
11

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)

image
image985×421 15.6 KB

Advanced description (click to open more details)
  • 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.

4 Likes