Re: dhcp apparently handing out the wrong ip address

["Jan C. Nordholz" <jckn@gmx.net>]

On Sat, Jan 08, 2005 at 09:54:59AM +0000, Alan Chandler wrote:
> [...]
> The real puzzle to me, is that the only recent change to this file is to add a 
> hardware address for the wireless pcmcia card.  Before it was always working 
> 
> Anyone any ideas as to what is wrong? 
> 
> 
> my /etc/dhcp3/dhcpd.conf file has the following in it
> 
> shared-network home-net {
>   option domain-name "home";
>   option domain-name-servers 192.168.0.20, 192.168.0.10;
> 
>   option subnet-mask 255.255.255.0;
>   default-lease-time 21600;
>   max-lease-time 86400;
>   authoritative;
>   subnet 192.168.0.0 netmask 255.255.255.0 {
>     range 192.168.0.40 192.168.0.59;
>     option routers 192.168.0.10;
>   }
> 
> #  The following are hosts which require a fixed ip-address (for instance
> #  so that NAT can direct things to them)
> #
> 
>   host roo {
>     hardware ethernet 00:50:da:ec:83:9a;
>     fixed-address roo.home;
>   }
>   host rabbit {
>     hardware ethernet 00:06:5b:b7:9c:35;
>     hardware ethernet 00:06:25:2a:fa:25;
>     fixed-address rabbit.home;
> ....
> 
> This last line refers to the dns - where a host lookup of rabbit.home gives
> J
> roo:~# host rabbit.home
> rabbit.home has address 192.168.0.25
> 
> From syslog although the hardware address matches above, it gets offered 
> 192.168.0.59
> 
> 
> Jan  8 09:42:30 roo dhcpd: DHCPDISCOVER from 00:06:5b:b7:9c:35 via eth1
> Jan  8 09:42:31 roo dhcpd: DHCPOFFER on 192.168.0.59 to 00:06:5b:b7:9c:35 
> (UKP-A4PUCZGT39T) via eth1
> Jan  8 09:42:31 roo dhcpd: DHCPREQUEST for 192.168.0.59 (192.168.0.20) from 
> 00:06:5b:b7:9c:35 (UKP-A4PUCZGT39T) via eth1
> Jan  8 09:42:31 roo dhcpd: DHCPACK on 192.168.0.59 to 00:06:5b:b7:9c:35 
> (UKP-A4PUCZGT39T) via eth1
> 
Hi Alan,

the only thing I can imagine is that the DHCP query gets matched against
_both_ hardware parameters, not one of them... and the interface querying
the IP address can never match both.
Have you tried splitting the host{}-clause in two? If I understand correctly,
the hostname after the "host" keyword is freely choosable as long as you
adjust the hostname the DHCP client gets sent back, so it might be possible
to write something like:

option use-host-decl-names false
host rabbit1 {
  hardware ethernet 00:06:5b:b7:9c:35;
  fixed-address rabbit.home;
  option host-name rabbit;
}
host rabbit2 {
  hardware ethernet 00:06:25:2a:fa:25;
  fixed-address rabbit.home;
  option host-name rabbit;
}

Sorry that I'm just guessing, but I don't have the equipment at hand to
test that scenario myself. ;-)

HTH,

Jan Nordholz