Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Uid lease for client is duplicated

    Scheduled Pinned Locked Moved DHCP and DNS
    12 Posts 10 Posters 10.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      firewalluser
      last edited by

      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#msg31528

      Editing the neccesary files only works with a reboot.

      Capitalism, currently The World's best Entertainment Control System and YOU cant buy it! But you can buy this, or some of this or some of these

      Asch Conformity, mainly the blind leading the blind.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        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.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        S 1 Reply Last reply Reply Quote 0
        • w0wW
          w0w
          last edited by

          @jimp:

          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 
          
          1 Reply Last reply Reply Quote 0
          • J
            jacek111p
            last edited by

            @w0w said in Uid lease for client is duplicated:

            o
            Hi

            I have cleared old IP in:
            /var/dhcpd/var/db/dhcpd.leases~ and /var/dhcpd/var/db/dhcpd.leases

            but it did not fix this issue.

            Can you provide fix or workaround on this?
            thanks

            1 Reply Last reply Reply Quote 0
            • J
              jacek111p
              last edited by

              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/22

              but still server interface is going down.

              Can you provice fix to this?

              S 1 Reply Last reply Reply Quote 0
              • S
                Summer @jacek111p
                last edited by

                @jacek111p
                I'm running pfsense 21.05.2 but got the same issue.
                Did you find a workaround?
                Thanks, BR

                1 Reply Last reply Reply Quote 1
                • S
                  schung
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • B
                    brookbphx
                    last edited by

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

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

                    So 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

                    C 1 Reply Last reply Reply Quote 1
                    • C
                      capitolcyber @brookbphx
                      last edited by

                      @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?

                      1 Reply Last reply Reply Quote 0
                      • S
                        slu @jimp
                        last edited by

                        @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

                        S johnpozJ 2 Replies Last reply Reply Quote 0
                        • S
                          Summer @slu
                          last edited by

                          @slu as workaround you can manually edit:

                          /var/dhcpd/var/db/dhcpd.leases~
                          /var/dhcpd/var/db/dhcpd.leases
                          
                          1 Reply Last reply Reply Quote 0
                          • johnpozJ
                            johnpoz LAYER 8 Global Moderator @slu
                            last edited by johnpoz

                            @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

                            oldlease.jpg

                            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

                            An intelligent man is sometimes forced to be drunk to spend time with his fools
                            If you get confused: Listen to the Music Play
                            Please don't Chat/PM me for help, unless mod related
                            SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                            1 Reply Last reply Reply Quote 1
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.