From owner-freebsd-questions Tue Sep 21 11:27:31 1999 Delivered-To: freebsd-questions@freefall.freebsd.org Received: from jli.com (jli.com [199.2.111.1]) by hub.freebsd.org (Postfix) with SMTP id 911E314A04 for ; Tue, 21 Sep 1999 11:27:22 -0700 (PDT) (envelope-from trost@cloud.rain.com) Received: (qmail 8471 invoked by uid 4); 21 Sep 1999 18:27:21 -0000 Received: (qmail 34919 invoked from network); 21 Sep 1999 18:26:55 -0000 Received: from localhost.cloud.rain.com (HELO cloud.rain.com) (127.0.0.1) by localhost.cloud.rain.com with SMTP; 21 Sep 1999 18:26:55 -0000 To: Christoph Kukulies Cc: freebsd-questions@freefall.FreeBSD.org, dhcp-dist@wide.ad.jp Subject: Re: dhcps strangeness MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <34915.937938415.1@cloud.rain.com> Date: Tue, 21 Sep 1999 11:26:55 -0700 Message-ID: <34916.937938415@cloud.rain.com> From: Bill Trost Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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