Bug 144481 - dhcpd: Lease with bogus binding state: 257
Summary: dhcpd: Lease with bogus binding state: 257
Status: CLOSED DUPLICATE of bug 144250
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: powerpc Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-07 16:12 UTC by Roger Blofeld
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 19:07:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Roger Blofeld 2005-01-07 16:12:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.12

Description of problem:
Receive a "bogus binding state" message for every address in the pool.

Due to usage of the __attribute__(("byte")) on the lease struct members of type binding_state_t. Possibly a gcc problem. (using gcc-3.4.3-12).

Solution is to just declare the binding_state_t struct with the "packed" attribute to acheive the same result in a more portable way.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. rpmbuild --rebuild dhcp-3.0.2rc3-1.src.rpm
2. rpm -Uvh dhc*
3. observe system log

Actual Results:  for me, 57 times I get the message

dhcpd: Lease with bogus binding state: 257

dhcpd then will not hand out any leases, claiming that none are available.

Expected Results:  no such messages, served leases

Additional info:

--- dhcp-3.0.1/includes/dhcpd.h.orig     2004-06-10 12:59:29.000000000 -0500
+++ dhcp-3.0.1/includes/dhcpd.h 2005-01-04 15:59:10.287041007 -0600
@@ -255,7 +255,7 @@
 } dhcp_control_object_t;
 /* Lease states: */
-typedef enum {
+typedef enum __attribute__ ((__packed__)) {
        FTS_FREE = 1,
        FTS_ACTIVE = 2,
        FTS_EXPIRED = 3,
@@ -306,9 +306,9 @@
 #      define EPHEMERAL_FLAGS          (MS_NULL_TERMINATION | \
-       binding_state_t __attribute__ ((mode (__byte__))) binding_state;
-       binding_state_t __attribute__ ((mode (__byte__))) next_binding_state;
-       binding_state_t __attribute__ ((mode (__byte__))) desired_binding_state;
+       binding_state_t binding_state;
+       binding_state_t next_binding_state;
+       binding_state_t desired_binding_state;
        struct lease_state *state;

Comment 1 Jason Vas Dias 2005-01-07 16:33:30 UTC
Hi - as you will notice from the dhcp.spec file, 
dhcp-3.0.2rc3-1 is to be
compiled with gcc33, because of gcc bug #144358 :

--- dhpc.spec, @line 142:
RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | sed 's/\ \-mtune\=[^\=\ ]*//'`
./configure --copts "$RPM_OPT_FLAGS"
make %{?_smp_mflags} CC="gcc33"

Did you try installing the default binary RPMs from Red Hat and
observe the 'bogus binding state 257' problem ?

If so, which architecture are you using ? There could be a problem
with gcc33 on our build server.

It is strange (or perhaps an RPM bug ?) that the 'rpm --rebuild' 
command did not use the gcc33 compiler specified in the .spec file .

What is the output of 
   $ gcc33 -v

on your system ?

Doing an 'rpmbuild -vvv --rebuild dhcp-3.0.2rc3.src.rpm 2>&1 | tee
/tmp/dhcp_build.log' would show which compiler was being used and
record the build log. 

I had considered making the same change as you did, or in simply
declaring the binding_state_t members like:

      uint8_t  binding_state;

It has yet not been fully tested what the effect of changing this
crucial structure definition will be on the DHCP server .

Also we don't want to make the change only in Red Hat's DHCP, but 
also upstream in the ISC DHCP code. I am in contact with the ISC
DHCP developer on this issue and we are deciding how best to resolve 
it longterm .


*** This bug has been marked as a duplicate of 144250 ***

Comment 2 Red Hat Bugzilla 2006-02-21 19:07:50 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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