dhcp became unresponsive after a few minutes

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Start the process via running 'python -OO main.py'
2.
3.

What is the expected output? What do you see instead?

In the first a few minutes, can see incoming dhcp request, after
a few minutes (say 5 minutes), it seems to be no longer responsive.
Another way to show the problem is: a client can pxe boot in the first
a few minutes when the staticdhcpd is running. Later it won't be able to 
pxeboot.

What version of the product are you using? On what operating system?

1.4.3 on Redhat El4 U3

Please provide any additional information below.

Had an instance of ISC's dhcpd (v3.0.1) running on the same server.
Did a tail -f /var/log/messages, can see it processing incoming dhcp requests 
while staticdhcpd stalled.

Original issue reported on code.google.com by andrew.x...@gmail.com on 15 Jan 2011 at 12:58

[GoogleCodeExporter]

Were you running the two daemons (ISC's server and staticdhcpd) at the same 
time? If so, it's possible that ISC's server attempted to automatically rebind 
on port 67 after a few minutes, which would have given it control of the socket.

If you can elaborate a bit more on the details of your setup, it would be 
appreciated.

Original comment by red.hamsterx on 15 Jan 2011 at 2:36

[GoogleCodeExporter]

You are right about the cause of the hang. ISC dhcpd is running on the same 
server. After stopping ISC dhcpd, it no longer hangs.

The reason I have them both running is that I have some hosts that need dynamic 
IP assignment.

Thank you for the response !

Original comment by andrew.x...@gmail.com on 15 Jan 2011 at 12:33

[GoogleCodeExporter]

Since client dhcpd requests all come on port 67, I probably can't resolve this 
conflict by just changing conf.py and set DHCP_SERVER_PORT to something else.
I can have a separate server to run staticdhcpd, but I want to avoid having to 
set up
two servers.

Original comment by andrew.x...@gmail.com on 15 Jan 2011 at 12:46

[GoogleCodeExporter]

If you can add a second IP to your server, you can tell staticDHCPd to 
explicitly bind to one address, while telling ISC's server to explicitly bind 
to the other. You could then run them in parallel on the same host, as long as 
you limit ISC's assignable range to something outside the static pool (because 
it wouldn't know anything about reservations).

It shouldn't be too hard to do this if you're running the Unix-like host in a 
VM because you can just add another virtual NIC. If that's not an option, you 
can use aliasing, described at 
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch03_:_Linux_Net
working#Multiple_IP_Addresses_on_a_Single_NIC to let your system take a second 
IP.

If this approach works for you, I'll add this information to the FAQ.

Original comment by red.hamsterx on 15 Jan 2011 at 7:16

• Changed state: Accepted

[GoogleCodeExporter]

Actually, no, that approach won't be enough by itself, since your clients won't 
know which DHCP server's offer to accept.

You should be able to define a "class" with the MACs of all NICs served 
statically and put a "deny" rule before it in the subnet-definition:
{{{
subclass "static" 00:00:00:00:00:00;
subclass "static" 00:00:00:00:00:01;

subnet 10.0.0.0 netmask 255.255.255.0 {
 option routers 10.0.0.1;

 pool {
  not authoritative;
  range 10.0.0.100 10.0.0.250;
  deny members of "static";
 }
}
}}}

This should cause the ISC server to ignore everything tagged "static". You can 
auto-generate this list from your SQL client; an SQLite example follows:
{{{
SELECT 'subclass "static" ' || mac || ';' FROM maps;
}}}

I know this isn't exactly the most graceful solution, but the goal of 
staticDHCPd is to provide an easy means of managing specialised networks where 
the administrator wants full control and knowledge of absolutely every piece of 
equipment in their domain. This is the case in business units that require a 
high degree of security, some small-and-mid-sized businesses with clueful IT 
departments, and large domains like ISPs, where having the ability to update 
the map at run-time, using programmatic methods like SQL, is pretty much 
necessary to allow for scalability -- it was for this reason that the server 
was created.

Original comment by red.hamsterx on 15 Jan 2011 at 8:07

[GoogleCodeExporter]

An alternative, perhaps more maintainable solution, would be to define the 
"static" class as follows:
{{{
class "static" {
 match if substring (vendor-class-identifier, 1, 9) = "PXEClient";
}
}}}

Assuming all of your static clients identify with option 60. If they have 
another common option (MAC prefix, perhaps), you should use that instead. This 
would save you the trouble of needing to manually manage the class-members as 
your network grows.

Please let me know if you find a combination of configurations that work for 
you -- I'd love to document this because I'm sure you won't be alone in wanting 
to set up a hybrid network.

Original comment by red.hamsterx on 15 Jan 2011 at 8:13

[GoogleCodeExporter]

I have tried a test case where staticdhcpd and ISC dhcp sits on two different 
servers.
From the /var/log/messages, I saw the discover requests were ignored by ISC 
dhcp server and picked up by staticdhcpd. The /etc/dhcpd.conf did not 
specifically deny
requests coming to it. I am going to do some testing with a different NIC as 
you suggested.

Actually I made some changes to code in 1.4.3 not to NACK those requests that 
it did not know about. I was worried that might confuse the clients which had 
taken leases from ISC dhcp earlier.

One more thing I am not sure about was the existing clients that took out IP 
assignment and leases from ISC dhcp server. After migrating them to staticdhcpd,
then the leases will need to be renewed. Hopefully that won't be a problem.

Original comment by andrew.x...@gmail.com on 15 Jan 2011 at 10:24

[GoogleCodeExporter]

You shouldn't need to make any changes to the code to avoid unwanted NAKs. The 
following option in the configuration file should handle what you want:

#If True, any unknown MACs will be NAKed instead of ignored. If you may have
#more than one DHCP server serving a single LAN, this is NOT something you
#should enable.
AUTHORITATIVE = False

If staticdhcpd gets a RENEW or REBIND for an "invalid" IP assignment, it will 
send a NAK and then allow the client when it tries to send a new DISCOVER. 
You'll have an IP-swap and possibly lose the address on the host while the DHCP 
process restarts, but it shouldn't cause any long-term problems.

Original comment by red.hamsterx on 15 Jan 2011 at 10:49

[GoogleCodeExporter]

Thanks for the explanation.

Original comment by andrew.x...@gmail.com on 16 Jan 2011 at 12:19

[GoogleCodeExporter]

I think I might have an explanation for why you saw the ISC server sitting idle 
when staticDHCPd was handling responses.

Since it doesn't run as an authoritative server by default, it might be 
listening for responses from other servers before sending its own response to 
the client. Specifically, it's possible that it might be either ignoring the 
first DISCOVER or waiting for five seconds, just to see if another server 
handles the request first.

I don't know whether that's happening for sure, though, so I can't recommend 
that you rely on it. If you do some research and conclude that that is how it 
behaves, however, then things should be both easy and good. Forever.

Original comment by red.hamsterx on 16 Jan 2011 at 6:50

[GoogleCodeExporter]

Some update on my testing. I used a server that has a few NICs. Interestingly, 
I set up ISC dhcpd and staticdhcpd both pointing to the same NIC. This time, 
the staticdhcpd did not hang as I saw on the other server (with one interface 
only and a lot, a lot more dhcpd requests coming in). So I am suspecting the 
traffic volume of incoming dhcp requests might have something to do with it. 
But just my guess.

If I remember correctly, ISC's dhcpd will listen on all the interfaces if you 
do not specifically specify them. But if you intentionally omit one of them, 
the daemon just won't listen from that interface?

Original comment by andrew.x...@gmail.com on 20 Jan 2011 at 1:19

[GoogleCodeExporter]

If volume were a crippling factor, the server never would have made it into 
production. Right now, its primary deployment is serving several thousand users 
with one-day renewal rates and the potential for massive floods when local 
switches go down (ISP environment). I'm not saying your guess is wrong, 
necessarily, but if it were reproducible, I'm sure I would have noticed by now. 
But, if you're right, I need to know so I can address the problem immediately.

You're correct about the ISC server's default behaviour, in that it binds to 
all interfaces by default. I decided against that for this implementation, 
though, since its intended use is in highly structured environments, where you 
would want to strictly control how packets are routed through a network. ISC's 
approach was probably chosen because it makes for a more versatile design, 
usable in a wider number of roles, albeit with added complexity associated with 
its configuration and maintenance.

Original comment by red.hamsterx on 20 Jan 2011 at 3:07

[GoogleCodeExporter]

This seemed to be related to the conflict with ISC dhcpd. I accidentally turned 
off ISC dhcpd or somehow it died on its own this morning. The staticdhcpd ran 
without any issue continuously without any problem. A few minutes after I 
started the ISC dhcpd, staticdhcpd froze.

Original comment by andrew.x...@gmail.com on 14 Feb 2011 at 7:30

[GoogleCodeExporter]

Closing this non-code-related issue.

Original comment by red.hamsterx on 22 Jun 2011 at 11:19

• Changed state: Invalid