Bug 2477 - Not dhcpcd, but pump problem. Cannot support -h option.
Summary: Not dhcpcd, but pump problem. Cannot support -h option.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pump
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Erik Troan
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-05-01 22:28 UTC by Ross Williams
Modified: 2008-05-01 15:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-02-15 17:20:33 UTC

Attachments (Terms of Use)

Description Ross Williams 1999-05-01 22:28:14 UTC
The pump command does not support the -h option that the
dhcpcd command does. Thus, it is unusable on my network, the
@Home Network. Please advise me of the fix or a fix. :)

Comment 1 David Lawrence 1999-05-02 19:31:59 UTC
This has been assigned to a developer for further review.

Comment 2 Erik Troan 1999-06-02 20:31:59 UTC
This is a pump problem, and we don't have access to facilities to
test this, unfortunately. We're very interested in finding out
more information, however.

Comment 3 ryants 1999-06-03 03:11:59 UTC
Well, couldn't you take a look at the dhcpcd source and "borrow"
(read: steal) their -h functionality?

Comment 4 hecker 1999-06-15 13:07:59 UTC
I would be glad to test any pump changes that would better support
DHCP on @Home connections.  I have an existing RH 5.2 system on @Home
successfully using dhcpcd-0.70-2 with the -h option (/sbin/dhcpcd -h
foo).  I have a second dual-boot system (laptop) with Windows 95 and
RH 6.0; the system can do DHCP successfully on @Home under Windows 95,
as well as on my office LAN under both Win95 and RH 6.0, but cannot do
DHCP on @Home under RH 6.0.  With RH 6.0 and @Home pump-0.6.4 does not
work (because it does not support the -h option properly), but also
dhcpcd-1.3.17-pl2 (using -h) doesn't work either for some reason.

For a complete set of tcpdump runs please see
<http://www.hecker.org/misc/dhcp-athome/>.  Note that dhcpcd-0.70-2 on
RH 5.2 (using the -h option) sends the following packet when
requesting a DHCP lease from @Home:

11:32:06.023274 > xid:0x7028a3c
vend-rfc1048 T53:1 T57:9218 T55:201720577,673848335 HN:"cc817150-a"

Windows 95 sends something similar.  However pump-0.6.4 on RH 6.0
sends the following:

3:04:08.133274 > xid:0x340f1c07
vend-rfc1048 T53:1

This will not work on @Home because the request does not include the
hostname.  (pump sends this several times, receives no response from
@Home, and then times out.)

dhcpcd-1.3.17-pl2 on RH 6.0 (using the -h option) appears to send the
right thing (eventually), and even gets a response from @Home, but for
some reason does not end up setting the IP address and other

Comment 5 Ross Williams 1999-06-15 13:21:59 UTC
I'd just like to chime in that I'm also willing to do the testing on
the @Home Network.

Comment 6 Bill Nottingham 1999-08-31 22:24:59 UTC
This is fixed in the errata release.

Comment 7 nick34 1999-09-12 21:13:59 UTC
The latest version of pump (0.7.0-1) still doesn't work with @Home's
DHCP server (not for me that is ;)).

The stock version op DHCPCD (1.3.17-pl2) also didn't work with
@Home's DHCP server.

After upgrading DHCPCD to version 1.3.17-pl9 everything works


The latest version of DHCPCD can be found here:
or (if you prefer FTP)

To install this version make sure you have a file named "dhcpcd"
located in your "/sbin" directory, or the installation will fail. You
may ofcourse also do a "touch /sbin/dhcpcd" :)

1) extract the dhcpcd daemon (tar -xzf dhcpcd-1.3.17-pl9.tar.gz)
2) make
3) make install

4) <optional> remove dhcpcd.old from your "/sbin" directory

Good luck !!


Comment 8 steve 1999-10-19 16:01:59 UTC
Even after applying the pump (pump-0.7.0-1), I still cannot connect to
cox@home in Oklahoma City using pump, although dhcpcd works fine.  As
noted previously, this system does require that a hostname be sent,
but "pump -i eth0 -h myhostname" never gets a response back from the
dhcp server.  I have also tried the pump from RH6.1 with the same

------- Additional Comments From   10/19/99 12:55 -------
Just another data point, the ISC DHCP client (2.0) works perfectly,
but pump from 6.1 as well as the dhcpcd from 6.1 don't. Is there a
reason not the use the ISC client? (I guess one downside may be that
it needs more configuration). It's the "reference", so it should work
in any DHCP setup.  (this is with @home as well)

Comment 9 edwinh 1999-10-19 16:55:59 UTC
Just another data point, the ISC DHCP client (2.0) works perfectly,
but pump from 6.1 as well as the dhcpcd from 6.1 don't. Is there a
reason not the use the ISC client? (I guess one downside may be that
it needs more configuration). It's the "reference", so it should work
in any DHCP setup.  (this is with @home as well)

Comment 10 gadown 2000-02-08 23:55:59 UTC
I have also discovered the same @home problem.  We have two available @home
providers here in Ontario.  One is from Shaw@Home the other Rogers@Home.  When
I use Shaw@Home with the errata version of pump (for RedHat 6.0) everything
seems to work fine.  When I use Rogers@Home with the errata version of pump it
fails.  I enabled debug in syslog to see what pump was doing.  I noticed with
Shaw the vendor information is returned but with Rogers there is no vendor
information returned.  After some analysis I discovered that shaw does not
require a host name (hence does not need the -h parm of pump) while rogers
does.  The only way to get rogers to work correctly was to use dhcpcd with the -
h parm.  SO there must be a bug in pump-0.7.0-1.  When will this be fixed.

Also why was pump even created.  It appears that dhcpcd worked correctly so why
replace it.  Second, if you did plan on replacing it why did you not use
dhcpcd's source as a basis for pump and hence eliminate many of the problems
that might have occurred.  As a developer the fact that the -h parm is ignore
is a good indication of the quality and quantity of testing that you do.

Comment 11 Erik Troan 2000-02-15 17:16:59 UTC
This is fixed in pump-0.7.7, which will be available from
ftp://people.redhat.com/ewt/ later this afternoon.

Please reopen this bug if you continue to have prolems.

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