Description of problem: When attempting to set up bridge via the Gnome 3 gui, only result is failure and borkage of existing network. How reproducible: Always Steps to Reproduce: 1. In Gnome Settings network dialog, click plus sign on left side, select bridge, click add, ethernet, create, save. 2. After first attempt, I added: net.ipv4.conf.all.forwarding = 1 net.ipv4.ip_forward = 1 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 to /etc/sysctl.conf, still failure. When I attempted to remove the bridge, it killed networking alltogether. There are no error messages produced during any of this. I also set up ip forwarding in firewalld, still failure. Actual results: Failure Expected results: Bridging profit Additional info: Marking as Final blocker due to this being one of the few bits of functionality that remains in Gnome 3, as per the basic functionality must work criteria
Proposed as a Blocker for 20-final by Fedora user jdulaney using the blocker tracking app because: Default panel functionality All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.
Discussed in 2013-12-04 Blocker Review Meeting [1]. Voted as a RejectedBlocker. Non-functional bridge NetworkManager setting is not considered as essential functionality. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-04/
Below is nm-connection-editor logs when I was trying to setup bridge network using NM. Steps: I was using http://avi.alkalay.net/2014/01/fedora-20-virtualization-networkmanager-native-bridge.html to set it up. [root@localhost prkumar]# nm-connection-editor Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) Error creating proxy: The connection is closed (g-io-error-quark, 18) (nm-connection-editor:2009): dconf-WARNING **: failed to commit changes to dconf: The connection is closed (nm-connection-editor:2009): dconf-WARNING **: failed to commit changes to dconf: The connection is closed (nm-connection-editor:2009): dconf-WARNING **: failed to commit changes to dconf: The connection is closed (nm-connection-editor:2009): dconf-WARNING **: failed to commit changes to dconf: The connection is closed ~
This remains broken in F20. It's very unclear what the user is even supposed to do when presented with the current GUI. When I follow the above steps to create a bridge, I end up with a new bridge without any slave devices. In the configuration dialog Bridge tab I can click to "Add" an interface, but this ends up creating new, non-functional interfaces that aren't assigned to a physical interface, even if I select my interfaces mac addresses from the dropdown list.
(In reply to Matt Hirsch from comment #4) > This remains broken in F20. It's very unclear what the user is even supposed > to do when presented with the current GUI. When I follow the above steps to > create a bridge, I end up with a new bridge without any slave devices. In > the configuration dialog Bridge tab I can click to "Add" an interface, but > this ends up creating new, non-functional interfaces that aren't assigned to > a physical interface, even if I select my interfaces mac addresses from the > dropdown list. Clicking "Add" doesn't create a new network interface, but a connection profile for a physical interface that will act as a bridge slave. What actual problem do you have?
Here are the steps I follow: Click Network in Gnome Settings Click the Plus button in the lower left Click Bridge I see a dialog called "Editing Bridge connection 1". Next to the "Bridged Connections" panel, click the "Add" button. I expect this to add an existing interface to the bridge. A dialog appears that says "Select the type of connection you wish to create" - I want to add an ethernet connection to the bridge, so I select "Ethernet" in the dropdown. The options are "Create..." and "Cancel". I click "Create..." This opens a dialog titled "Editing bridge0 slave 1". The options are "Device MAC address", "Cloned MAC address", and "MTU". Now, as an average user, I'm pretty lost but let's try to take a guess... In the "Device MAC address" I click the dropdown arrow. I see the MAC address of my ethernet device with "(eth0)" next to it. I select it. I click "Save..." I am back in the "Editing Bridge connection 1" dialog. I click "Save..." (I'm aware I have added only one interface, but lets see if that works). I click "Save..." in the bridge dialog. Now I have a bridge. It can never establish a connection. It seems to have no interfaces connected. $ ifconfig bridge0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet6 fe80::508a:ddff:fee3:be0a prefixlen 64 scopeid 0x20<link> ether 52:8a:dd:e3:be:0a txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1 bytes 90 (90.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.182 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::2e27:d7ff:fecc:9b73 prefixlen 64 scopeid 0x20<link> ether 2c:27:d7:cc:9b:73 txqueuelen 1000 (Ethernet) RX packets 98 bytes 15198 (14.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 70 bytes 11187 (10.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 $ brctl show bridge name bridge id STP enabled interfaces bridge0 0080.000000000000 yes This method of creating bridges seems completely non-functional. I would expect that, in the bridge dialog, I can just choose from my existing wired and wireless connections. Why has it created a new name for an existing connection called "bridge0 slave 1"? And worse, why has it created a non-functional bridge?
Same problem fresh install of fedora 20 Settings -> Network -> + Create Bridge -> Bridge Tab, add Ethernet -> add mac address -> save Settings -> Network -> Wired toggle -> Off -> Bridge toggle -> On Nothing happens Bridge stay in (connecting) state and shows Bridge slaves (none) $ brctl show bridge name bridge id STP enabled interfaces bridge0 0080.000000000000 yes It would be cool if this worked. If anyone needs help testing, I'm aricg on freenode I can most likely patch/test 9-5 EDT
It is necessary to activate the slave profile. It can be done by selecting it in GUI. Or using nmcli on command-line: $ nmcli con up "bridge0 slave 1" What do you get on: $ nmcli device $ nmcli con s c $ nmcli con s a
@kirka I removed everything from the NetworkManager GUI and rm'ed the all of my ifcfg* scripts. Rebooted, re added the bridge through the gui and then issued nmcli con up "bridge0 slave 1" Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2) It's working now. thanks. $ nmcli device DEVICE TYPE STATE bridge0 bridge connected enp0s25 ethernet connected wlp3s0 wifi unavailable lo loopback unmanaged virbr0-nic tap unmanaged $ nmcli con s c NAME UUID TYPE TIMESTAMP-REAL eth0 7445c8aa-0c87-402e-981c-041a5a9dcc33 802-3-ethernet Tue 27 May 2014 02:41:06 PM EDT Bridge connection 1 e169fa95-b104-41f1-8d67-66fffad3eb00 bridge Tue 27 May 2014 02:49:34 PM EDT bridge0 slave 1 75b99588-1b9f-4720-89e1-4f3fc3dc152d 802-3-ethernet Tue 27 May 2014 02:49:34 PM EDT $ nmcli con s a NAME UUID DEVICES DEFAULT VPN MASTER-PATH Bridge connection 1 e169fa95-b104-41f1-8d67-66fffad3eb00 bridge0 yes no -- bridge0 slave 1 75b99588-1b9f-4720-89e1-4f3fc3dc152d enp0s25 no no /org/freedesktop/NetworkManager/Devices/4 $ brctl show bridge name bridge id STP enabled interfaces bridge0 0080.28d244719f30 yes enp0s25 virbr0 8000.52540008b5e4 yes virbr0-nic
The same steps did not work without the reboot I can't seem to figure out why, in the Network GUI When selecting Wired I now see bridge0 Slave 1 ✓ under my eth0 Thanks again.
Wired works, when I try to add my wireless network to the bridge the connection fails. I checked with macchanger and my wifi cards mac is fungible. The command that hangs: (docker0 is the name of my bridge) $ nmcli con up "docker0 slave 2" The error: May 28 10:57:31 hyperion.local NetworkManager[1025]: <error> [1401289051.486361] [platform/nm-linux-platform.c:1596] link_change(): Netlink error: Message sequence number mismatch Full output: May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (docker0): carrier is OFF May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (docker0): new Bridge device (driver: 'bridge' ifindex: 7) May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (docker0): exported as /org/freedesktop/NetworkManager/Devices/5 May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (docker0): No existing connection detected. May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (docker0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (docker0): bringing up device. May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (docker0): device state change: unavailable -> disconnected (reason 'none') [20 30 0] May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> Activation (docker0) starting connection 'Bridge connection 1' May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (docker0): device state change: disconnected -> prepare (reason 'none') [30 40 0] May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 1 of 5 (Device Prepare) scheduled... May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (wlp3s0): disconnecting for new activation request. May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (wlp3s0): device state change: activated -> disconnected (reason 'none') [100 30 0] May 28 10:57:27 hyperion.local NetworkManager[1025]: <info> (wlp3s0): deactivating device (reason 'none') [0] May 28 10:57:27 hyperion.local dhclient[3216]: Received signal 15, initiating shutdown. May 28 10:57:27 hyperion.local NetworkManager[1025]: Received signal 15, initiating shutdown. May 28 10:57:27 hyperion.local NetworkManager[1025]: DHCPRELEASE on wlp3s0 to 192.168.0.1 port 67 (xid=0x2ea0ebfa) May 28 10:57:27 hyperion.local dhclient[3216]: DHCPRELEASE on wlp3s0 to 192.168.0.1 port 67 (xid=0x2ea0ebfa) May 28 10:57:30 hyperion.local NetworkManager[1025]: <warn> (wlp3s0): DHCP client pid 3216 didn't exit, will kill it. May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> (wlp3s0): canceled DHCP transaction, DHCP client pid 3216 May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> NetworkManager state is now CONNECTING May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) starting connection 'docker0 slave 2' May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> (wlp3s0): device state change: disconnected -> prepare (reason 'none') [30 40 0] May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 1 of 5 (Device Prepare) scheduled... May 28 10:57:30 hyperion.local NetworkManager[1025]: <warn> Connection disconnected (reason -3) May 28 10:57:30 hyperion.local NetworkManager[1025]: <warn> (pid 3216) unhandled DHCP event for interface wlp3s0 May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> (wlp3s0): supplicant interface state: completed -> disconnected May 28 10:57:30 hyperion.local NetworkManager[1025]: <warn> Connection disconnected (reason -3) May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 1 of 5 (Device Prepare) started... May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 2 of 5 (Device Configure) scheduled... May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 1 of 5 (Device Prepare) complete. May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 1 of 5 (Device Prepare) started... May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 2 of 5 (Device Configure) scheduled... May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 1 of 5 (Device Prepare) complete. May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 2 of 5 (Device Configure) starting... May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> (docker0): device state change: prepare -> config (reason 'none') [40 50 0] May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 2 of 5 (Device Configure) successful. May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 2 of 5 (Device Configure) complete. May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 2 of 5 (Device Configure) starting... May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> (wlp3s0): device state change: prepare -> config (reason 'none') [40 50 0] May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0/wireless): connection 'docker0 slave 2' has security, and secrets exist. No new secrets needed. May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Config: added 'ssid' value 'cafe bloom' May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Config: added 'scan_ssid' value '1' May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Config: added 'key_mgmt' value 'WPA-PSK' May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Config: added 'psk' value '<omitted>' May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Config: added 'proto' value 'WPA RSN' May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 2 of 5 (Device Configure) complete. May 28 10:57:30 hyperion.local NetworkManager[1025]: <info> Config: set interface ap_scan to 1 May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 3 of 5 (IP Configure Start) scheduled. May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 3 of 5 (IP Configure Start) started... May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> (docker0): device state change: config -> ip-config (reason 'none') [50 70 0] May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> (docker0): IPv4 config waiting until carrier is on May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> (docker0): IPv6 config waiting until carrier is on May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> Activation (docker0) Stage 3 of 5 (IP Configure Start) complete. May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> (wlp3s0): supplicant interface state: disconnected -> authenticating May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> (wlp3s0): supplicant interface state: authenticating -> associating May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> (wlp3s0): supplicant interface state: associating -> 4-way handshake May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> (wlp3s0): supplicant interface state: 4-way handshake -> completed May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'cafe bloom'. May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 3 of 5 (IP Configure Start) scheduled. May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 3 of 5 (IP Configure Start) started... May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> (wlp3s0): device state change: config -> ip-config (reason 'none') [50 70 0] May 28 10:57:31 hyperion.local NetworkManager[1025]: <error> [1401289051.486361] [platform/nm-linux-platform.c:1596] link_change(): Netlink error: Message sequence number mismatch May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) connection 'docker0 slave 2' waiting on master 'docker0' May 28 10:57:31 hyperion.local NetworkManager[1025]: <info> Activation (wlp3s0) Stage 3 of 5 (IP Configure Start) complete.
I just tested this from a completely clean Rawhide live image, starting from a single wired network connection. I used the same steps described in https://bugzilla.redhat.com/show_bug.cgi?id=1036961#c6 : from the GNOME control center Network applet, create a bridge and add a slave profile for the wired adapter. I concur with that reporter's notes that the process is rather difficult to follow, btw. There is definitely at least one out-and-out bug at that point: as jklimes says in c#8 what you actually need to do at that point to bring the network up is activate the bridge slave profile, but you cannot do that from the GNOME control center. The slave profile does not show up in it at all. You only see the old "Wired connection 1" profile. If you drop to a console and do 'nmcli con up (UUID of slave profile)", two things happen: 1) The slave profile comes up and the bridge actually starts working (after a few seconds) 2) The slave profile suddenly appears in the GNOME control center applet So, you can't see the slave profile in the GNOME control center (in order to activate it) until you've activated it. Bit of a catch 22. ;) I'll check whether the same applies to nm-connection-editor...if so there may be some underlying bug affecting both UIs, if not I'll file a bug against GNOME for that element.
nm-connection-editor doesn't really let you bring connections up and down (the clue's in the name!), so the UI bug doesn't exactly apply to it, I don't think. I'll file that against GNOME. One more thing I note is that when you follow all the defaults when creating a bridge (as described in c#6), you wind up with ONBOOT=yes for the bridge itself, but ONBOOT=no for the bridge slave profile. Does that make sense? It seems strange to me. You have to edit the bridge slave profile and change 'Automatically connect to this network when it is available' to checked in the General tab to change this.
Filed https://bugzilla.gnome.org/show_bug.cgi?id=733634 for the GNOME Control Center UI issue.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. 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 20 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.
It seems like in the gnome bug tracker they have duped all bugs related to this to a master bug that basically says "remove all the bridge control functionality from workstation" -- that's too bad. Also, this bug still exists in Fedora 21, so please update the version number.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.
Moving to f21 per comment #17.