pre-creating reserved leases

[Foggi, Nicola]

so i was able to reliably reproduce this tonight, and here's what i found with DEBUG_FIND_LEASE turned on:

the "primary" of the failover pair found the correct lease and offered it:

Mar  4 00:01:04 dhcp-sac-1s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar  4 00:01:04 dhcp-sac-1s dhcpd: Found lease for hardware address: 10.0.82.9.
Mar  4 00:01:04 dhcp-sac-1s dhcpd: Returning lease: 10.0.82.9.
Mar  4 00:01:04 dhcp-sac-1s dhcpd: DHCPDISCOVER from 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
Mar  4 00:01:05 dhcp-sac-1s dhcpd: DHCPOFFER on 10.0.82.9 to 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
Mar  4 00:01:09 dhcp-sac-1s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar  4 00:01:09 dhcp-sac-1s dhcpd: Found lease for hardware address: 10.0.82.9.
Mar  4 00:01:09 dhcp-sac-1s dhcpd: DHCPREQUEST for 10.0.82.6 (10.0.5.25) from 00:0e:7f:e9:6c:c3 via 10.0.82.1: lease owned by peer

however, notice that last line where the client requests 82.6, it got that address from the "secondary" server as seen below:

Mar  4 00:01:04 dhcp-lew-13s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar  4 00:01:04 dhcp-lew-13s dhcpd: not mine to allocate: 10.0.82.9
Mar  4 00:01:04 dhcp-lew-13s dhcpd: DHCPDISCOVER from 00:0e:7f:e9:6c:c3 via 10.0.82.1
Mar  4 00:01:05 dhcp-lew-13s dhcpd: DHCPOFFER on 10.0.82.6 to 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
Mar  4 00:01:09 dhcp-lew-13s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar  4 00:01:09 dhcp-lew-13s dhcpd: not mine to allocate: 10.0.82.9
Mar  4 00:01:09 dhcp-lew-13s dhcpd: DHCPREQUEST for 10.0.82.6 (10.0.5.25) from 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
Mar  4 00:01:09 dhcp-lew-13s dhcpd: DHCPACK on 10.0.82.6 to 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1

so looking at the find_lease function brings me to lines 3196 - 3213:

        while (hw_lease) {
#if defined (DEBUG_FIND_LEASE)
                log_info ("trying next lease matching hw addr: %s",
                          piaddr (hw_lease -> ip_addr));
#endif
#if defined (FAILOVER_PROTOCOL)
                /* When failover is active, it's possible that there could
                   be two "free" leases for the same uid, but only one of
                   them that's available for this failover peer to allocate. */
                if (hw_lease -> binding_state != FTS_ACTIVE &&
                    !lease_mine_to_reallocate (hw_lease)) {
#if defined (DEBUG_FIND_LEASE)
                        log_info ("not mine to allocate: %s",
                                  piaddr (hw_lease -> ip_addr));
#endif
                        goto n_hw;
                }
#endif


(i'm assuming the problem also exists on lines 3128 - 3146 for a uid_lease but didn't test that) but not sure what the correct if statement should be :) 

I'm getting more in depth with the source code than i would of ever imagined... but hey, if we can get this bug nailed, then i think i can move forward with a full deployment!!!

Nicola
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3721 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090304/5a16ab63/attachment.bin>