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.
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).
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.
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
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.
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
(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)
(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
*** Bug 707497 has been marked as a duplicate of this bug. ***
*** Bug 708431 has been marked as a duplicate of this bug. ***
(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.
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.
(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.
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
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.
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.