Hello, 

dhcp is not my favorite technology, but if the apartment is to have random
wireless clients, it's the right answer.  I'm also one of the random
wireless clients, or, rather, my Powerbook (OS X) is. 

If you've been following my saga, you know I recently upgraded my Soekris
box to NetBSD 3.0.  Since then, the wi0 interface started working again
(good) but dhcpd changed somehow.  

The first evidence of change isn't directly the subject but bears mention
in case it's related: the Mac stopped learning its DNS domain via dhcp on
the *wired* interface.  Suddenly it was 'Monarch.local'.  So I assigned
the wired address manually, as a workaround.  

The wireless interface I'd really rather have managed by dhcp because any
manner of laptops show up here from time to time.  And it would be really
nice if they could be routed to the wired LAN, which of course means they
need the correct netmask.  And, for that matter, FQDN.  

I've looked and looked at my dhcpd.conf and don't see what else I could
say.  Here're the relevant bits:

==  snip  ==
# option definitions common to all supported networks...
option domain-name "schemamania.org";
option domain-name-servers 192.168.1.254, 192.168.2.254;
option subnet-mask 255.255.0.0;
default-lease-time 604800;
max-lease-time 604800;
ddns-update-style none;

# Set parameters for the 192.168.2.0/24 subnet.
  subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.100 192.168.2.208;
  option routers 192.168.2.254;
}
== unsnip ==

The client is not getting the global domain-name setting, and he's not
getting the subnet /24 netmask.  Instead, he's getting no domain name and
the global /16 netmask.  

It's not easy to debug.  Does anyone know of a command-line utility that
makes client request and prints out the response?  On the server side,
everything looks copasetic in /var/log/messages:

dhcpd: DHCPREQUEST for 192.168.2.205 from 00:14:51:7e:1f:83 (Monarch) via
wi0
dhcpd: DHCPACK on 192.168.2.205 to 00:14:51:7e:1f:83 (Monarch) via wi0

But looking at the Mac, you'd never know it.  :-(

In case it matters, tcpdump on the Mac has a lot of messages like this:

00:56:21.820689 IP 192.168.2.254 > 192.168.2.205: icmp 36: 192.168.2.254
udp port osu-nms unreachable

... meaning the Mac isn't listening on port 192:

$ grep osu-nms /etc/services 
osu-nms         192/udp     # OSU Network Monitoring System       
osu-nms         192/tcp     # OSU Network Monitoring System       

Of course I know this is a NetBSD list.  I hope you'll file it under
"interoperability".  

Thanks.

--jkl