I am setting up a Squid Proxy/DHCP/FTP/DNS box for a project at work. Everything works fine when I connect to the network with a Linux box, but when I connect with a M$ box I am unable to obtain and hold a DHCP lease.

What I want to happen is for boxes to be plugged into my network, get a 192.168.10 address, and use this box to route to the 192.168.3 network which is the gateway to the internet.

To make a long story short, I've got 192.168.10.0 and 192.168.3.0 running on the same switch (no VLANS for you Cisco people), and I've got two NIC's in my server.

When I watch /var/log/daemon.log I saw that what was happening is that the M$ box was getting a lease then attempting to get a new lease one second later. Mixxed in with these lease messages was a line stating "no free leases on subnet 192.168.3.0."

When I disconnect the 192.168.3 interface on my server the M$ boxes get an IP and hold it, so it looks to me like the M$ box is re-trying to get a lease on the 192.168.3 network even though I'm not handing out IP's on that network.

My /etc/dhcpd.conf file looks like this:

subnet 192.168.10.0 netmask 255.255.255.0 {
# Setup Network
# default gateway
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.10.255;

#domains
option domain-name "setup.xxxxx.com";
option domain-name-servers 192.168.10.1;

#dynamic range
range 192.168.10.100 192.168.10.254;
default-lease-time 21600;
max-lease-time 43200;
}

subnet 192.168.3.0 netmask 255.255.255.0 {
}
EOF

The only reason I have an entry for the 192.168.3.0 subnet is that hdcpd bombs if I do not.

Anyone have suggestions on how I can solve my issue through configuration of DHCPD?

Cheers,
MrKnisely

I added an entry for a shared network and it appears to work now. Here's the config:

shared-network LabNetwork {
# Setup Network
subnet 192.168.10.0 netmask 255.255.255.0 {
# default gateway
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.10.255;
# domains
option domain-name "setup.xxxxxxx.net";
option domain-name-servers 192.168.10.1;
# dynamic range
range 192.168.10.100 192.168.10.254;
default-lease-time 21600;
max-lease-time 43200;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
}
}


As you can see, all it did was put a "shared-network { }" around it.

Cheers,
MrKnisely

Well, it's pretty obvious that the problem is the 192.168.3.0 subnet entry. If anything tried to get an IP from that subnet, it would of course fail since there is no range information.

What happens when you remove that? What sort of problem does it cause dhcpd?

Well, maybe not then.

I too thought it was stupid to even mention the 192.168.3.0 network in my DHCP config, but I had to or DHCPD would bomb. It needs each subnet mentioned in the config or it won't run properly; though, I have been told by others in another forum that theirs works without mention of the 2nd subnet. If you read the man pages though it says to mention all the subnets for the daemon to work.

The reason for the strange setup is that I have these two networks sharing the same media. I have a 192.168.10.0 system plugged into the same switch/hub as a 192.168.3.0 system. The odd part is that my Linux boxes get a DHCP address on the .10 and they don't care that the .3 failed. They're just happy they got an address. It was only the M$ boxes that weren't satisfied with one address, they wanted an address from both interfaces. Odd, but not surprising given M$'s other quirks.

Thansk for the post,

MrKnisely