Red Hat Bugzilla – Bug 131212
"booting disallowed" for hosts that should get addresses
Last modified: 2007-11-30 17:10:48 EST
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 list. It seems this is a known problem, as a simple search of the DHCP mailing list shows: http://marc.theaimsgroup.com/?l=dhcp-server&w=2&r=1&s=booting+disallowed&q=b 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).
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.
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.
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: http://people.redhat.com/~jvdias/DHCP/FC2 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.
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.
Still running smoothly. I will let it go for another week and report back.
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.
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.
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. http://rhn.redhat.com/errata/RHBA-2004-566.html
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: http://marc.theaimsgroup.com/?l=dhcp-server&w=2&r=1&s=booting+disallowed&q=b I'm going to try the packages in http://people.redhat.com/~jvdias/DHCP/FC-4/ and see if I have any luck.
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.
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.
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.