Bug 133575 - GATEWAYDEV directive ignored...
GATEWAYDEV directive ignored...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks: 132991
  Show dependency treegraph
 
Reported: 2004-09-24 17:05 EDT by Johnray Fuller
Modified: 2014-03-16 22:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-18 11:35:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
use 'dev $GATEWAYDEV' if $GATEWAYDEV is set. (861 bytes, patch)
2004-10-18 11:25 EDT, Pekka Savola
no flags Details | Diff

  None (edit)
Description Johnray Fuller 2004-09-24 17:05:27 EDT
On a system with two active NICs (eth0 & eth2), I configured the
second NIC to e the gateway device. However, it seems to begetting
ignored.

# rpm -q initscripts
initscripts-7.31.16.EL-1

# cat /etc/sysconfig/network
HOSTNAME=homocorrectus.mine.nu
NETWORKING=yes
GATEWAY=172.31.0.1
GATEWAYDEV=eth2

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
PEERDNS=no
NETMASK=255.255.255.0
IPADDR=172.31.0.110

# cat /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE=eth2
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
PEERDNS=no
NETMASK=255.255.255.0
IPADDR=172.31.0.112

# service network restart

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface
172.31.0.0      *               255.255.255.0   U     0      0       
0 eth0
172.31.0.0      *               255.255.255.0   U     0      0       
0 eth2
169.254.0.0     *               255.255.0.0     U     0      0       
0 eth2
default         172.31.0.1      0.0.0.0         UG    0      0       
0 eth0

Note the default device is still eth2.

J
Comment 1 Johnray Fuller 2004-09-24 17:07:25 EDT
s/still eth2/not eth2
Comment 2 Pekka Savola 2004-10-17 06:57:53 EDT
You've funkily set up IP prefixes for the interfaces, they overlap; I 
guess that's causing the problems, because the default gateway is 
reachable through the first interface which was brought up (eth0).

Do you have interface aliases or static routes?  Aliases might be 
causing a problem through legacy code in ifup-aliases.

I've looked at the code in CVS and RHL9, and it SHOULD be working even 
though it's funky, unless you have aliases (in which case the failures 
might be explainable).

If that's not the case, I guess the only thing you could do is add 
some debugging log messages e.g. using /usr/bin/logger in ifup around 
GATEWAY to figure out where the gateway gets added and using what 
parameters, and go from there.
Comment 3 Eric Paris 2004-10-18 11:00:38 EDT
# Set a default route.
    if [ -z "${GATEWAYDEV}" -o "${GATEWAYDEV}" = "${REALDEVICE}" ]; then
        # set up default gateway. replace if one already exists
        if [ -n "${GATEWAY}" -a "`ipcalc --network ${GATEWAY}
${NETMASK} 2>/dev/null`" = "NETWORK=${NETWORK}" ]; then
            ip route replace default via ${GATEWAY} ${WINDOW:+window
$WINDOW} ${SRC}
        elif [ "${GATEWAYDEV}" = "${DEVICE}" ]; then
            ip route replace default ${SRC} ${WINDOW:+window $WINDOW}
dev ${REALDEVICE}
        fi
    fi


This is the code in question, notice that the first route statement
does not specify the device.  Since we do have aliases and the dummy
alias is up and it is allowed to pick any interface it wants we can
see this makes sense.  But, it is not right.  There needs to be a
nested if which checks if the gatewaydev is set and then uses the "dev
${REALDEVICE} in the first if block if it is set, and uses the
statement as it stands if not.
Comment 4 Pekka Savola 2004-10-18 11:23:09 EDT
Right.  I was looking at the code real hard, but I didn't notice that 
the first ip route didn't specify the interface.

I guess a patch like attached would fix this? (untested)
Comment 5 Pekka Savola 2004-10-18 11:25:38 EDT
Created attachment 105384 [details]
use 'dev $GATEWAYDEV' if $GATEWAYDEV is set.
Comment 6 Bill Nottingham 2004-10-18 12:10:50 EDT
The entire stanza is wrapped in -z "$GATEWAYDEV" - I don't think that
will work.
Comment 7 Pekka Savola 2004-10-18 12:15:39 EDT
There's '-o "${GATEWAYDEV}" = "${REALDEVICE}"' as well which is TRUE 
-- the route will be added when REALDEVICE is eth2 (==GATEWAYDEV), so 
it should work.
Comment 8 Bill Nottingham 2004-10-18 12:18:06 EDT
In that case, should the order of the tests just be reversed?
Comment 9 Pekka Savola 2004-10-18 12:23:16 EDT
If you refer to the -z $GATEWAYDEV ... line, I guess it won't matter 
except as an optiomization.

If you refer to the following if/elif tests, it wouldn't work (without 
changes) because the elif just adds the route to point at the device 
(weird stuff?!!), doesn't specify the next-hop..

The only reason I can think of why the elif statement is like it is is 
if it was originally thought that GATEWAYDEV would only be used with 
point-to-point interfaces that don't need GATEWAY..
Comment 10 Bill Nottingham 2004-10-18 12:37:07 EDT
Added, will be in 7.31.19.EL-1 (and various other releases on various
other branches.)
Comment 11 Eric Paris 2004-10-18 13:11:57 EDT
Patch doesn't look right to me.  Don't you have to have a + in there?
 Right that patch isn't valid and I thnk will bust the ifup.

should be   ${GATEWAYDEV:+dev $GATEWAYDEV}
Comment 13 Pekka Savola 2004-10-18 13:54:45 EDT
True, the + sign was missing.  As said, it was untested ;-).  Thanks 
for the good eyes.
Comment 16 John Flanagan 2004-12-13 15:31:44 EST
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-619.html
Comment 17 Tim Powers 2005-05-18 11:35:57 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-123.html

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