Date: Tue, 21 Sep 1999 11:26:55 -0700 From: Bill Trost <trost@cloud.rain.com> To: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE> Cc: freebsd-questions@freefall.FreeBSD.org, dhcp-dist@wide.ad.jp Subject: Re: dhcps strangeness Message-ID: <34916.937938415@cloud.rain.com>
next in thread | raw e-mail | index | archive | help
I realize this is an old message, but I thought it worthwhile to have an
explanation and solution on the record.
Over a year ago, Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE> wrote:
I'm using dhcp (wide-dhcp)...
Mar 9 13:19:23 duke dhcps[187]: DHCPDISCOVER: No more available address in the pool
/etc/dhcpdb.pool:
global:!snmk=255.255.255.0:tmof=32400:
subnet0:tblc=global:rout=137.123.44.1:dht1=500:dht2=850:\
:brda=137.123.44.255:dnsv=137.123.44.21:dnsd=somedomain.de:
# entries for manual allocation (DHCP, BOOTP)
3001: :ipad=137.123.44.5:hstn="kukubook.somedomain.de":tblc=subnet0:clid="1:0x0080a89228ac":
I was having this problem, too (using wide-dhcp 1.3.6), and finally
decided I was going to beat this problem into submission. After far
too much gdb-ing, I eventually hit upon the problem: dhcps computes
the subnet a computer is on as soon as it sees the "ipad=" entry.
The problem is that your (and my) dhcpd.pool sets the subnet mask
*after* setting the IP address, so the subnet computed for the entry is
incorrectly based on the default netmask. This wrong subnet is then
used when looking up the entry for the client when the server receives
the DHCPDISCOVER.
So, you can work around this problem by moving the "tblc" entry to the
start of the entry for kukubook. The ultimate fix, presumably, is to
postpone computing the subnet until the entire entry has been read.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34916.937938415>