Bug 2387 - pump not may not be sending proper DHCPREQUEST message
Summary: pump not may not be sending proper DHCPREQUEST message
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: dhcp
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
: 2558 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 1999-04-27 19:36 UTC by tek
Modified: 2008-05-01 15:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-06-11 19:42:25 UTC

Attachments (Terms of Use)

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

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, but in fact it should be (dhcpclient gets
it right, however.)  My IP address falls in class B (it is
130.132.53.x) iirc, so 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, when my server should be telling it it's really 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 mjp@itg.net  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.

Comment 6 David Lawrence 1999-06-11 19:42:59 UTC
These have hopefully been fixed the in the latest errata release of
pump located at ftp://updates.redhat.com/6.0/i386. Please obtain and
install and reopen this report of the problem still occurs.

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