Bug 109601

Summary: /etc/init.d/network does not correctly handle xDSL connections
Product: [Fedora] Fedora Reporter: Josi Romildo Malaquias <romildo>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 1CC: prata, redhat, robatino, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 7.43-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-11-10 22:50:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to fix this
none
patch, take 2 none

Description Josi Romildo Malaquias 2003-11-10 00:51:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031030

Description of problem:
To start up a xDSL connection, the script /etc/init.d/network calls
ifup with the device name of the connection as its argument (ppp0 in
my case), requiring the existence of a file named ifup-<device>
(ifup-ppp0 in my case) in the /etc/sysconfig/network-scripts
directory. But the internet-druid program, used to set up the
connection, creates a file ifup-<proavider name>, named after the
provider name (ifup-NetSuper in my case). As a consequence, the script
fails to bring up the connection.

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


How reproducible:
Always

Steps to Reproduce:
1. Configure a xDSL connection with internet-druid, setting the
provider name to NetSuper, lets say. Also sets the connection to start
at initialization time.
2. 
3.
    

Actual Results:  At initialization time /etc/init.d/network fails to
start the connection, with a message saying that ifup did not find the
configuration file for the DEVICE used in the connection.

Expected Results:  The connection should be successfully stablished.

Additional info:

Making a symbolic link from
/etc/sysconfig/network-scripts/ifcfg-<provider name> to
/etc/sysconfig/network-scripts/ifcfg-<device name> solves the problem,
but then the connection is started twice (and the second time the
script fails because the connection is already up).

Comment 1 Andre Robatino 2003-11-10 05:14:39 UTC
  This is the same as bug #109411 and bug #108033.  I applied the
patch provided in the bug #109411 bug report and it fixed it for me
(and the original reporter).

Comment 2 Bill Nottingham 2003-11-10 17:07:10 UTC
*** Bug 109411 has been marked as a duplicate of this bug. ***

Comment 3 Bill Nottingham 2003-11-10 17:07:22 UTC
*** Bug 108033 has been marked as a duplicate of this bug. ***

Comment 4 Bill Nottingham 2003-11-10 17:08:07 UTC
Created attachment 95879 [details]
patch to fix this

Try the attached; it's a little more generic than the patch in the other bugs.

Comment 5 Andre Robatino 2003-11-10 20:12:56 UTC
  Same result as with the patch in bug #109411 - works perfectly on
startup, but on shutdown there is no message

Shutting down interface [xdsl interface name] :

as there should be.

Comment 6 Bill Nottingham 2003-11-10 20:58:02 UTC
Created attachment 95888 [details]
patch, take 2

This should fix one of the obvious ways that the ifdown step would get skipped.
Use this instead of the previous patch.

Comment 7 Andre Robatino 2003-11-10 22:46:03 UTC
  I patched and rebooted.  It shut down the interface properly on
shutdown, and brought it up properly on startup.  I think it's fixed.

Comment 8 Bill Nottingham 2003-11-10 22:50:21 UTC
Fixed in CVS, will be in 7.43-1.

Comment 9 Andre Robatino 2003-11-13 17:29:20 UTC
  You might want to take another look at the patch.  The last time I
shutdown, I saw two identical shutdown messages for the xdsl
interface, the first succeeded and the second failed (since the
interface was already down).  This is the first time out of several
shutdowns where it happened.

Comment 10 Harald Hoyer 2003-11-25 15:22:40 UTC
*** Bug 109884 has been marked as a duplicate of this bug. ***

Comment 11 Jef Spaleta 2004-02-02 17:15:23 UTC
*** Bug 109607 has been marked as a duplicate of this bug. ***