Bug 704119 - [network] Can't edit connections when device is off
[network] Can't edit connections when device is off
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: control-center (Show other bugs)
19
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Control Center Maintainer
Fedora Extras Quality Assurance
CommonBugs
:
: 707497 708431 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-12 04:22 EDT by Francesco Tapparo
Modified: 2015-02-17 08:44 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 08:44:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Francesco Tapparo 2011-05-12 04:22:55 EDT
Description of problem:


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

How reproducible:
One cannot use NetworkManager to configure a unconfigured network device. I have an ethernet port connected to another pc, so there is no a dhcp server in that network. It would suffice to click on "impostazioni" (I guess "settings" in english) and set em1 to manual mode, but I'm not able to do it because the device never reach the activated state: I first have to click on it to "on" on network-manager and wait that it becomes activated but this never happens because after a while of course NetworkManager renounces to activate the device(of course because there is no dhcp server). 
I activated the device with system-config-network and NetworkManager activated the device without any problem. I was not sure about the severity, but I decided to set it "high" because this bug effectively removes functionality that was present in fedora 14. Similar problems could happen every time some tweakings are necessary before device activation.
Comment 1 Jirka Klimes 2011-05-13 04:37:45 EDT
Actually, this is by design that you can edit the connection only when activated, because when it's not active you don't know what profile to edit.

However, you can use nm-connection-editor (from terminal) or Applications->Other->Network Connections (Gnome shell) to edit any profile. Find and edit your profile in 'Wired' tab (probably called 'System em1).
Comment 2 Radek Vykydal 2011-05-19 03:50:14 EDT
I am exploring possibility of integration of gnome-control-center into Anaconda installer and this is one of the issues that we'd need to address. In Anaconda we want to configure also devices we don't activate, ideally from single UI entry point - the control center in this case. In installer there would be single profile per device so we would be fine with just taking the first profile, but I understand that this is not the case for desktop. How about these options:

A) Enable the Options button also in case when there is no active connection, but just single profile (connection) is found for the device. That should satisfy our needs and I think it can be acceptable also for desktop.

or:

B) In case of disconnected device run nm-connection-editor for Options button. This is probably not good from UX point of view, perhaps there could be additional UI element (e.g. button) for running nm-connection-editor in network panel.

I am willing to make patches.
Comment 3 Tore Anderson 2011-05-21 07:18:46 EDT
This is a gross regression in usability.

Unless you're aware of the «back door» ways of configuring the network, you'll be left completely unable to connect to any network that requires settings other than the defaults. And if you have no network connection, it's not like you can Google for the solution, either. It's a classic catch-22 - you would need to connect to the network in order to change the settings necessary to to be able connect to the network in the first place.

It's not limited to when using static IPv4 configuration, I ran across this problem when attempting to connect F15 beta to an IPv6-only network, and needed to de-select to the «require IPv4 addressing for this connection to complete» in order to successfully connect to the network (see bug #538499).

Tore
Comment 4 cornel panceac 2011-05-24 05:12:14 EDT
It seems more intuitive to configure networks from the applet. Also, if the option is there but is deactivated, you may start thinking that the network hardware was actually not detected. Leaving "Network settings" always available should be the way to go.
Comment 5 Adam Williamson 2011-05-24 11:06:54 EDT
We should probably have a commonbugs note for this, but I'm not entirely sure how to phrase it, or what workarounds there are. If you need a static config for your wired ethernet, does it work to first turn it 'on' - even though it'll try and use DHCP and fail - and then do Network Settings while it's failing? Or do you have to use the nm-c-e workaround? Can anyone affected by this provide more details? thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Radek Vykydal 2011-05-24 11:21:34 EDT
(In reply to comment #5)
> We should probably have a commonbugs note for this, but I'm not entirely sure
> how to phrase it, or what workarounds there are. If you need a static config
> for your wired ethernet, does it work to first turn it 'on' - even though it'll
> try and use DHCP and fail - and then do Network Settings while it's failing? Or
> do you have to use the nm-c-e workaround? Can anyone affected by this provide
> more details? thanks!
> 

        /* set up options button */
        wid_name = g_strdup_printf ("button_%s_options", page_name);
        widget = GTK_WIDGET (gtk_builder_get_object (panel->priv->builder, wid_name));
        g_free (wid_name);
        if (widget != NULL) {
                gtk_widget_set_sensitive (widget, state == NM_DEVICE_STATE_ACTIVATED);
        }

(gnome-control-center/panels/network/cc-network-panel.c)
Comment 7 Tore Anderson 2011-05-24 14:02:59 EDT
(In reply to comment #5)
> We should probably have a commonbugs note for this, but I'm not entirely sure
> how to phrase it, or what workarounds there are. If you need a static config
> for your wired ethernet, does it work to first turn it 'on' - even though it'll
> try and use DHCP and fail - and then do Network Settings while it's failing?

No, the button for changing the settings remains «grayed out» while the connection attempt is in progress. I haven't tried F15 final yet, but I guess the nm-c-e workaround would be necessary in this case, yes.

Tore
Comment 8 Jirka Klimes 2011-05-25 07:58:22 EDT
*** Bug 707497 has been marked as a duplicate of this bug. ***
Comment 9 Jirka Klimes 2011-05-30 16:38:29 EDT
*** Bug 708431 has been marked as a duplicate of this bug. ***
Comment 10 killerman.ravi 2011-05-31 11:42:47 EDT
(In reply to comment #7)
> (In reply to comment #5)
> > We should probably have a commonbugs note for this, but I'm not entirely sure
> > how to phrase it, or what workarounds there are. If you need a static config
> > for your wired ethernet, does it work to first turn it 'on' - even though it'll
> > try and use DHCP and fail - and then do Network Settings while it's failing?
> 
> No, the button for changing the settings remains «grayed out» while the
> connection attempt is in progress. I haven't tried F15 final yet, but I guess
> the nm-c-e workaround would be necessary in this case, yes.
> 
> Tore

It is just as you put it. The "Options" button is grayed out after we make any changes in the Network Manager applet - which should never happen. The workaround namely opening nm-connection editor and undoing the changes do enable the "Options" button in Network Manager applet though. And everything is back to normal once again.
Comment 11 Seppo Yli-Olli 2011-08-28 18:27:21 EDT
Yes, this is indeed an issue with final Fedora 15 as well.
Real user story: No network connectivity whatsoever. Went check network configurations: noticed that network is getting all necessary addresses for network but still bailing out for some reason, repeatedly. (without telling what is going wrong) Then started wondering why the properties is gray. Assumed it has to do with Fedora's security systems (ie some change which would require me to fix my user account). After spending days searching for ways to elevate user privileges finally after asking on #fedora realize that it's mandatory to use nm-c-e to even find out what's wrong and finally fix the problem. And yes, figured out later dmesg would also have hinted what the problem was but since the problem was unfixable without nm-c-e, this wouldn't have been use anyhow. 

While it may sound drastic, I personally think this should have been a release blocker for Fedora 15 and definitely should be a release blocker for Fedora 16 if this hasn't yet been fixed for branched.
Comment 12 Seppo Yli-Olli 2011-08-28 18:30:50 EDT
(In reply to comment #11)
> finally fix the problem
Pardon previous: fix to the problem was disabling IPv6 being mandatory for connecting. I had previously had connectivity and had forgotten it on.
Comment 13 Fedora End Of Life 2013-04-03 10:13:45 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 14 Fedora End Of Life 2015-01-09 11:39:48 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 15 Fedora End Of Life 2015-02-17 08:44:58 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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