Bug 55404 - netcfg does not apend new network configuration
netcfg does not apend new network configuration
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: netcfg (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
:
: 56445 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-30 15:48 EST by Phil Terrett
Modified: 2007-04-18 12:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 13:13:30 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)

  None (edit)
Description Phil Terrett 2001-10-30 15:48:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
When attempting to apply the new settings, netcfg would not apend the new 
configuration to ifcg-eth0.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Ran netcfg to configure for network settings
2.Installed IP address information
3.Checked apply and restarted networking using /etc/rc.d/init.d/network 
restart command
Networking regained with old IP address settings, attempted to reboot 
wkstn had to use ctrl-alt-del keyset to reboot system.
	

Additional info:
Comment 1 Need Real Name 2001-11-12 13:05:17 EST
It looks like the new configuration does get added wether you use
linuxconf
netconfig
or neat.
The problem seems to be in ifdown because after changing an ip address on an 
interface the command:    ip addr  
shows both the old and new addresses assigned to the interface.  It appears that
ifdown when called by network restart is using the new ip address and not the old, 
so therefore both the new and old addresses are assigned to the interface.

A work around for this problem is to first issue ifdown on the interface before 
changing it. The old ip address will be removed. Then change it with whatever 
command and do a network restart. (no re-boot is then necessary).

It appears that ifdown should look for the ifconfig??.old and down it first ??

Earl 

Comment 2 Werner Puschitz 2001-11-22 03:16:47 EST
I attached a patch for this problem. But first I would like to explain what
exactly happens here - the network can get messed up pretty bad when the server
is suddenly responding to multiple IP addresses. I'm using eth0 as an example
here:


-- Comment: eth0 is up and running

# ifconfig
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:210.210.210.20  Bcast:210.210.210.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1285 errors:0 dropped:0 overruns:0 frame:0
          TX packets:901 errors:0 dropped:0 overruns:0 carrier:0
          collisions:6
          RX bytes:121535 (118.6 Kb)  TX bytes:81329 (79.4 Kb)

# ip addr ls eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 210.210.210.20/24 brd 210.210.210.255 scope global eth0
#


-- Comment: Now I change IPADDR in "ifcfg-eth0" to 210.210.210.99

# service network stop
Shutting down interface eth0:                              [  OK  ]
#

-- Comment: 210.210.210.20/24 is still showing up:

# ip addr ls eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 210.210.210.20/24 brd 210.210.210.255 scope global eth0
#


# service network start
Setting network parameters:                                [  OK  ]
Bringing up interface lo:                                  [  OK  ]
Bringing up interface eth0:                                [  OK  ]
#


-- Comment: Now 210.210.210.20 is showing up again instead of 210.210.210.99 

# ifconfig
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:210.210.210.20  Bcast:210.210.210.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1285 errors:0 dropped:0 overruns:0 frame:0
          TX packets:909 errors:0 dropped:0 overruns:0 carrier:0
          collisions:6
          RX bytes:121535 (118.6 Kb)  TX bytes:81665 (79.7 Kb)


-- Comment: 210.210.210.20 is showing up because inet 210.210.210.20/24 was not
removed by "ifdown", and the server is now responding to *both* IP addresses!

# ip addr ls eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 210.210.210.20/24 brd 210.210.210.255 scope global eth0
    inet 210.210.210.99/24 brd 210.210.210.255 scope global secondary eth0
#


Here is my suggested patch where "ifup" simply copies "ifcfg-eth0" to
"ifcfg-eth0.current" which will be used later by "ifdown" to get always the
current/correct IPADDR.

=========================

--- ifup.old    Thu Nov 22 02:09:05 2001
+++ ifup        Thu Nov 22 02:11:40 2001
@@ -36,6 +36,9 @@
     exit 1
 }

+echo "#Do NOT edit this file!" > ${CONFIG}.current
+cat ${CONFIG} >> ${CONFIG}.current
+
 if [ ${UID} != 0 ]; then
     if[ -x /usr/sbin/usernetctl ]; then
        if /usr/sbin/usernetctl ${CONFIG} report ; then

=========================

--- ifdown.old  Thu Nov 22 02:08:36 2001
+++ ifdown      Thu Nov 22 02:08:54 2001
@@ -30,6 +30,10 @@
     exit 1
 fi

+[ -f "$CONFIG".current ] && {
+    CONFIG=$CONFIG.current
+}
+
 source_config

 if [ -x /sbin/ifdown-pre-local ]; then

=========================


Regards,
Werner


Comment 3 Werner Puschitz 2001-11-22 12:52:50 EST
I forgot to provide one more detail. In line 86 in
/etc/sysconfig/network-scripts/ifdown, 
the script executes the following command:
ip addr del ${IPADDR}/${PREFIX} brd ${BROADCAST:-+} dev ${REALDEVICE}

For eth0, the variable $IPADDR gets set through
/etc/sysconfig/network-scripts/ifcfg-eth0
which means "ifdown" is trying to remove the wrong $IPADDR when "ifcfg-eth0" was
changed
before "ifdown" gets executed. This is exactly leading to our problem. It helps
when "ifup" saves
$IPADDR in "ifcfg-eth0.current" so that "if-down" can get later the current
$IPADDR. 

I'm not sure if the approach of simply removing all eth0 entries instead of
using a "current" file
is a good idea when you do IP aliasing.

Regards,
Werner
Comment 4 Phil Knirsch 2002-02-24 12:22:05 EST
*** Bug 56445 has been marked as a duplicate of this bug. ***
Comment 5 Bill Nottingham 2006-08-07 15:54:52 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Comment 6 Bill Nottingham 2006-10-18 13:13:30 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

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