Bug 143936 - network device dialog not updated after interface brought up
Summary: network device dialog not updated after interface brought up
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-network   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Whiteboard: bzcl34nup
Depends On:
Blocks: 87718
TreeView+ depends on / blocked
Reported: 2005-01-01 23:23 UTC by A. Folger
Modified: 2008-05-07 00:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-07 00:04:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description A. Folger 2005-01-01 23:23:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)

Description of problem:
When activating a network interface, one expects the status to change from inactive to active, yet in my case, this doesn't happen. It already didn't happen in FC1 and FC2, FC3-test1, -2 and -3, and now FC3.

The interface in question is an isdn interface which is *not* activated at boot. Interestingly isdn services refuse to be started at boot, so that the isdn modules are only loaded once the user activates the interface for the first time after boot.

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

How reproducible:

Steps to Reproduce:
1. click network device control to start application. Also works with the "Network" program of "System Settings" (is same program, but second choice is intended for root, only, IIUC)
2. click to activate a user-activateable network interface

Actual Results:  see how the status column is not updated

Expected Results:  "inactive" changes to "active"

Additional info:

Comment 1 Matthew Miller 2006-07-10 23:18:11 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 2 A. Folger 2006-07-11 17:30:36 UTC
This problem persisted in FC4 and still persists in FC5. It doesn't need to be
fixed in FC3, but should be fixed in FC5 or at least fc6.

Kind regards

Comment 3 Matthew Miller 2006-07-11 17:43:33 UTC

Comment 4 A. Folger 2006-10-31 18:07:26 UTC
The problem persists in FC5 and FC6

Comment 5 A. Folger 2006-10-31 18:08:49 UTC
Oops, correction: the problem only persists when activating an isdn interface,
however, the eth interfaces are handled correctly.

Comment 6 Bug Zapper 2008-04-03 15:47:40 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 7 Bug Zapper 2008-05-07 00:04:29 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:

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