Bug 1033683 - nm-applet says no network even though bridge is up, vpn connections also handled badly
Summary: nm-applet says no network even though bridge is up, vpn connections also hand...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: network-manager-applet
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-22 15:37 UTC by Jeff Layton
Modified: 2014-06-18 07:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-22 21:50:51 UTC
Type: Bug


Attachments (Terms of Use)
screenshot of nm-applet menu (89.60 KB, image/png)
2013-11-22 15:37 UTC, Jeff Layton
no flags Details

Description Jeff Layton 2013-11-22 15:37:21 UTC
Created attachment 827865 [details]
screenshot of nm-applet menu

After much struggle, I got a bridge set up in NM. At boot time, it starts and the physical network interface is slaved to it as expected.

nm-applet however seems to be totally incapable of handling a bridge however. Here's the state of the networking post-boot. Looks fine:

$ ifconfig -a
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.3  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::3a60:77ff:fe93:a95d  prefixlen 64  scopeid 0x20<link>
        inet6 2001:470:8:d63:3a60:77ff:fe93:a95d  prefixlen 64  scopeid 0x0<global>
        ether 38:60:77:93:a9:5d  txqueuelen 0  (Ethernet)
        RX packets 2682  bytes 1150570 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2365  bytes 365254 (356.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::3a60:77ff:fe93:a95d  prefixlen 64  scopeid 0x20<link>
        ether 38:60:77:93:a9:5d  txqueuelen 1000  (Ethernet)
        RX packets 2759  bytes 1206033 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2766  bytes 402110 (392.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xfe700000-fe720000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 97  bytes 9854 (9.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 97  bytes 9854 (9.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:b9:7c:88  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0-nic: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 52:54:00:b9:7c:88  txqueuelen 500  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ brctl show
bridge name	bridge id		STP enabled	interfaces
br0		0080.38607793a95d	yes		em1
virbr0		8000.525400b97c88	yes		virbr0-nic

However, the nm-applet menu looks like the attached picture. The icon has an 'x' over it which is what it usually looks like when the networking isn't up, but the bridge itself is working just fine.

The Wired networking says "on", even though it's slaved to the bridge.

If I then try to bring up the VPN, that all works correctly. I get the prompts for password and such and the VPN comes up normally. The nm-applet menu still looks the same however after that. The slider switch for the VPN stays in the off position, and the icon in the status bar doesn't change to the lock.

Comment 1 Jeff Layton 2013-11-22 15:40:13 UTC
Oh, and here is some nmcli output:

[jlayton@tlielax ~]$ nmcli nm
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN      
running         connected       enabled         enabled    enabled         disabled  

[jlayton@tlielax ~]$ nmcli d
DEVICE     TYPE              STATE        
br0        bridge            connected    
em1        802-3-ethernet    connected    

[jlayton@tlielax ~]$ nmcli c
NAME                      UUID                                   TYPE              TIMESTAMP-REAL                    
Red Hat OpenVPN (PHX)     ee557ea1-907f-42dd-a78d-fa7bca3d525a   vpn               Wed 13 Nov 2013 04:54:54 PM EST   
br0                       0cab6e24-b5f8-46ba-8b43-597c95fe1c43   bridge            Fri 22 Nov 2013 10:35:02 AM EST   
br0 slave 1               88903a0a-dd44-4bc1-a0d3-2acdc9ed4b3a   802-3-ethernet    Fri 22 Nov 2013 10:35:02 AM EST   
Red Hat vpnc (RDU)        1ecb6514-f777-4062-b6f6-a4df4570c5bc   vpn               Fri 22 Nov 2013 10:23:57 AM EST

Comment 2 Jeff Layton 2013-11-22 15:43:48 UTC
Oh, and my f19 box is patched up as of this morning:

network-manager-applet-0.9.8.4-1.git20131028.fc19.x86_64
NetworkManager-pptp-gnome-0.9.8.2-3.fc19.x86_64
NetworkManager-glib-devel-0.9.8.8-1.fc19.x86_64
NetworkManager-glib-0.9.8.8-1.fc19.i686
NetworkManager-vpnc-0.9.8.2-2.fc19.x86_64
NetworkManager-0.9.8.8-1.fc19.x86_64
NetworkManager-pptp-0.9.8.2-3.fc19.x86_64
NetworkManager-openconnect-0.9.7.0-2.git20120918.fc19.x86_64
NetworkManager-openvpn-gnome-0.9.8.2-3.fc19.x86_64
NetworkManager-glib-0.9.8.8-1.fc19.x86_64
NetworkManager-openvpn-0.9.8.2-3.fc19.x86_64
NetworkManager-devel-0.9.8.8-1.fc19.x86_64
NetworkManager-vpnc-gnome-0.9.8.2-2.fc19.x86_64

Comment 3 Jeff Layton 2013-11-22 21:50:51 UTC
Ahh, went ahead and updated the box to f20 beta and the problem seems to be straightened out. Sorry for the noise!


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