Messages

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.

>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.

- 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


Setting the checkbox for "DHCP authoritative", applying, restarting dnsmasq, and then restarting the client had no effect. Client still requests and is given the leased IP.

Yeah....I just did a similar set of work today, not exactly the same....but dnsmasq doesn't appear to be respecting the host configuration. I absolutely hit the apply button and I even restarted dnsmasq for good measure, but the packet capture is clear as day. When the DHCP client rebooted, it did a DHCP discover requesting the temporary/dynamic/lease-pool address it had previously, offered it, and acknowledged it.

Idk. I'm on the fence on whether this "issue" merits a dev response or not.

It certainly would be a nice to have and similar router/firewall software offer lease deletion.

However, this is a "two to tango" and in my case, my client (TrueNAS, but I fail to recall what version it was at the time) eventually did pick up the new lease after the existing lease expired (IIRC my setting is a 24-hour lease). A simple administrator workaround is to appropriately configure their lease times.

I agree with a previous commentor where they said (paraphrasing) that if the DHCP client isn't RFC compliant and isn't assuming it should grab a totally new lease on reboot, it's the fault of the client and not OPNsense. To this part, I am in full agreement. I certainly can't quote the RFC off the top of my head, but I recall reading language within it that DHCP clients should not assume they're on the same network segment as before a major system event such as a reboot. I think there's something in there about a NIC connection change too, but again - none of this is direct quote, simply sensible.

What's funny is I did reboot the client system and that didn't influence the behavior either. Idk. Don't want to overthink it.

Thanks for sharing. If I'm reading that right, the "issue" that caused me to ask the question (reservation not seeming to take effect) is likely an issue with the client system in question not doing a release.

I'm feeling like an idiot right now. I tried STFW and the forum and not finding an obvious answer. I swear I read something recently that this was a (recently new?) feature but I'm struggling.

Is it seriously not possible to delete a DHCP lease under DNSmasq? I am looking at Services > Dnsmasq DNS & DHCP > Leases and staring at a table of leases, but there's no UI indication on a way to delete/forget a lease.

I tried rebooting the OPNsense firewall as a hail mary but unsurprisingly that didn't do anything.

[not]

Not to bully others into how I want this thread to go, but this thread was not meant as a general "how to install OPNsense" question and is not meant to be too technical in nature.

For such comments, those should be in a separate thread. This thread is about the three things in the title and per my OP.

I think people are thoroughly confused as to the reasons why I posted this.

Don't read what I didn't write.

For some reason I'm no longer getting email alerts when this thread is updated...weird.

I feel more confident in OPNsense's sustainability compared to Netgate. Maybe one day if I'm incredibly bored I'll throw together a VM and try to build OPNsense for the "fun" of it and see how quickly I get stuck as an ignoramus.

I am still unclear on the donation angle and where donations go. I'd be willing to throw some money at the project on a regular basis, I'd just need to know where that donation is going.

Responding mainly to cookiemonster here - I may have not communicated my concern here very well, let me take another run at it.

Netgate is no longer providing offline installation media for pfSense CE. Their installer is essentially a stub installer now. Their response to people concerned about this change is "well if you love offline installers so much, build it yourself" but to my knowledge there is no official build guide for pfSense CE, and (I can't find it now...) I came across criticism that a lot of the build tooling for CE is not itself open sourced, and the build process is cumbersome, requiring a lot of intermediate systems/code.

In the case of pfSense CE, it may definitely be possible for a willing and skilled individual to build it from source, but it's not *accessible* and much harder for someone independent of the corporate sponsor to complete.

I don't want to build OPNsense from source - I am perfectly happy with the installation media. I am asking (now knowing the risk to CE) how OPNsense compares as this ties into the "sustainability" questions.

What are you even talking about?

Please be kind, I am a newcomer. I simply feel betrayed by Netgate and am now weary of placing undue trust in any project.

[are there any people outside of Deciso staff that regularly build OPNsense]

New forum user here, and new to the OPNsense community overall. Please be gentle - I tried doing quick searches for my questions, didn't find them, but figured this is probably something I am looking for the "human touch" on anyways.

Having learned over the last week or so that they won't be publishing offline installers for pfSense CE and comments from Netgate staff in a Reddit thread ... well, all remaining good will is out the window.

Before I fall under any illusions that this is a "true solution", I want to ask some questions:

• I see there's this guide on how to build OPNsense. It doesn't look super detailed, but serviceable. Outside of CS101 classes 10 years ago, I can count on two hands the amount of times I've run `make`. I'm not a programmer and would never claim to be. What I'm getting at is - are there any people outside of Deciso staff that regularly build OPNsense from source who can attest that the build process reliably works? If builds suddenly become impossible to complete in the future, that can at least serve as a canary.
  
• Where exactly do donation proceeds go? Deciso as should be expected is a commercial entity who happens to be the main sponsors of the project. If I choose to make regular donations, I want to ensure those funds are going directly to staffing/web hosting/administrative costs for supporting OPNsense development and not to general Deciso profits.
  
• A criticism of OPNsense is that it is downstream of Netgate's contributions and that Netgate is the primary contributor to both pfSense CE and FreeBSD generally. I have not necessarily fact checked such arguments, but they seem reasonable at face value. If Netgate were to retract all contributions to pfSense CE and FreeBSD, what would the impacts be to OPNsense development?