uid lease is duplicate / multiple DHCPOFFER [solution]

Wim Vandersmissen Wim.Vandersmissen at icts.kuleuven.be
Fri Apr 30 14:32:28 UTC 2010


Hi,

I found a solution for the problem, apparently "Most versions of Microsoft Windows improperly encode the secs field on the wire as little-endian." (http://wiki.wireshark.org/DHCP#head-838a814984848532459be023c4d9da55a411dff9)

This means that the check in load_balance_mine (in server/failover.c) isn't working correctly for such hosts.

I made the following small patch, if it sees a value above 255 it probably means we're dealing with little-endian, so we can use the secs value of the raw packet.

--Wim


diff -urp dhcp-4.1.1/server/failover.c dhcp-4.1.1-endianfix/server/failover.c
--- dhcp-4.1.1/server/failover.c        2009-07-23 21:02:10.000000000 +0200
+++ dhcp-4.1.1-endianfix/server/failover.c      2010-04-30 14:38:59.000000000 +0200
@@ -5751,9 +5751,18 @@ int load_balance_mine (struct packet *pa
        struct data_string ds;
        unsigned char hbaix;
        int hm;
+       short int ec; // endian check
 
-       if (state -> load_balance_max_secs < ntohs (packet -> raw -> secs)) {
-               return 1;
+       ec = ntohs (packet -> raw -> secs);
+       if (ec > 255) {
+               // little endian encoding (ms client probably)
+               if (state -> load_balance_max_secs < packet -> raw -> secs) {
+                       return 1;
+               }
+       } else {
+               if (state -> load_balance_max_secs < ec) {
+                       return 1;
+               }
        }



> -----Original Message-----
> From: Wim Vandersmissen [mailto:wim.vandersmissen at icts.kuleuven.be]
> Sent: donderdag 29 april 2010 15:23
> To: dhcp-users at lists.isc.org
> Subject: uid lease is duplicate / multiple DHCPOFFER
> 
> Hi,
> 
> We recently migrated our old dhcp environment to a 4.1.1 failover one.
> After the migration we got users complaining that they got new ip
> addresses and
> the logs are showing "uid lease x.x.x.x for client aa:bb:cc:dd:ee:ff is
> duplicate on x.x.x.x/y" on those users.
> 
> Sometimes the dhcpservers know that they should load balance to the
> peer and
> only send one DHCPOFFER and sometimes they respond with two DHCPOFFERS
> containing two different IP addresses.
> 
> I used wireshark to debug the DHCPDISCOVER
>     - the client 'secs' field (0) or sometimes (3) or (5) is below our
> 	'load-balance-max-secs'  (6)
>     - the clients 'client address field' is also 0.0.0.0
> 
> Some more information about the failover:
>     - we're using 'split 128' for the load-balancing
>     - we're not using any reservations.
>     - we're using 'one-lease-per-client'
>     - both partners are in normal state (00:00:00:02)
>     - MCLT = 1800
>     - for this example the max-lease-time = 900
> 
> In the example below you can see that at 09h35 it works correctly, load
> balanced
> to peer.. but at 21h40 both servers responds with different DHCPOFFERS
> and
> different ip's which cause the duplicate message and a possible
> different ip for
> the client (in this case it takes the same, but in other cases it takes
> the other
> one)
> 
> We're seeing this behaviour on around 10% of our users (unique mac
> addresses).
> 
> cat /var/log/all|grep "Apr 29"|grep DHCPDISCOVER|awk '{print
> $8}'|sort|uniq|wc
>   10912   10912  196416
> cat /var/log/all|grep "Apr 29"|grep duplicate|awk '{print
> $11}'|sort|uniq|wc
>    1160    1160   20880
> 
> Disabling the secondary dhcp server solves the duplicate messages and
> obviously
> also the two different DHCPOFFERS but also removes the failover, so
> it's not
> really an option.
> 
> Any clues/ideas what I can do/check next ?
> 
> Thanks,
> 
> Wim
> 
> 
> -----------------------
> 09:35:44 dhcp1-l dhcpd: DHCPDISCOVER from 00:00:00:aa:bb:cc via
> 10.0.14.254: load balance to peer dhcp-failover
> 09:35:44 dhcp2-l dhcpd: DHCPDISCOVER from 00:00:00:aa:bb:cc via
> 10.0.14.254
> 09:35:45 dhcp2-l dhcpd: DHCPOFFER on 10.0.14.164 to 00:00:00:aa:bb:cc
> (Jarri) via 10.0.14.254
> 09:35:45 dhcp1-l dhcpd: DHCPREQUEST for 10.0.14.164 (134.58.127.6) from
> 00:00:00:aa:bb:cc via 10.0.14.254: lease owned by peer
> 09:35:45 dhcp2-l dhcpd: DHCPREQUEST for 10.0.14.164 (134.58.127.6) from
> 00:00:00:aa:bb:cc (Jarri) via 10.0.14.254
> 09:35:45 dhcp2-l dhcpd: DHCPACK on 10.0.14.164 to 00:00:00:aa:bb:cc
> (Jarri) via 10.0.14.254
> 09:36:25 dhcp2-l dhcpd: DHCPACK to 10.0.14.164 (00:00:00:aa:bb:cc) via
> eth1
> 09:36:25 dhcp1-l dhcpd: DHCPACK to 10.0.14.164 (00:00:00:aa:bb:cc) via
> eth1
> 
> ---
> 21:40:06 dhcp1-l dhcpd: DHCPDISCOVER from 00:00:00:aa:bb:cc via
> 10.0.14.254
> 21:40:06 dhcp2-l dhcpd: DHCPDISCOVER from 00:00:00:aa:bb:cc via
> 10.0.14.254
> 21:40:07 dhcp2-l dhcpd: DHCPOFFER on 10.0.14.164 to 00:00:00:aa:bb:cc
> (Jarri) via 10.0.14.254
> 21:40:07 dhcp1-l dhcpd: DHCPOFFER on 10.0.14.179 to 00:00:00:aa:bb:cc
> (Jarri) via 10.0.14.254
> 21:40:07 dhcp1-l dhcpd: uid lease 10.0.14.179 for client
> 00:00:00:aa:bb:cc is duplicate on 10.0.14.0/24
> 21:40:07 dhcp1-l dhcpd: DHCPREQUEST for 10.0.14.164 (134.58.127.6) from
> 00:00:00:aa:bb:cc via 10.0.14.254: lease owned by peer
> 21:40:07 dhcp2-l dhcpd: DHCPREQUEST for 10.0.14.164 (134.58.127.6) from
> 00:00:00:aa:bb:cc (Jarri) via 10.0.14.254
> 21:40:07 dhcp2-l dhcpd: DHCPACK on 10.0.14.164 to 00:00:00:aa:bb:cc
> (Jarri) via 10.0.14.254
> 21:40:12 dhcp1-l dhcpd: DHCPACK to 10.0.14.164 (00:00:00:aa:bb:cc) via
> eth1
> 21:40:12 dhcp2-l dhcpd: DHCPACK to 10.0.14.164 (00:00:00:aa:bb:cc




More information about the dhcp-users mailing list