can't find where to delete a device entry associated with an interface

[RobLatour]

I'm having trouble assigning a new device to an old ip address (I don't think it is the dnsmasq lease expiry issue - rather something else).

What I'm trying to do is to get a new device to come in and be assigned the address 192.168.7.24 which had previousily been assigned.
I waited until it had expired in the lease table, and then plugged in the new device - however it would not get the address I had wanted to spite me having already it defined in the dnsmasq host table (by its MAC) to be assigned to 192.168.7.24

I can get it assinged to 192.168.7.25 - but with that I get odd behaviours.

For example, the device is plugged directly into the OPNSense box's opt2 interface.  There is only one device plugged into that interface - but regardless with that one device plugged in I can ping both 192.168.7.24 and 192.168.7.25. 

As I'm using this device in conjunction with OPNSense's Time Service; I've tried stopping that server and turning it on at various points in my experementation to get this to work - just incase the time service has a hold on the IP address some how??

Also, oddly, while 192.168.7.24 no longer shows up in the lease table or the host table, I backed up my configuration and looked inside the back up file to find this (I just have no idea where to delete it from):

```
    <opt2>
      <gateway>192.168.7.1</gateway>
      <ddnsdomainalgorithm>hmac-md5</ddnsdomainalgorithm>
      <numberoptions>
        <item/>
      </numberoptions>
      <range>
        <from>192.168.7.24</from>
        <to>192.168.7.24</to>
      </range>
      <winsserver/>
      <dnsserver>192.168.7.1</dnsserver>
      <ntpserver/>
      <staticmap>
        <mac>24:0a:c4:26:9e:43</mac>
        <ipaddr>192.168.7.24</ipaddr>
        <hostname>MasterClock</hostname>
        <descr>MasterClock</descr>
        <arp_table_static_entry>1</arp_table_static_entry>
        <winsserver/>
        <dnsserver/>
        <ntpserver/>
      </staticmap>
    </opt2>
```
edit: I thought maybe if I could delete / clear the above I could get it to work - but can't seem to find how to do that.

edit: I should note I am running OPNsense 26.7.2_2-amd64 ; FreeBSD 15.1-RELEASE-p2 ; OpenSSL 3.5.7

[Patrick M. Hausen]

Remove the dynamic range.

[RobLatour]

Thanks for this Patrick,

However, for clarification, by this I assume you mean to check the option on the interface entitled:
"This interface does not require an intermediate system to act as a gateway"

Which I did, followed by a save and apply, followed by another backup of my settings.
However, when I looked in them the same entry as shown in my original post was there.
```
    <opt2>
      <gateway>192.168.7.1</gateway>
      <ddnsdomainalgorithm>hmac-md5</ddnsdomainalgorithm>
      <numberoptions>
        <item/>
      </numberoptions>
      <range>
        <from>192.168.7.24</from>
        <to>192.168.7.24</to>
      </range>
      <winsserver/>
      <dnsserver>192.168.7.1</dnsserver>
      <ntpserver/>
      <staticmap>
        <mac>24:0a:c4:26:9e:43</mac>
        <ipaddr>192.168.7.24</ipaddr>
        <hostname>MasterClock</hostname>
        <descr>MasterClock</descr>
        <arp_table_static_entry>1</arp_table_static_entry>
        <winsserver/>
        <dnsserver/>
        <ntpserver/>
      </staticmap>
    </opt2>
```

Will these now be ignored? 

I'm asking as I would otherwise just test it, but I have to wait for mid morning tomorrow for the existing lease to expire.

Thanks again for your help.

[Patrick M. Hausen]

No, you have a DHCP range from .24 to .24. In that case you probably cannot use the same address as a static assignment. My guess - I'm running Kea, not DNSmasq.

[dseven]

The config snippet looks like it pertains to ISC DHCP, not dnsmasq. Which DHCP server are you actually using? It look like it has static ARP too, so that may be getting in your way. I think there may be some magic code that looks at those static mappings even if ISC DHCP is not enabled (not sure if I'm remembering this right).

[RobLatour]

I am using dnsmasq dns & dhcp; having migraged to it several months ago when the prior way of doing this was being obsoleted. 

[dseven]

OK, so I think you have some leftover ISC DHCP config, and that's what's tripping you up. If you have the plugin installed, you could delete the static mappings using the webUI. If you don't have the plugin, I *think* you could use `pluginctl -f dhcpd` to flush the old config, then perhaps reboot (to clear out the static ARP entries)... but I'd generally defer to franco on the proper way to clean up things like this...

[Monviech (Cedrik)]

You can clean up old config in the GUI via "System: Configuration: Defaults - Components tab"

[RobLatour]

What exactly should I reset via "System: Configuration: Defaults - Components tab"?
I don't see ISC DHCP listed.

[dseven]

It would be "Services: ISC DHCPv4 [legacy] [dhcpd]" - you can just type "isc" in the search box, and it should pop up if it's available.

[RobLatour]

Well I have a mix of good news and bad news:

Good news

I did a reset of via System: Configuration: Defaults - Components of Services: ISC DHCPv4 [legacy] [dhcpd] and rebooted OPNSense
Using System - Configuration - Backup I download my new configuration
I looked at it and the offending entry as well as many others were removed!

Bad news

I lost Internet access through my entire network and when I rebooted my device which I am trying to have 192.168.7.24 assigned to it would not establish an IPv4 connection.

Good news

Prior to the making the  System: Configuration reset I had created a snapshot

Bad news

I restored from that snapshot and rebooted; the internet was still down and my device was still not getting an IPv4 address.

Good news

I had made a snapshot 2 days ago, I restored from that and rebooted; the internet was back up again and my device got an ip adress albeit the one it had before all this started.

Bad news

Using System - Configuration - Backup I download my restored configuration
I looked at it and the offending entry was again there (as expected)
So I'm back to square one - however, learned something new as I had never actually done a snapshot recovery before.

Any other ides?

[dseven]

If I'm following that sequence right, it sounds like your broke something (probably your dnsmasq DHCP config) before resetting the ISC DHCP config (and maybe the clients were still clinging onto old leases, or something). Maybe you could try resetting the ISC DHCP config again, and hopefully dnsmasq is still functional from the 2-days-ago snapshot.....

[Monviech (Cedrik)]

I doubt dnsmasq was ever configured correctly and assume the leases are in ISC instead.

[RobLatour]

If I'm following that sequence right, it sounds like your broke something (probably your dnsmasq DHCP config) before resetting the ISC DHCP config (and maybe the clients were still clinging onto old leases, or something). Maybe you could try resetting the ISC DHCP config again, and hopefully dnsmasq is still functional from the 2-days-ago snapshot.....

Good news

after following that suggestiong and a reboot, the system came back up with the internet fully working, also the offending entry was now gone

Bad news

I still can not assign 192.168.7.24 to that device

Good news

Originally the range on the interface I am using was 192.168.7.24 - 192.168.7.25 as I only had one device I was using on it at a time.
I thought perhaps OPNSense was doing something / locking / who knows what with that first address and why I was not able to assign it.
In any case, I've now changed the range to 192.168.7.1 - 192.168.7.100 and after that my device got a new dynamic address of 192.168.7.72.
I've now added a static entry to flip it to 192.168.7.24 - but will have to wait for the lease to expire - after which time I'm hoping it will be all good once again.

Also, as an asided, I'm thinking the one potentially non-benign change I had made over the last two days was checking the option 'This interface does not require an intermediate system to act as a gateway' which may have explained some of the issues with restoring from the most recent snapshop - but in any case I don't care as the one from two days ago did the trick - underlining the importance of taking snapshots!

Thanks all very much for your help.