Uid lease for client is duplicated
-
This is still happening in 2.2.3
https://forum.pfsense.org/index.php?PHPSESSID=g7fvh3mm2sdajhtac714n0gtn0&topic=7078.msg40046#msg40046
I have tried the suggestion here.
https://forum.pfsense.org/index.php?topic=5231.msg31528#msg31528Editing the neccesary files only works with a reboot.
-
Are you actually seeing a problem, or just the message in the logs?
That can happen if you assign a client a static mapping and the leases file still has their old lease, but it should be harmless.
We used to have code that would tidy up things like that in the leases file but the code was removed since it was causing problems with DHCP failover in HA clusters.
-
Are you actually seeing a problem, or just the message in the logs?
That can happen if you assign a client a static mapping and the leases file still has their old lease, but it should be harmless.
We used to have code that would tidy up things like that in the leases file but the code was removed since it was causing problems with DHCP failover in HA clusters.
I just ran into this issue, currently it is harmless, but can fluctuate a lot before getting connected at the end of story. In my case it's taken about 2 minutes to get connected, I am not sure what's logic caused that. I really don't understand why would DHCP server to override correct static IP configured in GUI and ALREADY received by PC with some old crap IP stored in /var/dhcpd/var/db/dhcpd.leases~ and /var/dhcpd/var/db/dhcpd.leases
Jan 7 08:26:12 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:26:12 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:26:12 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:26:04 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:26:04 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:26:04 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:26:01 dhcpd DHCPACK on 10.0.87.101 to e8:ab:fa:0e:83:b6 via igb1 Jan 7 08:26:01 dhcpd DHCPREQUEST for 10.0.87.101 from e8:ab:fa:0e:83:b6 via igb1 Jan 7 08:25:57 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:57 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:57 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:55 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:55 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:55 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:53 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:53 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:53 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:51 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:51 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:51 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:49 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:49 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:49 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:47 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:47 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:47 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:46 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:46 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:46 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:44 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:44 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:44 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:42 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:42 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:42 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:42 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:42 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:42 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:36 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:36 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:36 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:33 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:33 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:33 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:32 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:32 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:32 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:31 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:31 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:31 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:27 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:27 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:27 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:26 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:26 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:26 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:24 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:24 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:24 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:22 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:22 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:22 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:18 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:18 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:18 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:17 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:17 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:17 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:16 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:16 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:16 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:15 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:15 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:15 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:11 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:11 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:11 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:08 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:08 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:08 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:05 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:05 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:05 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:05 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:05 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:05 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:25:01 dhcpd DHCPACK on 10.0.87.101 to e8:ab:fa:0e:83:b6 via igb1 Jan 7 08:25:01 dhcpd DHCPREQUEST for 10.0.87.101 from e8:ab:fa:0e:83:b6 via igb1 Jan 7 08:25:01 dhcpd DHCPACK on 10.0.87.101 to e8:ab:fa:0e:83:b6 via igb1 Jan 7 08:25:01 dhcpd DHCPREQUEST for 10.0.87.101 from e8:ab:fa:0e:83:b6 via igb1 Jan 7 08:25:01 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:25:01 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:25:01 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:24:59 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:24:59 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:24:59 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:24:57 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:24:57 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:24:57 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:24:40 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:24:40 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:24:40 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:24:37 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:24:37 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:24:37 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:24:34 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:24:34 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:24:34 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:24:31 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:24:31 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:24:31 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 Jan 7 08:24:07 dhcpd DHCPACK on 10.0.87.3 to 74:da:38:de:d3:1e via igb1 Jan 7 08:24:07 dhcpd DHCPREQUEST for 10.0.87.3 from 74:da:38:de:d3:1e via igb1 Jan 7 08:24:07 dhcpd uid lease 10.0.87.11 for client 74:da:38:de:d3:1e is duplicate on 10.0.87.0/24 -
@w0w said in Uid lease for client is duplicated:
o
HiI have cleared old IP in:
/var/dhcpd/var/db/dhcpd.leases~ and /var/dhcpd/var/db/dhcpd.leasesbut it did not fix this issue.
Can you provide fix or workaround on this?
thanks -
ok, I can see that after I have cleard old IP in those files, I can not see anymore such:
Apr 29 16:41:58 dhcpd DHCPREQUEST for 192.168.20.9 from 40:16:7e:a1:61:48 via lagg0.4091
Apr 29 16:41:58 dhcpd uid lease 192.168.20.11 for client 40:16:7e:a1:61:48 is duplicate on 192.168.20.0/22but still server interface is going down.
Can you provice fix to this?
-
@jacek111p
I'm running pfsense 21.05.2 but got the same issue.
Did you find a workaround?
Thanks, BR -
In the last couple of months I've notice an issue where once every few hours the household seems to lose internet connectivity. When that happens, the pfsense router goes unresponsive (doesn't respond to ping, web UI non-responsive). At first I thought it was my cable-modem dropping the WAN but after monitoring both I've noticed the WAN is fine when the pfsense goes unresponsive.
I've monitored when that happens, and the only thing in the pfsense logs that coincides with the outages is this "Uid lease for client is duplicated" message in the DHCP log. Seems odd that a duplicate IP would cause the entire router to freeze but that's the only thing that seems to coincide in the logs to the outages. Could this cause such a problem? I'm on the latest firmware 22.01, happened in the previous firmware as well.
-
Using PFSense and a Netgear WIFI Access Point, I've been having problems with my Samsung Galaxy Tab A dropping its WIFI connection in poorly covered areas of the house, but when I return to a strong signal area, it can't reconnect. It shows a strong signal, but indicates failure to negotiate with the access point, despite a strong signal, and both manual and automated attempts to reconnect. After 2 to 5 minutes, it might finally connect, but in the meantime, I have no connection.
Long story short is that these duplicated lease events occurring in PFSense were the cause of the problem. I think this issue needs to finally be addressed by Netgate. More info below . . .
At first I suspected that the Netgear access points had a problem, but it turns out they were disconnecting because the DHCP lease never completed and an IP address was never assigned successfully (found a hint to that in an Internet search). So then I went to PFSense, and started looking at DHCP logs. That's when I first saw the "uid lease ... is duplicate" issue. It seems that every time the Galaxy TAB A would attempt to reconnect, there would be three line items:
Sep 18 09:06:04 pfsense dhcpd[22095]: uid lease 192.168.30.244 for client 04:b4:29:xx:yy:zz is duplicate on 192.168.30.0/24 Sep 18 09:06:04 pfsense dhcpd[22095]: DHCPREQUEST for 192.168.30.187 from 04:b4:29:xx:yy:zz via vmx1.30 Sep 18 09:06:04 pfsense dhcpd[22095]: DHCPACK on 192.168.30.187 to 04:b4:29:xx:yy:zz via vmx1.30Reading them, you would think that yes, there was a duplicate lease issue, but then the following two lines for DHCPREQUEST and DHCPACK would seem to indicate that everything worked out OK, and that the proper lease was acknowledged. However, somehow the Galaxy TAB A did not complete the lease handshake with PFSense. I don't know if PFSense logged it but didn't send it, or if the lease duplicate created a bogus error message that screwed things up, or if there was some signaling race condition, or what. (I have not run Wireshark to look at actual traffic). What I do know is that the WIFI setup fails and waits a few minutes and tries again. Eventually it works. But it could take quite a while.
This seems like some kind of race condition. If you win the race, you get the correct lease messaging for request and ack without any errors messing it up. But most of the time, you lose the race and it appears that the "uid lease...is duplicate" issue is what causes the failure.
In PFSense, I had originally set up a pool in the range of 192.168.30.240-192.168.30.254. And the Galaxy Tab A got its 192.168.30.244 address originally from that pool. But then I added a static assignment for this tablet at address 192.168.30.187. And apparently, that's when the problems started.
So as I figure this out today, in the PFSENSE web GUI, I clicked on the "Show all configured leases" button at the bottom of the DHCP leases page, and found tons of ancient pool-assigned addresses still showing up, but marked as offline and expired. The ancient lease (months old) for my Tab A was still in there at 192.168.30.244.
So I manually deleted that ancient lease, and retried disconnecting/reconnecting my TAB A from Wifi by walking in and out of the good coverage area. Now, everything works fine and the TAB A reconnects automatically every time. Snippet below shows 4 attempts in few minutes. These were all good.
Sep 18 11:03:51 pfsense dhcpd[22095]: DHCPREQUEST for 192.168.30.187 from 04:b4:29:xx:yy:zz via vmx1.30 Sep 18 11:03:51 pfsense dhcpd[22095]: DHCPACK on 192.168.30.187 to 04:b4:29:xx:yy:zz via vmx1.30 Sep 18 11:15:40 pfsense dhcpd[30760]: DHCPREQUEST for 192.168.30.187 from 04:b4:29:xx:yy:zz via vmx1.30 Sep 18 11:15:40 pfsense dhcpd[30760]: DHCPACK on 192.168.30.187 to 04:b4:29:xx:yy:zz via vmx1.30 Sep 18 11:17:08 pfsense dhcpd[30760]: DHCPREQUEST for 192.168.30.187 from 04:b4:29:xx:yy:zz via vmx1.30 Sep 18 11:17:08 pfsense dhcpd[30760]: DHCPACK on 192.168.30.187 to 04:b4:29:xx:yy:zz via vmx1.30 Sep 18 11:19:25 pfsense dhcpd[30760]: DHCPREQUEST for 192.168.30.187 from 04:b4:29:xx:yy:zz via vmx1.30 Sep 18 11:19:25 pfsense dhcpd[30760]: DHCPACK on 192.168.30.187 to 04:b4:29:xx:yy:zz via vmx1.30So despite some people saying this should not be an issue, or is harmless, I must disagree. This is an issue - at least for some use cases or combinations of equipment, including mine where I have a Netgear access point and a Galaxy Tab A. And apparently for others as well who have indicated that their systems remain offline for minutes at a time when this occurs. It seems that the PFsense DHCP code has a bug such that if there is a 'duplicate' lease assignment, the code logs things OK, but doesn't send or respond to DHCP messaging correctly. Or maybe it provides duplicate responses which confuse the endpoint asking for an address. Or maybe when this occurs, that changes the timing of the handshaking and that breaks things. I'll leave it to others to figure that out.
- Best solution is to analyze and fix the likely bug. Figure out why DHCP handshaking doesn't work as it should if there are duplicate leases in the database. Static leases should ALWAYS override pool leases. When a static lease is created, the pool should be cleared of any previous lease associations to that MAC address.
- A bandaid fix would be to automatically delete expired leases after X amount of time so that they don't trigger this 'bug' after the old lease is automatically deleted. But that still leaves a window of time where the bug could occur.
- And if Netgear doesn't want to create automatic deletion or truly fix the bug, a third option would be to provide more "Clear * DHCP Leases" buttons at the bottom of the leases page. Right now, there is "Clear All DHCP Leases". But that is too extreme most of the time. Netgear could add "Clear Inactive" and "Clear Expired" buttons as well to make it easier for us to clear out the ancient unused leases that are still in the database.
Of course, we can hand edit the leases file as well, but we shouldn't have to.
Thanks all
-
@brookbphx Hey this is the same exact nonsense that I have been dealing with for years now. When I read your post it sent shivers down my spine because I'm like 'OMG I'm not the only one!' HAHA. I'm running a Netgate FW appliance with Netgear WAX630E APs. Typically, I have to toggle WiFi on/off (iPhones/laptops/etc) + attempt to reconnect to WiFi over and over before I finally get an IP Address. I would say that you can't imagine how frustrating this is, but sadly you probably do! Have you figured out a sustainable solution? Is it better to just use some other system like Windows Domain Controller for DHCP instead?
-
@jimp said in Uid lease for client is duplicated:
That can happen if you assign a client a static mapping and the leases file still has their old lease, but it should be harmless.
We running into the same issue (2.7.2), the client has now for months an static mapping.
Since we have login issues on this workstation we looked into the logs and hit this ip change during boot up (not sure this is our login problem).Is there a (safe) way to clean up this old leases?
pfSense Gold subscription
-
@slu as workaround you can manually edit:
/var/dhcpd/var/db/dhcpd.leases~ /var/dhcpd/var/db/dhcpd.leases -
@slu said in Uid lease for client is duplicated:
Is there a (safe) way to clean up this old leases?
If the lease is old, before you went to static - you can just hit the trashcan to delete the old lease
I have never ran into a problem with an old lease, normally I let a client just get a lease - then I change it to a reservation and renew the lease on the client and it gets the new reservation.
But if its problematic - then clear the old lease.. If the device is still using the old one and its actively up it won't present the trashcan.. If that is the case you could either maybe clear pfsense arp cache so it doesn't think the devices is online and delete the old lease in the gui.. Or worse case manually edit the lease file.
If you want an option to delete all expired leases en masse you could prob put in a feature request.
edit: btw the leases page doesn't show you expired leases unless you click the show all configured leases at the bottom of the page
