|Summary:||pump not may not be sending proper DHCPREQUEST message|
|Product:||[Retired] Red Hat Linux||Reporter:||tek|
|Component:||dhcp||Assignee:||David Lawrence <dkl>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||6.0||CC:||flosofl, gadown, tek|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-06-11 19:42:25 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description tek 1999-04-27 19:36:41 UTC
We're using the Carnegie Mellon DHCPd server, version 3.3.7. We're finding that when pump sends a DHCPREQUEST to our server, it doesn't include any ReqOpt's. So in response, our server doesn't give it any opts in return (nameserver (NS), designated gateway (DG), subnet mask (SM), etc.). This wasn't a problem in RH 5.2 when we were using dhcpcd. dhcpcd would send ReqOpts of SM, DG, NS, HN, DN, BA, NT, YD in its DHCPREQUEST and our server would then respond in kind in its DHCPACK. pump doesn't send any ReqOpts in it's DHCPREQUEST.
Comment 1 david.ogilvie 1999-04-28 07:02:59 UTC
I haven't tracked down if the problem is the exact same as this message, but pump is configuring the wrong netmask for my computer (as reported by pump -i eth0 --status.) It claims that the netmask is 255.255.0.0, but in fact it should be 255.255.255.0 (dhcpclient gets it right, however.) My IP address falls in class B (it is 130.132.53.x) iirc, so 255.255.0.0 is the (incorrect) default (If I remember all that IP nonsense correctly.)
Comment 2 tek 1999-04-28 15:33:59 UTC
Concerning David's comments: YES!, I think this is directly related to the problem I'm seeing. pump wouldn't give me the proper subnet mask either (would give me 255.255.0.0, when my server should be telling it it's really 255.255.252.0). It also wouldn't get the gateway address either. Like I said in my previous message, running tcpdump on the traffic shows that pump isn't even *asking* for things like netmask and gateway. In fact, it doesn't really seem to be asking for anything. So of course, our server doesn't tell it anything.
Comment 3 tek 1999-04-30 04:04:59 UTC
Okay, I read the DHCP spec (RFC 2131) and it says that the client MAY send the a request for parameters in the DHCPDISCOVER message. (but doesn't have to) In return, the server MUST send all the options available in the DHCPOFFER. The author of our server was actually aware of this and noted that if we added a special entry to our bootptab then all the options would be offered regardless in the DHCPOFFER. So we did that and pump works perfectly now. Summary: bug on our end.
Comment 4 gadown 1999-05-07 15:38:59 UTC
I've noticed that after upgrading to RH6 from 5.2 my dhcp doesn't work correctly. It seems to be missing info such as dns. If it worked in 5.2 WHY change it in 6.0. At this point I had to hardcord dns information in resolv.conf to make things work correctly. I shouldn't have to do that.
Comment 5 Dale Lovelace 1999-06-04 16:02:59 UTC
*** Bug 2558 has been marked as a duplicate of this bug. *** DHCP Client is not initializing correctly. I have tested it in 5.2 and 6.0. 5.2 works. I have tried the old version of dhcpcd with the 6.0 and it still does not work. I can ping my local subnet and nothing else ------- Additional Comments From email@example.com 05/12/99 12:27 ------- I found that on my systems the newer "pump" DHCP client grabbed the IP address fine, but didn't retrieve anything else, such as default gateway and DNS info, which made an FTP install using DHCP impossible. I ended-up having to use a static IP for the FTP install and then switch to DHCP after the install, in which I still had to manyally set my default gateway and DNS info.