Bug 131212 - "booting disallowed" for hosts that should get addresses
Summary: "booting disallowed" for hosts that should get addresses
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp   
(Show other bugs)
Version: 2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-30 02:11 UTC by Jason Tibbitts
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version: dhcp-3.0.1-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-30 03:05:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:566 normal SHIPPED_LIVE Updated dhcp and dhclient packages 2005-05-26 04:00:00 UTC

Description Jason Tibbitts 2004-08-30 02:11:10 UTC
Description of problem:
dhcpd refuses valid DHCPDISCOVER requests with the following log entry:

Aug 25 15:30:25 util4 dhcpd: DHCPDISCOVER from 00:02:3f:7e:c1:7b via
eth0: booting disallowed

There is a defined group of hardware addresses for which booting is
denied, but the server is refusing requests from addresses not on that

It seems this is a known problem, as a simple search of the DHCP
mailing list shows:

Unfortunately the author of the DHCP server software doesn't seem to
understand open source, as the patch to fix this problem is not being
revealed and was not considered for 3.0.1.  In the meantime we're
being clobbered by this bug.  Perhaps Red Hat could extract the patch
from the author.

Version-Release number of selected component (if applicable):
dhcp-3.0.1rc14-1 (i386)

I have built and installed the 3.0.1-7 pachage from rawhide; it's to
early to tell if it fixes the problem but I looked at the list of
additional patches which are applied and didn't see any which looked
like they might be related.  I will report back after it's been stressed.

How reproducible:
Occurs randomly.  A restart usually clears the problem for a while.

Steps to Reproduce:
1. Set up a group:

group {
  deny booting;
  host a {hardware ethernet xx:yy:yy:blah;}
  host b {hardware ethernet xx:yy:yy:blah;}

2. Wait random amount of time with lots of activity on DHCP server

Actual results:
Hosts not in above group are disallowed.

Expected results:
Host not in above group are given addresses (assuming the pool is free).

Comment 1 Jason Vas Dias 2004-08-30 14:57:51 UTC
The ISC DHCP maintainer writes:
> On Tue, Mar 02, 2004 at 10:11:33PM +0000, David W. Hankins wrote:
> > i have reproduced the problem in the lab.
> when deny booting (and some other deny/error/etc conditions of the
> function) is tickled, the host entry for the denied host remains
> referenced on the lease.  this is not cleared when the server tries
> to offer the lease to an otherwise leaseless third party, which causes
> them to inherit the previous host's configuration.
> this definitely reaches further than just 'deny booting'.  many forms
> of mis-host-identification could be happening in low-free-lease
> or long-runtime circumstances.
> this will be fixed in the next release candidate.
> if you need a patch before then, mail me (not the list).

Perhaps David's reluctance to release the patch is because it
would be a "Major" fix with perhaps unforseen consequences .

I have emailed David to obtain the patch and am investigating .

Perhaps it would be better to wait for a fully tested fix for this
problem to appear in DHCP-3.0.2 ; but if I obtain or produce a
patch earlier that I can verify causes no other problems, I'll 
try to get it into the next Red Hat DHCP release. 

Comment 2 Jason Tibbitts 2004-08-30 15:20:37 UTC
I suppose "major consequences" could mean "security hole", but at this
point the DHCP server simply doesn't work for us and backing down to a
release that doesn't have this bug implies running a release with
known security issues.  I think I'm willing to gamble.

I can understand if Red Hat decides not to include the patch in their
official version, but if you do receive the patch, could you possibly
attach it to this bug or send it to me privately?

By the way, things are just getting going here and the current version
from rawhide is already rejecting requests that it should not.

Comment 3 Jason Vas Dias 2004-08-30 17:39:44 UTC
 I have now obtained the patch from David and have compiled 
 dhcp*-3.0.1-8 containing it for i386 FC2. You can download the
 rpms (including src.rpm) from:

 If you don't mind being a guinea pig for this, I'd appreciate
 if you could test this release and let me know if :
  A) It fixes the problem
  B) It causes any other problems.
 I've been unable to reproduce the problem here with my very limited
 test setup - it seems to require a large busy subnet to occur.
 Please let me know if it works well and I will integrate it into
 the official release and issue a FC2 update.
 Thanks, Jason Vas Dias.

Comment 4 Jason Tibbitts 2004-08-30 18:00:38 UTC
I have applied the patch and let it run for a bit.  So far everything
seems fine but it takes a while for the problem to occur.

Comment 5 Jason Tibbitts 2004-08-31 15:44:57 UTC
Still running smoothly.  I will let it go for another week and report

Comment 6 Jason Tibbitts 2004-09-10 15:59:02 UTC
Everything is running smoothly after ten days.

I doubt it's worth pushing an update to FC2 for this issue, but of
course that's your call.  It would be great if it makes it into FC3. 
I'm just happy to have a working server.

Comment 7 Jason Vas Dias 2004-09-10 16:15:28 UTC
 Now that we know the patch doesn't break anything on a busy subnet,
 I will submit it to FC3 (dhcp-3.0.1-8), especially as this seems to
 be a common problem judging by the number of times it is reported
 in the dhcp-server mailing list.

Comment 8 John Flanagan 2004-12-21 19:41:47 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Comment 9 Jason Tibbitts 2006-02-16 01:51:21 UTC
I've recently moved my DHCP service to a host running FC4 (dhcp-3.0.2-30.FC4)
and I've started seeing this problem again.  A search of the dhcp-server list
shows that this bug indeed was not fixed by 3.0.2:


I'm going to try the packages in http://people.redhat.com/~jvdias/DHCP/FC-4/ and
see if I have any luck.

Comment 10 Jason Tibbitts 2006-02-16 23:07:05 UTC
Since updating to dhcp-3.0.3-22.FC4 and fixing the selinux problems caused by
the change from /var/lib/dhcp to /var/lib/dhcpd, I'm still seeing "booting
disallowed" for addresses which I did not specifically disallow.

Comment 11 Jason Vas Dias 2006-02-17 00:28:22 UTC
The original bug was that if specific hosts were denied booting with a 
'group denied { deny booting; host name { hardware ethernet xx...; } }' clause,
then hosts not in that group are not allowed to boot.
Is this what you are seeing ? 
If so, please send your dhcpd.conf to : jvdias@redhat.com and open another bug.
I've just tested this bug again, with both 3.0.3-22+ and with RHEL-4 3.0.1-54 ,
and I cannot reproduce the problem.

Comment 12 Matthew Miller 2006-06-30 03:05:40 UTC
The original FC2 bug here was fixed in an errata. If there is an issue in FC4 or
later, please file a new bug. Thanks.

Note You need to log in before you can comment on or make changes to this bug.