dhcpd lease double allocation problem

I just set up ISC dhcpd 3.1.0a1 on an AlphaServer running RH 7.0
with kernel 2.2.22.

dhcpd is working fine, with no errors. Three computers connected
to the network all acquire leases and are able to correctly
function as expected.

However...The first two computers are given the SAME IP ADDRESS!
Not only that, their hardware addresses (obviously different)
are listed as being the same in the dhcpd.leases file.
A THIRD computer connected is given a DIFFERENT IP address,
as it should be. (Third computer not shown here).

I released the IP addresses of the three attached WinXP machines,
shut them down, killed dhcpd on the Alpaserver, made a new,
empty lease file, fired up dhcpd, then turned on all the computers.
Same result.

What am I missing here? Why is the second "discover" appearing
to be issued by BOX-A, while the "ack" is being sent to BOX-B?

Here are the contents of the conf file, the lease file, plus my logs
from the last connection attempt:

--------

ddns-update-style none;
option domain-name "example.com";
option domain-name-servers 192.168.1.132;
default-lease-time 86400;
max-lease-time 86400;
authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
option routers 192.168.1.132;
}

------

lease 192.168.1.10 {
starts 2 2006/10/10 11:24:00;
ends 3 2006/10/11 11:24:00;
cltt 2 2006/10/10 11:24:00;
binding state active;
next binding state free;
hardware ethernet 00:00:00:00:00:10;
uid "\001\000\000\000\000\000\020";
client-hostname "BOX-A";
}
lease 192.168.1.10 {
starts 2 2006/10/10 11:25:32;
ends 3 2006/10/11 11:25:32;
cltt 2 2006/10/10 11:25:32;
binding state active;
next binding state free;
hardware ethernet 00:00:00:00:00:10;
uid "\001\000\000\000\000\000\020";
client-hostname "BOX-B";
}

-------------

Oct 10 07:23:08 alpha dhcpd: Internet Systems Consortium DHCP Server V3.1.0a1
Oct 10 07:23:08 alpha dhcpd: Copyright 2004-2006 Internet Systems Consortium.
Oct 10 07:23:08 alpha dhcpd: All rights reserved.
Oct 10 07:23:08 alpha dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Oct 10 07:23:08 alpha dhcpd: Wrote 0 leases to leases file.
Oct 10 07:23:08 alpha dhcpd: Listening on LPF/eth0/00:10:4b:6c:04:2b/192.168.1/24
Oct 10 07:23:08 alpha dhcpd: Sending on LPF/eth0/00:10:4b:6c:04:2b/192.168.1/24
Oct 10 07:23:08 alpha dhcpd: Sending on Socket/fallback/fallback-net
Oct 10 07:23:59 alpha dhcpd: DHCPDISCOVER from 00:00:00:00:00:10 via eth0
Oct 10 07:24:00 alpha dhcpd: DHCPOFFER on 192.168.1.10 to 00:00:00:00:00:10 (BOX-A) via eth0
Oct 10 07:24:00 alpha dhcpd: DHCPREQUEST for 192.168.1.10 (192.168.1.132) from 00:00:00:00:00:10 (BOX-A) via eth0
Oct 10 07:24:00 alpha dhcpd: DHCPACK on 192.168.1.10 to 00:00:00:00:00:10 (BOX-A) via eth0
Oct 10 07:25:31 alpha dhcpd: DHCPDISCOVER from 00:00:00:00:00:10 (BOX-A) via eth0
Oct 10 07:25:32 alpha dhcpd: DHCPOFFER on 192.168.1.10 to 00:00:00:00:00:10 (BOX-B) via eth0
Oct 10 07:25:32 alpha dhcpd: DHCPREQUEST for 192.168.1.10 (192.168.1.132) from 00:00:00:00:00:10 (BOX-B) via eth0
Oct 10 07:25:32 alpha dhcpd: DHCPACK on 192.168.1.10 to 00:00:00:00:00:10 (BOX-B) via eth0
Oct 10 07:26:02 alpha dhcpd: DHCPINFORM from 192.168.1.10 via eth0
Oct 10 07:26:02 alpha dhcpd: DHCPACK to 192.168.1.10 (00:00:00:00:00:10) via eth0
Oct 10 07:26:05 alpha dhcpd: DHCPINFORM from 192.168.1.10 via eth0
Oct 10 07:26:05 alpha dhcpd: DHCPACK to 192.168.1.10 (00:00:00:00:00:10) via eth0
Oct 10 07:28:05 alpha dhcpd: DHCPINFORM from 192.168.1.10 via eth0
Oct 10 07:28:05 alpha dhcpd: DHCPACK to 192.168.1.10 (00:00:00:00:00:10) via eth0
Oct 10 07:28:08 alpha dhcpd: DHCPINFORM from 192.168.1.10 via eth0
Oct 10 07:28:08 alpha dhcpd: DHCPACK to 192.168.1.10 (00:00:00:00:00:10) via eth0


--
TeGGeR®

The Unofficial Honda/Acura FAQ
www.tegger.com/hondafaq/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


TeGGeR® wrote:
> I just set up ISC dhcpd 3.1.0a1 on an AlphaServer running RH 7.0
> with kernel 2.2.22.
>
> dhcpd is working fine, with no errors. Three computers connected
> to the network all acquire leases and are able to correctly
> function as expected.
>
> However...The first two computers are given the SAME IP ADDRESS!
> Not only that, their hardware addresses (obviously different)
> are listed as being the same in the dhcpd.leases file.
> A THIRD computer connected is given a DIFFERENT IP address,
> as it should be. (Third computer not shown here).
>
> I released the IP addresses of the three attached WinXP machines,
> shut them down, killed dhcpd on the Alpaserver, made a new,
> empty lease file, fired up dhcpd, then turned on all the computers.
> Same result.
>
> What am I missing here? Why is the second "discover" appearing
> to be issued by BOX-A, while the "ack" is being sent to BOX-B?

- From the logs below, either both BOX-A and BOX-B have been
misconfigured to use the same Ethernet MAC address, or you munged the
logs improperly before posting.

Assuming that the logs are accurate, then you have two misconfigured XP
machines that need to be fixed. MAC addresses /must/ be unique on the
LAN; MAC addresses are the way Ethernet distinguishes one network
device from another, and if you have two ethernet devices with the same
MAC, traffic gets screwed up.

See my comments below...

> Here are the contents of the conf file, the lease file, plus my logs
> from the last connection attempt:
>
> --------
>
> ddns-update-style none;
> option domain-name "example.com";
> option domain-name-servers 192.168.1.132;
> default-lease-time 86400;
> max-lease-time 86400;
> authoritative;
>
> subnet 192.168.1.0 netmask 255.255.255.0 {
> range 192.168.1.10 192.168.1.100;
> option routers 192.168.1.132;
> }
>
> ------
>
> lease 192.168.1.10 {
> starts 2 2006/10/10 11:24:00;
> ends 3 2006/10/11 11:24:00;
> cltt 2 2006/10/10 11:24:00;
> binding state active;
> next binding state free;
> hardware ethernet 00:00:00:00:00:10;
> uid "\001\000\000\000\000\000\020";
> client-hostname "BOX-A";
> }

OK, so the first lease request came from a device with MAC address
00:00:00:00:00:10 and was given the IP address of 192.168.1.10

> lease 192.168.1.10 {
> starts 2 2006/10/10 11:25:32;
> ends 3 2006/10/11 11:25:32;
> cltt 2 2006/10/10 11:25:32;
> binding state active;
> next binding state free;
> hardware ethernet 00:00:00:00:00:10;
> uid "\001\000\000\000\000\000\020";
> client-hostname "BOX-B";
> }

The second lease request /also/ came from a device with MAC address
00:00:00:00:00:10, and was given the same address as that MAC address
was given earlier.

That the two requests added some different supplemental information
("BOX-A" vs "BOX-B") is of no consequence. It is not "BOX-A" that is
asking for the IP address, it is MAC 00:00:00:00:00:10


> -------------
>
> Oct 10 07:23:08 alpha dhcpd: Internet Systems Consortium DHCP Server V3.1..0a1
> Oct 10 07:23:08 alpha dhcpd: Copyright 2004-2006 Internet Systems Consortium.
> Oct 10 07:23:08 alpha dhcpd: All rights reserved.
> Oct 10 07:23:08 alpha dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
> Oct 10 07:23:08 alpha dhcpd: Wrote 0 leases to leases file.
> Oct 10 07:23:08 alpha dhcpd: Listening on LPF/eth0/00:10:4b:6c:04:2b/192.168.1/24
> Oct 10 07:23:08 alpha dhcpd: Sending on LPF/eth0/00:10:4b:6c:04:2b/192.168.1/24
> Oct 10 07:23:08 alpha dhcpd: Sending on Socket/fallback/fallback-net
> Oct 10 07:23:59 alpha dhcpd: DHCPDISCOVER from 00:00:00:00:00:10 via eth0

MAC 00:00:00:00:00:10 asks for someone to offer it an IP address

> Oct 10 07:24:00 alpha dhcpd: DHCPOFFER on 192.168.1.10 to 00:00:00:00:00:10 (BOX-A) via eth0

Your DHCP server offers 00:00:00:00:00:10 the IP address 192.168.1.10

> Oct 10 07:24:00 alpha dhcpd: DHCPREQUEST for 192.168.1.10 (192.168.1.132)from 00:00:00:00:00:10 (BOX-A) via eth0

MAC 00:00:00:00:00:10 accepts the offer for IP address192.168.1.10

> Oct 10 07:24:00 alpha dhcpd: DHCPACK on 192.168.1.10 to 00:00:00:00:00:10(BOX-A) via eth0

Your DHCP server confirms that MAC address 00:00:00:00:00:10 now has
the lease on IP address 192.168.1.10

> Oct 10 07:25:31 alpha dhcpd: DHCPDISCOVER from 00:00:00:00:00:10 (BOX-A) via eth0

Only Ghu knows why XP repeats it's discover request. I'd bet that this
is a transcription error because, up to now, all requests have been
identified with the BOX-A supplemental information, and none have been
identified with the BOX-B supplemental information. This was probably
the BOX-B DHCP discover.

In any case, MAC 00:00:00:00:00:10 asks for someone to offer it an IP
address

> Oct 10 07:25:32 alpha dhcpd: DHCPOFFER on 192.168.1.10 to 00:00:00:00:00:10 (BOX-B) via eth0

and your DHCP server, noticing that the same MAC asked earlier, assumes
that the ACK to MAC 00:00:00:00:00:10 got lost. So, it offers the same
IP address again.

> Oct 10 07:25:32 alpha dhcpd: DHCPREQUEST for 192.168.1.10 (192.168.1.132)from 00:00:00:00:00:10 (BOX-B) via eth0

MAC 00:00:00:00:00:10 accepts the offer for IP address192.168.1.10

> Oct 10 07:25:32 alpha dhcpd: DHCPACK on 192.168.1.10 to 00:00:00:00:00:10(BOX-B) via eth0

Your DHCP server confirms that MAC address 00:00:00:00:00:10 now has
the lease on IP address 192.168.1.10

The rest is housekeeping, confirming the reverse mapping (IP to MAC).
[snip]

So, both systems asked using the same MAC address. Or to look at it a
different way, one unique MAC address asked twice for a single IP
address. And that's what it got.


Next step: go back to each of the problematic XP systems, and check
what the MAC addresses are set to. Change one of them, so that both
addresses are unique. Then invalidate the leases, and start again.

HTH
- --
Lew Pitcher

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

iD8DBQFFK6IJagVFX4UWr64RAn6CAJ4gv4MSrDX9JxqfjttcG5 O2HVJF7QCg7INC
v8NiUGeYVys1FD6W5g430Hw=
=NYZd
-----END PGP SIGNATURE-----

TeGGeR® wrote:

> hardware ethernet 00:00:00:00:00:10;
> uid "\001\000\000\000\000\000\020";
> client-hostname "BOX-A";
> .......................................
> hardware ethernet 00:00:00:00:00:10;
> uid "\001\000\000\000\000\000\020";
> client-hostname "BOX-B";
> ......................................
> DHCPDISCOVER from 00:00:00:00:00:10 via eth0
> ......................................

These MAC address do not appear valid as they are coming from some
pseudo device like tun/tap and as both boxes have the same pseudo MAC.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
Registered Linux user #337974 < http://giovanni.homelinux.net/ >

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Giovanni wrote:
> TeGGeR® wrote:
>
> > hardware ethernet 00:00:00:00:00:10;
> > uid "\001\000\000\000\000\000\020";
> > client-hostname "BOX-A";
> > .......................................
> > hardware ethernet 00:00:00:00:00:10;
> > uid "\001\000\000\000\000\000\020";
> > client-hostname "BOX-B";
> > ......................................
> > DHCPDISCOVER from 00:00:00:00:00:10 via eth0
> > ......................................
>
> These MAC address do not appear valid as they are coming from some
> pseudo device like tun/tap and as both boxes have the same pseudo MAC.

I agree, sort of.

However, given that you can "override" the builtin MAC addresses with
user-selected MAC addresses, and that those MAC addresses can be of any
value (but /should/ be within the range of "soft" MAC addresses), the
strange MAC address value alone isn't enough to conclude that a
pseudo-device is in use here.

As for tun/tap, the interface wouldn't be eth0 if these requests came
from a tun or tap device. Instead, the interface would be tun0 or tap0.


So, we're still left with suspicious MAC addresses coming from two
Windows XP boxes.

- --
Lew Pitcher

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

iD8DBQFFK6maagVFX4UWr64RAhz3AKDmlJuOrG6Y829CdHmwdp kuSfKWsgCg0qYF
oNbLkuXR2958pMEUDCsWcJQ=
=Rhfk
-----END PGP SIGNATURE-----

"Lew Pitcher" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) oups.com:


>
> So, both systems asked using the same MAC address. Or to look at it a
> different way, one unique MAC address asked twice for a single IP
> address. And that's what it got.
>
>
> Next step: go back to each of the problematic XP systems, and check
> what the MAC addresses are set to. Change one of them, so that both
> addresses are unique. Then invalidate the leases, and start again.



I knew I was missing something.

In the heat of trying to solve this, I did not notice that both machines
had not only SAME model of NIC (onboard), but the SAME MAC address. I
changed the one as suggested and things are fine now. Thanks for the help.

A final question: If both machines were quite happy being together on the
network with the same MAC and the same IP address, am I correct in guessing
the client-hostname was enough to allow packets to find their correct
destination?

--
TeGGeR®

The Unofficial Honda/Acura FAQ
www.tegger.com/hondafaq/

"Lew Pitcher" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) ups.com:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Giovanni wrote:
>> TeGGeR® wrote:
>>
>> > hardware ethernet 00:00:00:00:00:10;
>> > uid "\001\000\000\000\000\000\020";
>> > client-hostname "BOX-A";
>> > .......................................
>> > hardware ethernet 00:00:00:00:00:10;
>> > uid "\001\000\000\000\000\000\020";
>> > client-hostname "BOX-B";
>> > ......................................
>> > DHCPDISCOVER from 00:00:00:00:00:10 via eth0
>> > ......................................
>>
>> These MAC address do not appear valid as they are coming from some
>> pseudo device like tun/tap and as both boxes have the same pseudo
>> MAC.
>
> I agree, sort of.
>
> However, given that you can "override" the builtin MAC addresses with
> user-selected MAC addresses, and that those MAC addresses can be of
> any value (but /should/ be within the range of "soft" MAC addresses),
> the strange MAC address value alone isn't enough to conclude that a
> pseudo-device is in use here.
>
> As for tun/tap, the interface wouldn't be eth0 if these requests came
> from a tun or tap device. Instead, the interface would be tun0 or
> tap0.
>
>
> So, we're still left with suspicious MAC addresses coming from two
> Windows XP boxes.



I've never seen MAC addresses that were so full of zeros as these two.

I don't know enough to be able to guess why the addresses were what they
were, but with one changed, all is well, so I'm leaving it alone now.

Thanks for your help.


--
TeGGeR®

The Unofficial Honda/Acura FAQ
www.tegger.com/hondafaq/

TeGGeR® wrote:
>
>> So, we're still left with suspicious MAC addresses coming from two
>> Windows XP boxes.
>
>
>
> I've never seen MAC addresses that were so full of zeros as these two.
>
> I don't know enough to be able to guess why the addresses were what they
> were, but with one changed, all is well, so I'm leaving it alone now.
>
> Thanks for your help.
>
>

I've seen something like that... on a NIC that was about to crap out.
I'd go to the local Geek store and buy a couple of cheap NICs just in
case. :-)

--Yan