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 roswell) How reproducible: Always 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. 3. Actual Results: Infinite loop: dhcp DHCPDISCOVER packet sent, DHCPOFFER received and dropped. Expected Results: DHCPOFFER accepted! break out of loop. Additional info:
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) is. 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