dhcpd not working as I would expect

[vdubjunkie]

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33204
        groups: lo
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:50:da:b2:37:1c
        groups: egress
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::250:daff:feb2:371c%xl0 prefixlen 64 scopeid 0x1
        inet x.x.x.x netmask 0xffffffe0 broadcast x.x.x.x
xl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:01:03:de:32:84
        description: Wired
        media: Ethernet 100baseTX full-duplex (100baseTX half-duplex)
        status: active
        inet 10.100.0.226 netmask 0xffff0000 broadcast 10.100.255.255
        inet6 fe80::201:3ff:fede:3284%xl1 prefixlen 64 scopeid 0x2
xl2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:50:da:5b:71:54
        description: Wireless
        media: Ethernet 100baseTX full-duplex (100baseTX half-duplex)
        status: active
        inet 172.16.0.226 netmask 0xfffff000 broadcast 172.16.15.255
        inet6 fe80::250:daff:fe5b:7154%xl2 prefixlen 64 scopeid 0x3
vr0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:11:2f:7b:c1:41
        media: Ethernet autoselect (none)
        status: no carrier
enc0: flags=0<> mtu 1536
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33204
        groups: pflog

# grep -v "#" /etc/dhcpd.conf

authoritative;


shared-network WIRED {
        default-lease-time 86400;
        option  domain-name "freak.dub";
        option nis-domain "freak.dub";
        option  domain-name-servers 172.16.0.226, x.x.x.2, x.x.x.3, x.x.x.20, x.x.x.25, x.x..30;
        option broadcast-address 172.16.0.255;
        option routers 172.16.0.226;
        option ntp-servers 172.16.0.226;
        subnet 172.16.0.0 netmask 255.255.255.0 {
                range 172.16.0.25 172.16.0.35;
        }
        host vdubmac {
                hardware ethernet 00:25:00:4d:24:df;
                fixed-address 172.16.0.222;
        }
}

shared-network WIRELESS {
        option domain-name "wifi.freak.dub";
        option domain-name-servers 172.16.0.226, x.x.x.2, x.x.x.3, x.x.x.20, x.x.x.25, x.x.x.30;
        subnet 172.16.0.0 netmask 255.255.255.0 {
                option routers 172.16.0.226;
                option domain-name-servers 172.16.0.226;
                option ntp-servers 172.16.0.226;
                range 172.16.0.25 172.16.0.35;
        }
}

xl1 is WIRED subnet and xl2 is WIRELESS subnet. When I had "10.100.0.226" as the WIRED router, it bled through to my laptop which gets it's IP via a Linksys AP being used as just that, an AP only, to the WIRELESS vlan on my Catalyst 2950 switch which is shared by the port on the switch which connects to my xl2 iface.

Can anybody tell me why it's not handing out the WIRELESS settings to a client getting it's IP via the WIRELESS interface?

oh yes...

# uname -a
OpenBSD zeus.freak.dub 4.4 GENERIC#1021 i386

[jggimi]

If you want dhcpd to hand out addresses on only one subnet, start dhcpd so that it only listens on that one subnet. For example, you could add the following to /etc/rc.conf.local:

dhcpd_flags="xl2"

[jggimi]

OK. I noted you already posted about using one or two NICs with dhcpd, in an earlier thread.

I went back and looked at your dhcpd.conf, and found the problem.

You have two NICs on the same subnet, 172.16.0.0/16. That is the reason for "bleeding". Use different subnets for wired and wireless, and your problem will be solved.

[vdubjunkie]

I'm sorry I may not have been clear. The 172.16 IPs used in the WIRED section were put that way in order to make the system work. This was how I proved that the WIRELESS IP being handed out was getting it's values from that section. Here is the previous version which I have conveniently saved as always..

# cat dhcpd.conf.orig                                                          

authoritative;


shared-network WIRED {
        default-lease-time 86400;
        #max-lease-time 172800;
        option  domain-name "freak.dub";
        option nis-domain "freak.dub";
        option time-offset -6; #CST
        option  domain-name-servers 10.100.0.226, x.x.x.2, x.x.x.3, x.x.x.20, x.x.x.25, x.x.x.30;
        option broadcast-address 10.100.0.255;
        option routers 10.100.0.226;
        option ntp-servers 10.100.0.226;
        subnet 10.100.0.0 netmask 255.255.255.0 {
                range 10.100.0.25 10.100.0.35;
        }
        host vdubmac {
                #next-server ns1.freak.dub;
                hardware ethernet 00:25:00:4d:24:df;
                fixed-address 10.100.0.222;
        }
}

shared-network WIRELESS {
        option domain-name "wifi.freak.dub";
        option domain-name-servers 172.16.0.226, x.x.x.2, x.x.x.3, x.x.x.20, x.x.x.25, x.x.x.30;
        subnet 172.16.0.0 netmask 255.255.255.0 {
                option routers 172.16.0.226;
                option domain-name-servers 172.16.0.226;
                option ntp-servers 172.16.0.226;
                range 172.16.0.25 172.16.0.35;
        }
}

[jggimi]

From the dhcpd.conf(5) man page:

The shared-network statement is used to inform the DHCP server that some
IP subnets actually share the same physical network. Any subnets in a
shared network should be declared within a shared-network statement.
Parameters specified in the shared-network statement will be used when
booting clients on those subnets unless parameters provided at the subnet
or host level override them. If any subnet in a shared network has
addresses available for dynamic allocation, those addresses are collected
into a common pool for that shared network and assigned to clients as
needed. There is no way to distinguish on which subnet of a shared
network a client should boot.

My recommendation: don't use it. Use the subnet statement, instead.

[There0]

I agree competely with that last statement of jggimi, it is highly recommended NOT to share the same subnet with ANY interface (under certain extreme situations?) especially a wireless one.

[vdubjunkie]

Thanks so much. Most examples I've found use that shared-network pragma. Understanding the difference was clear and simple once you pointed me in the right direction, and naturally this has solved my problem.