Oops I sent this to Nick and not the list...
On 28/04/2008, at 1:39 AM, Nick Holland wrote:
Damon McMahon wrote:
Greetings,
Can anyone enlighten me as to why DHCP clients are no longer
retrieving their domain name from my OpenBSD DHCP/DNS server which I
recently upgraded from 4.1 to 4.3 via 4.2? DHCP and DNS seems to
functioning normally otherwise...
Any advice appreciated (as always),
Damon
it is your DHCP /SERVER/ machine which was upgraded, not the clients
(I say this because I started out the note thinking it was a client
that was upgraded and no longer fetching from the DHCP server)
Show us what is happening, what you expected to happen, why you
expected
etc., rather than diagnosing the problem for us. :)
yeah sorry about the lazy posting, just thought it might be a known
issue with the upgrade scripts. It was my server that was upgraded.
Here's the info...
Contents of dhcpd.conf would be interesting,
% cat /etc/rc.local | grep dhcpd
if [ -r /etc/dhcpd.ral0.conf ] && [ X"${dhcpd_flags}" != X"NO" ]; then
echo -n ' dhcpd:ral0 '
touch /var/db/dhcpd.ral0.leases
/usr/sbin/dhcpd -c /etc/dhcpd.ral0.conf -l /var/db/
dhcpd.ral0.leases ral0
% cat /etc/dhcpd.ral0.conf
shared-network THE_OFFICE {
use-host-decl-names on;
option domain-name "office";
option domain-name-servers 192.168.1.1;
option ntp-servers 192.168.1.1;
option smtp-server 192.168.1.1;
default-lease-time 86400;
max-lease-time 259200;
#
# this is an IPsec protected wifi network so each host is in its own /
30 subnet
#
subnet 192.168.1.0 netmask 255.255.255.252 {
option routers 192.168.1.1;
option broadcast-address 192.168.1.3;
host kang {
hardware ethernet 00:30:65:1a:43:7d;
fixed-address kang.office; # resolves to
192.168.1.2 - see below
}
}
# other DHCP clients in their own /30 subnets are declared here
# they are experiencing the same issue
}
% nslookup
> kang
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: kang.office
Address: 192.168.1.2
as well as any message
in /var/log/daemon regarding dhcpd.
All looks normal...
Apr 27 19:24:21 wiggum dhcpd: DHCPDISCOVER from 00:30:65:1a:43:7d via
ral0
Apr 27 19:24:21 wiggum dhcpd: DHCPOFFER on 192.168.1.2 to 00:30:65:1a:
43:7d via ral0
Apr 27 19:24:22 wiggum dhcpd: DHCPREQUEST for 192.168.1.2 from
00:30:65:1a:43:7d via ral0
Apr 27 19:24:22 wiggum dhcpd: DHCPACK on 192.168.1.2 to 00:30:65:1a:
43:7d via ral0
More details on what you did for the upgrade might also be
interesting,
as a fair number of people (including me) have upgraded their DHCP
servers from 4.1 (and before) to 4.2 to 4.3 without reporting this
problem, so my guess at this point is either something strange was
done
during the upgrade process or the problem is not directly related to
the upgrade.
Used /faq/upgrade42.html including upgrade42.patch but avoided
upgrading packages due to the libexpat issue, then used /faq/
upgrade43.html - pretty much to the letter, ran into some minor
issues with upgrade43.patch mangling my customised named.conf but I
think this is all resolved as forward and reverse name resolution is
now functioning normally:
% nslookup
> set type=any
> office
Server: 127.0.0.1
Address: 127.0.0.1#53
office
origin = wiggum.office
mail addr = hostmaster.the.office
serial = 2008042502
refresh = 3600
retry = 900
expire = 1209600
minimum = 43200
office nameserver = wiggum.office.
office mail exchanger = 10 wiggum.office.
> 192.168.1.2
Server: 127.0.0.1
Address: 127.0.0.1#53
2.1.168.192.in-addr.arpa name = kang.office.
Does
There isn't much to dhcpd: dhcpd.conf and /usr/sbin/dhcpd are about
it.
Some other files launch it, but if it is running, it will be mostly
those two files. dhcpd was replaced in the upgrade process,
dhcpd.conf
/should/ be untouched. Looking at the dates on those files will tell
a few things, I suspect.
% ls -l /etc/dhcpd.ral0.conf
-rw-r--r-- 1 root wheel 3678 Feb 2 01:24 /etc/dhcpd.ral0.conf
% ls -l /usr/sbin/dhcpd
-r-xr-xr-x 1 root bin 85220 Mar 13 03:11 /usr/sbin/dhcpd
Nick.
One other point to note (not sure if relevant). As dhcpd is serving a
wireless IPsec network I use 2 instances of named(8) - a crippled
version which accepts redirected queries on ral0 via a pf(4) rdr
rule, which works in conjunction with a specially configured instance
of httpd(8) to tell users how to authenticate using IPsec; and a full
version of named(8) which only accepts queries on the enc0 interface.
If my pf.conf is required to clarify please let me know.
Any advice will be appreciated.
Cheers,
Damon
