Red Hat Bugzilla – Bug 52385
[8139too] kernel IP autoconfig dhcp request fails
Last modified: 2013-07-02 22:05:10 EDT
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 )
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
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.
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.
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.
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.
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.
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"
Can we confirm this problem still occurs on Red Hat 8.0,
or occurs in 7.x with the latest kernel errata rpm installed?
No reply in months, closed