[SOLVED] Dnsmasq DHCP - Not possible to delete dynamic lease?

[jamesaepp]

- The reservation IP address was already dynamically leased to another host. In that case the original host will receive the old IP as fallback, until that lease expires. Otherwise there would be duplicate IP addresses.

Can you check for that?

Definitely not. My process was approximately as follows:

1. Shutdown original system (which has the host definition/DHCP reservation outside the dynamic pool/range).

2. Reduce DHCP lease time from 8 hours to 1 hour (3600 seconds).

3. Install fresh installation of TrueNAS Scale (TN) on new motherboard with new NIC. It gets a lease from pool/range.

4. Restore configuration of TN. (Configuration restore creates a bridge interface, but doesn't maintain the same MAC as before step 1).

5. Figure out the MAC of the bridge interface, update host definition. Apply. Restart Dnsmasq.

6. Wait over an hour, no change. Reboot the TN. No change.

7. Make your recommended DHCP authoritative change, restart dnsmasq. Reboot the TN. No change.

8. Wait over an hour, no change.

9. Give up, set the TN box to the desired "permanent" reserved/static IP address. Wait an hour. Check that the old lease is gone, switch TN box back to DHCP. Works.

I didn't notice/check them at the time of all these issues, but the webui's Services > DNsmasq DNS & DHCP > Log File page has the following two warning events repeating over and over. Pretend 192.0.2.100 is a dynamic address, and 192.0.2.10 is the reservation.

Code Select Expand

not giving name HOSTNAME to the DHCP lease of 192.0.2.100 because the name exists in /var/etc/dnsmasq-hosts with address 192.0.2.10
not giving name HOSTNAME.SUBDOMAIN.DOMAIN.TLD to the DHCP lease of 192.0.2.100 because the name exists in /var/etc/dnsmasq-hosts with address 192.0.2.10


[Monviech (Cedrik)]

For me it works exactly as described above, and as outlined in the Dnsmasq source code.

Workflow:

- Windows Client gets dynamic IP: 172.16.0.132
- Give it a reservation: 172.16.0.108, press Apply
- Reboot Windows Client
- In tcpdump you can see that client requests 172.16.0.132, but gets a DHCP NAK and then does a full DHCP Discover
- Windows Client gets static IP: 172.16.0.108 after reboot.

---- Before reboot ---
- Here the client asks and receives its current IP address (172.16.0.132) /before/ getting a reservation

Code Select Expand

No. Time Source Destination Protocol Length Info
1 0.000000 0.0.0.0         255.255.255.255 DHCP 354 DHCP Request  - Transaction ID 0x65f20d29
2 0.022221 172.16.0.1 172.16.0.132 DHCP 376 DHCP ACK      - Transaction ID 0x65f20d29

---- After reboot ---
- Here the client asks for its old IP address (172.16.0.132), but is actively denied by Dnsmasq (DHCP NAK)

Code Select Expand

3 184.282607 0.0.0.0         255.255.255.255 DHCP 354 DHCP Request  - Transaction ID 0x1e64e5aa

Frame 3: 354 bytes on wire (2832 bits), 354 bytes captured (2832 bits)
Ethernet II, Src: Microsoft_c1:24:4c (f0:6e:0b:c1:24:4c), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Request)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x1e64e5aa
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: Microsoft_c1:24:4c (f0:6e:0b:c1:24:4c)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Request)
        Length: 1
        DHCP: Request (3)
    Option: (61) Client identifier
    Option: (50) Requested IP Address (172.16.0.132)
        Length: 4
        Requested IP Address: 172.16.0.132
    Option: (12) Host Name
    Option: (81) Client Fully Qualified Domain Name
    Option: (60) Vendor class identifier
    Option: (55) Parameter Request List
    Option: (255) End

4 184.304084 172.16.0.1 255.255.255.255 DHCP 342 DHCP NAK      - Transaction ID 0x1e64e5aa

Frame 4: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)
Ethernet II, Src: Deciso_00:d9:f4 (f4:90:ea:00:d9:f4), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 172.16.0.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Dynamic Host Configuration Protocol (NAK)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x1e64e5aa
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: Microsoft_c1:24:4c (f0:6e:0b:c1:24:4c)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (NAK)
        Length: 1
        DHCP: NAK (6)
    Option: (54) DHCP Server Identifier (172.16.0.1)
    Option: (56) Message
    Option: (255) End
    Padding: 0000000000000000000000000000000000000000000000000000

- Now a full DHCP Discover starts, and the Reservation IP (172.16.0.108) is offered and ACK.

Code Select Expand

5 184.385874 0.0.0.0         255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0xb123c37e
6 184.406124 172.16.0.1 172.16.0.108 DHCP 348 DHCP Offer    - Transaction ID 0xb123c37e
7 184.414919 0.0.0.0         255.255.255.255 DHCP 360 DHCP Request  - Transaction ID 0xb123c37e
8 184.448230 172.16.0.1 172.16.0.108 DHCP 376 DHCP ACK      - Transaction ID 0xb123c37e


There must be some sort of difference in our configuration, how we do things, or how different clients handle this. Essentially it should be explainable in some way.

[jamesaepp]

>Give it a reservation: 172.16.0.108, press Apply

Maybe there's a misunderstanding. What I am reporting and what the others (I think) are trying to report is the below "problem", not what you describe:

1. A DHCP reservation/host definition exists for an IP/MAC binding.

2. A (planned or unplanned) failure occurs to the original device with that MAC.

3. A new device with a new MAC to replace the original device/MAC is added to the network and gets a DHCP lease.

4. After the reservation/host definition is updated with the new MAC, Dnsmasq is not NACK'ing DHCP discovers/requests and is continuing with the temporary lease in spite of the reservation/host definition.

[Monviech (Cedrik)]

I understand but I guess that makes sense.

Dnsmasq does not know if the old client MAC ever comes back as long as the lease time is still valid.

It will fall in the code path:

- The current (changed MAC address) reservation overlaps with an existing (old MAC address) lease, thus it will not be offered, a dynamic lease is offered instead.

[jamesaepp]

Few different comments I guess.

* So I could be mistaken, but I don't *remember* seeing the original reservation's lease on the Leases page after the reservation was edited to the new MAC address (the right-hand graphic had the magnifying glass to go straight to the host configuration, versus the + sign to add a new one).

* I think this discussion proves there *is* merit to having a function to delete a lease. Whether or not Dnsmasq can do this is a separate question.

* Perhaps this is the wrong forum for this discussion and it needs to be had 'upstream'.

* I didn't think to try it before an earlier comment of yours (Cedrik) but maybe an appropriate workaround would have been to completely delete the reservation/host definition and re-create it. It may not be quite so simple, however.

[Monviech (Cedrik)]

I guess if there is merit or not also depends on network design.

Some might consider giving servers static IP addresses manually, and letting DHCP handle clients.

The IP address itself might also not be as valuable if most of the network uses dynamic FQDNs which Dnsmasq can register.

If you think there is a usecase we did not consider, open an issue on our github page.

The viability to add this to dnsmasq has been tried out, and its complicated. A delete button is very niche and it looks like only needed for a very specific edge case. Offering it broadly suggests its a requirement, when it is not in most cases.

https://github.com/opnsense/core/pull/8899