Bug 52385 - [8139too] kernel IP autoconfig dhcp request fails
Summary: [8139too] kernel IP autoconfig dhcp request fails
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-23 12:13 UTC by cradford
Modified: 2013-07-03 02:05 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2003-06-06 17:50:38 UTC

Attachments (Terms of Use)

Description cradford 2001-08-23 12:13:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)

Description of problem:
Using etherboot with dhcp to load kernel image, dhcp results NOT passed on 
kernel command line, (passing "any" ).
Kernel configured for IP autoconfig bootp/NFS root.
Kernel dhcp sends DHCPDISCOVER, receives DHCPOFFER and drops it ( 
ic_myaddr != INADDR_NONE )

file: net/ipv4/ipconfig.c 
function: ic_dynamic(void) 
I hacked the code to add "ic_myaddr=INADDR_NONE;" after call to 
ic_bootp_init(), cured problem, but this is obviously not the propper 
solution! There could of course be a documentation error, with the result 
that the configuration I created could be incorrect.

Version-Release number of selected component (if applicable):
kernel source versions tried and failed: 2.4.2-2, 2.4.3-12, 2.4.7-2(from 

How reproducible:

Steps to Reproduce:
1.Build kernel with IP autoconfig & DHCP & NFS root.
2.Network load kernel via etherboot netrom or diskette ( also using dhcp ) 
passing "any" or "dhcp" to kernel.

Actual Results:  Infinite loop:
dhcp DHCPDISCOVER packet sent, DHCPOFFER received and dropped.

Expected Results:  DHCPOFFER accepted! break out of loop.

Additional info:

Comment 1 David Miller 2001-08-23 21:25:30 UTC
I think there must be something wrong with your config.
There are only two ways, besides receiving a DHCPOFFER
packet, that ic_myaddr can change:

1) Via kernel command line
2) Via bootp/rarp packets

I think what may be happening, therefore, is that your machine
is receiving bootp/rarp responses from some misconfigured system.
This would explain the DHCPOFFER packets being dropped.

Comment 2 cradford 2001-08-24 08:23:08 UTC
Yes, it is receiving DHCPOFFER from another system on the same network ( which 
is configured correctly, and cannnot be changed ). Isn't it up to the client to 
"choose" the apropriate DHCPOFFER to accept ? Then the DHCPREQUEST is targeted 
at the specific dhcp server that offered the configuration wanted. If it dosent 
get the DHCPACK back, it all starts again. That is how our current network 
behaves, mostly due to visiting laptop users whose ethernet addresses (MACID) 
is unknown, and printers, whose ethernet address (and required configuration) 

I ran ethereal, which shows that linux is not receiving the DHCPOFFER from the 
second system until after the first dhcp dialogue has completed(my kernel hack) 
and the dhcp server has sent DCHPACK.

I am no kernel guru or 'C' programmer, but it looks to me like the DCHPACK is 
ignored where the kernel is concerned, how do you know whether the request was 
accepted or denied (another booting node beat you to it???) by the dhcp server.

Etherboot is also using dhcp, and works faultlessly as do all our other dhcp 
systems, this is definitely a linux issue.

Comment 3 David Miller 2001-08-27 23:05:31 UTC
I've asked the author of the DHCP support (Chip Salzenberg) how
this is supposed to act in this situation.  I have no idea myself.

Comment 4 cradford 2001-09-10 14:46:39 UTC
Point of note: It appears that the network driver/card I am using 
(8139too/RTL8139B) misbehaves when compiled into the kernel and connected to a 
10BaseT hub. It appears not to receive all packets on the wire. This does not 
appear to happen when connected to a 100BaseTX hub. I will continue to 
investigate (given time:>), and try to determine whether the fault is related 
to its unmodular nature or connection type.

Comment 5 cradford 2001-09-18 10:43:04 UTC
Further testing has revealed that 8139too/RTL8139B may be the whole cause of 
the problem. Initialisation of the ( in different PC's, with different network 
layers, not even dhcp ) card has failed, without the driver noticing/error 
reporting. This failure is only apparent by the absence of the "link present" 
light on the hub(s). On other occasions the network card appears to be able to 
transmit but not receive !?!

Presumably etherboot is initialising the network card differently from 8139too, 
and that is why it never appears to fail.

Suggest change of bug from "dhcp" to "8139too"

Comment 6 Jeff Garzik 2003-01-31 16:25:32 UTC
Can we confirm this problem still occurs on Red Hat 8.0,
or occurs in 7.x with the latest kernel errata rpm installed?

Comment 7 Alan Cox 2003-06-06 17:50:02 UTC
No reply in months, closed

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