Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 12002 - pump 0.7.8 and 0.7.9 won't install correct default route
pump 0.7.8 and 0.7.9 won't install correct default route
Product: Red Hat Linux
Classification: Retired
Component: pump (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Erik Troan
Depends On:
  Show dependency treegraph
Reported: 2000-06-08 18:53 EDT by Michael S. Fischer
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-12 08:12:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Red Hat Bugzilla 2000-06-08 18:53:22 EDT
pump 0.7.8 and 0.7.9 in our network configuration refuses to set up a
default route as provided by the DHCP server.

My configuration looks like this:

eth0 - back-side network (closed, no default route)
eth1 - front-side network (open, default route)

Our DHCP server is set up correctly, with no "option routers" statement on
the back-side network, and with an "option routers" statement on the
front-side network.

pump -s -i eth0 reports:

Device eth0
        Boot server
        Next server
        Boot file: /export/kickstart-2.0/ks-6.2.cfg
        Domain: auctionwatch.com
        Renewal time: Fri Jun  9 02:17:57 2000
        Expiration time: Fri Jun  9 03:47:57 2000

pump -s -i eth1 reports:

Device eth1
        Boot server
        Next server
        Gateway:   <<<<<
        Boot file: /export/kickstart-2.0/ks-6.2.cfg
        Domain: auctionwatch.com
        Renewal time: Fri Jun  9 02:17:59 2000
        Expiration time: Fri Jun  9 03:47:59 2000

But "netstat -nr" reports:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface   U         0 0          0
eth1   U         0 0          0
eth0       U         0 0          0 lo

As you can see, the default gateway is missing.

The only workaround I can do to get the default route to install is to put
an "option routers x.x.x.x" statement in the subnet definition for the
back-side network (the network eth0 is connected to).  This is (obviously)
not correct, as the back-side network has no default route, and I'm afraid
of nasty side effects.

pump did work correctly in its 0.6.4 version.
Comment 1 Red Hat Bugzilla 2000-07-26 11:35:03 EDT
For completeness, can you give some information about your dhcp server?  The
platform and OS it's running on, and any configuration info that you have would 
both be nice.

If it's running on a Linux machine, can you include your /etc/dhcpd.conf?

Comment 2 Red Hat Bugzilla 2000-07-28 16:23:03 EDT
Yes, please provide your dhcp server configuration if possible.

Comment 3 Red Hat Bugzilla 2000-07-28 17:53:38 EDT
The DHCP daemon is from the dhcp-2.0-1 RPM package.  Server is Red Hat Linux 
6.0.  'uname -a' reports:

Linux xxxxxxxx.auctionwatch.com 2.2.12-20smp #1 SMP Sun Jan 9 19:09:28 PST 2000 
i686 unknown

I'll send you the /etc/dhcpd.conf in a private email.
Comment 4 Red Hat Bugzilla 2000-08-01 09:51:55 EDT
Attempting to reprocude bug internally.
Comment 5 Red Hat Bugzilla 2000-08-02 16:44:20 EDT
I have reproduced this bug internally and have verified that pump does not set a
default route on eth1, I am assuming it will not set a default route on anything
but eth0. I also tested this by changing the dhcpd.conf file and moving the
option routers x.x.x.x; line to the config area for the mac address of the eth0
device and the default route was indeed set. Temporary fix for this would be to
change the roles of your ethernet devices by changing the dhcpd config for eth0
to eth1 and vice versa so that eth0 takes the gateway required for
Comment 6 Red Hat Bugzilla 2000-08-02 17:41:11 EDT
This is not an acceptable temporary workaround--I already explained why in the 
initial bug report.  To be more clear, the kickstart server is on the protected 
gatewayless network.  Kickstart can only use eth0 during installation.  We do 
not wish to change the network configuration and switch cables around after 
kickstart is completed.
Comment 7 Red Hat Bugzilla 2000-08-04 15:34:37 EDT
There's a new package of pump that we're testing, will give more details after
we've done initial verification.
Comment 8 Red Hat Bugzilla 2000-08-04 16:01:02 EDT
There's a new version of pump, residing in


Try that, and update this bug report after you've done so.
Comment 9 Red Hat Bugzilla 2000-08-07 17:16:38 EDT
Sorry, 0.8.1 doesn't fix the problem.  Problem remains.
Comment 10 Red Hat Bugzilla 2000-08-07 17:34:14 EDT
Are the symptoms identical?  If not, how do they change?
Comment 11 Red Hat Bugzilla 2000-08-07 17:41:01 EDT
Could you put a debug syslog in pumpSetupDefaultGateway() which gets triggered
if the
ioctl fails? Something like:

	syslog(LOG_INFO, "GW ioctl failed: %s", strerror(errno))

should do the trick. See if that shows up in syslog.
Comment 12 Red Hat Bugzilla 2000-08-07 19:21:21 EDT
Brian, the symptoms are exactly the same.  Same "pump -s -i eth1" output, no 
default route assigned.

I don't have the SRPM for 0.8.1, so someone will have to make a new build for 
Comment 13 Red Hat Bugzilla 2000-08-08 09:28:15 EDT
I think I found it. Please try:


and let us know if that works for you.
Comment 14 Red Hat Bugzilla 2000-08-08 14:26:07 EDT
I can't get this to make:

cc -I. -Wall -g  -D__STANDALONE__ -DVERSION=\"0.8.2\"   -c -o pump.o pump.c
pump.c: In function `runDaemon':
pump.c:449: incompatible types in assignment
make: *** [pump.o] Error 1
Comment 15 Red Hat Bugzilla 2000-08-12 08:12:28 EDT
In runDaemon(), intf is not an Lvalue.
Replace line 332: struct pumpNetIntf intf[20];
by:               struct pumpNetIntf *intf;
and insert an alloca() a few lines after.

PS (to Erik): what is your C compiler?
Comment 16 Red Hat Bugzilla 2000-10-04 18:12:51 EDT
The version of pump included in Guinness appears to have solved this issue. 
Thanks to all.

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