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. :)
This has been assigned to a developer for further review.
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.
Well, couldn't you take a look at the dhcpcd source and "borrow" (read: steal) their -h functionality?
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 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x7028a3c vend-rfc1048 T53:1 T57:9218 T55:201720577,673848335 HN:"cc817150-a" T60:76.105.110.117.120.32.50.46.48.46.51.54.32.105.54.56.54 T61:1.0.144.39.18.214.18 Windows 95 sends something similar. However pump-0.6.4 on RH 6.0 sends the following: 3:04:08.133274 0.0.0.0.bootpc > 255.255.255.255.bootps: 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 parameters.
I'd just like to chime in that I'm also willing to do the testing on the @Home Network.
This is fixed in the errata release.
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 smoothly. --- The latest version of DHCPCD can be found here: http://www.phystech.com/download/ or http://www.phystech.com/ftp/dhcpcd-1.3.17-pl9.tar.gz or (if you prefer FTP) ftp://ftp.phystech.com/pub/dhcpcd-1.3.17-pl9.tar.gz 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 !! Nick...
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 results. ------- 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)
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)
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.
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.