Also present in dhclient-4.0.0-20.fc9.i386.

Does this happen if you disable NetworkManager and run dhclient by hand?  That is, run dhclient by hand for each interface to get the same configuration state that NM gives you, but without NM doing it.

Orion,

Any updates?  I have a feeling that your F-8 system in question has the network and NetworkManager services enabled.

    chkconfig --list | grep -i network

No, network is definitely disabled.

Seems to be stuck in the following loop:

Breakpoint 1, omapi_one_dispatch (wo=0x0, t=0xbf9a7ce8) at dispatch.c:298
298             gettimeofday (&now, (struct timezone *)0);               
295             count = select (max + 1, &r, &w, &x, t ? &to : (struct timeval *)0);                                                                              
298             gettimeofday (&now, (struct timezone *)0);                       
299             cur_time = now.tv_sec;                                           
304             if (count < 0) {                                                 
299             cur_time = now.tv_sec;                                           
304             if (count < 0) {                                                 
402             for (io = omapi_io_states.next; io; io = io -> next) {           
405                     omapi_object_reference (&tmp, io -> inner, MDL);         
403                     if (!io -> inner)                                        
405                     omapi_object_reference (&tmp, io -> inner, MDL);         
408                     if (io -> readfd &&                                      
410                             if (FD_ISSET (desc, &r))                         
415                     if (io -> writefd &&                                     
421                     omapi_object_dereference (&tmp, MDL);
402             for (io = omapi_io_states.next; io; io = io -> next) {
403                     if (!io -> inner)
405                     omapi_object_reference (&tmp, io -> inner, MDL);
408                     if (io -> readfd &&
410                             if (FD_ISSET (desc, &r))
415                     if (io -> writefd &&
421                     omapi_object_dereference (&tmp, MDL);
402             for (io = omapi_io_states.next; io; io = io -> next) {
427             for (io = omapi_io_states.next; io; io = io -> next) {
460                                             omapi_io_dereference (&tmp, MDL);
447                                             omapi_io_dereference
460                                             omapi_io_dereference (&tmp, MDL);
454                                                     omapi_signal_in
427             for (io = omapi_io_states.next; io; io = io -> next) {
447                                             omapi_io_dereference
454                                                     omapi_signal_in
428                     if (io -> reaper) {
463                     prev = io;
427             for (io = omapi_io_states.next; io; io = io -> next) {
428                     if (io -> reaper) {
463                     prev = io;
427             for (io = omapi_io_states.next; io; io = io -> next) {
467     }
427             for (io = omapi_io_states.next; io; io = io -> next) {
467     }
dispatch () at dispatch.c:144
144             } while (status == ISC_R_TIMEDOUT || status == ISC_R_SUCCESS);
142                     tvp = process_outstanding_timeouts (&tv);
143                     status = omapi_one_dispatch (0, tvp);
144             } while (status == ISC_R_TIMEDOUT || status == ISC_R_SUCCESS);
142                     tvp = process_outstanding_timeouts (&tv);
143                     status = omapi_one_dispatch (0, tvp);

Breakpoint 1, omapi_one_dispatch (wo=0x0, t=0xbf9a7ce8) at dispatch.c:298
298             gettimeofday (&now, (struct timezone *)0);

(gdb) print to
$6 = {tv_sec = 12, tv_usec = 813891}

Not sure what information would be useful...

(gdb) print status
$10 = <value optimized out>

What architecture are you on?  i386, x86_64, or ppc?

i386.  Might be able try to duplicate on x86_64...

Next question:  does this happen on F-9 or later?

The above gdb trace is from F-9 (and as noted in comment #1).  Don't know about F-10.

I'm confused, I think.  The Version field for the bug is set to 8, so I'm assuming this is affecting Fedora 8.  In comment #1, are you saying the problem occurs with that version of dhclient on F-9 or did you install that version of dhclient on the affected F-8 system and try it there?

Sorry, it happens with both F-8 and F-9.  I'm currently running F-9 on my laptop so that is easiest for me to debug with at the moment, but it does happen with both.

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Still present in F-10.

Going back to the initial report, how are the two interfaces configuered?  I can't imagine you're using dhclient to configure both because the dhcp server wouldn't allow the same IP to go out to two different hosts.

I am trying to recreate this locally.

I have the following files on the client:

/etc/dhclient-eth0.conf:
send dhcp-client-identifier "hostname";
append domain-name " cora.nwra.com";
append domain-name-servers 65.44.101.180;

and the same fin /etc/dhclient-eth1.conf and /etc/dhclient-wlan0.conf.

In the server's dhcpd.conf:

host hostname {
        hardware ethernet 00:B0:D0:0D:F2:A3;
        option dhcp-client-identifier "hostname";
        fixed-address hostname.cora.nwra.com;
}

Change "hostname" as appropriate.

I've upgraded rawhide to ISC dhcp-4.1.0.  Does the same thing happen with that version?

Orion,

Are you still seeing this with ISC dhcp-4.1.0 in rawhide?

I installed dhclient-4.1.0-5.fc77 on my F10 box.  Still see DHCPREQUESTs every 20 seconds or so.

Starts after the second interface has been up for about 2 hours.

Feb 17 17:07:03 cynosure dhclient: Listening on LPF/wlan0/00:0f:66:4c:74:01          
Feb 17 17:07:03 cynosure dhclient: Sending on   LPF/wlan0/00:0f:66:4c:74:01          
Feb 17 17:07:03 cynosure dhclient: Sending on   Socket/fallback                      
Feb 17 17:07:04 cynosure dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 i
nterval 8                                                                            
Feb 17 17:07:12 cynosure dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 i
nterval 12                                                                           
Feb 17 17:07:12 cynosure dhclient: DHCPOFFER from 192.168.0.8                        
Feb 17 17:07:12 cynosure dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67   
Feb 17 17:07:12 cynosure dhclient: DHCPACK from 192.168.0.8                          
Feb 17 17:07:12 cynosure NetworkManager: <info>  DHCP: device wlan0 state changed pre
init -> bound                                                                        

Feb 17 18:34:35 cynosure dhclient: DHCPREQUEST on eth1 to 192.168.0.8 port 67
Feb 17 18:34:35 cynosure dhclient: DHCPACK from 192.168.0.8
Feb 17 18:34:35 cynosure dhclient: bound to 192.168.0.72 -- renewal in 5969 seconds.

Feb 17 19:03:34 cynosure dhclient: DHCPREQUEST on wlan0 to 192.168.0.8 port 67
Feb 17 19:03:38 cynosure dhclient: DHCPREQUEST on wlan0 to 192.168.0.8 port 67
...
Feb 17 20:13:44 cynosure dhclient: DHCPREQUEST on wlan0 to 192.168.0.8 port 67
Feb 17 20:14:04 cynosure dhclient: DHCPREQUEST on eth1 to 192.168.0.8 port 67
Feb 17 20:14:04 cynosure dhclient: DHCPREQUEST on wlan0 to 192.168.0.8 port 67
Feb 17 20:14:04 cynosure dhclient: DHCPACK from 192.168.0.8
Feb 17 20:14:04 cynosure dhclient: bound to 192.168.0.72 -- renewal in 6467 seconds.
Feb 17 20:14:12 cynosure dhclient: DHCPREQUEST on wlan0 to 192.168.0.8 port 67
...

I've reported this to ISC upstream.  The ticket number is #19604 at ISC.

Is there a URL for this ticket?

Sadly, no, but I will post any updates from ISC here.  They do not have an externally accessible bug tracking system.