GNOME Bugzilla – Bug 706098
Network indicator always shows 'disconnected' for a wired connection
Last modified: 2013-09-20 07:42:07 UTC
Created attachment 251784 [details] screenshot of the issue I'm running Fedora Rawhide (20) on my desktop, up to date with gnome-shell-3.9.5-2.fc20.x86_64 . I see a lot of change in the git logs since 3.9.5 but nothing related to this bug, and I can't find any closed reports, so I thought I'd better file it. Aside from the stuff discussed in https://bugzilla.gnome.org/show_bug.cgi?id=705104 , I have a more serious bug: on my rather ordinary wired connection, the actual network indicator itself always shows the 'offline' state, two computers with an x at the bottom right. Even when it's clearly online (it looks like that right now, as I'm submitting this bug). I'm not sure if this bug has consequences beyond the aesthetic, but it's obviously a bit of a problem even from that perspective. (VNC connection status display is also badly messed up, but I don't know if that's related to this bug or not; I'm saving that one till 3.9.6 comes out at least). In the following 'ip addr' output, em1 is the wired connection, virbr0 and virbr0-nic are the bridge for libvirt I think, and tun0 is for a VPN connection (it's not related to the bug; the indicator shows 'disconnected' whether I connect to the VPN or not). Any other info needed? [adamw@adam badges (master)]$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether f4:6d:04:9a:1d:45 brd ff:ff:ff:ff:ff:ff inet 192.168.1.5/24 scope global dynamic em1 valid_lft 72887sec preferred_lft 72887sec inet6 fe80::f66d:4ff:fe9a:1d45/64 scope link valid_lft forever preferred_lft forever 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN link/ether 52:54:00:aa:78:5d brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 500 link/ether 52:54:00:aa:78:5d brd ff:ff:ff:ff:ff:ff 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/none inet 10.3.113.3/24 scope global tun0 valid_lft forever preferred_lft forever
do we have a plan for this ?
just to record this here: Jasper has a patch to fix this. It relies on nm changes discussed in bug 704841 which will hopefully land soon.
Created attachment 253295 [details] [review] network: Update for new APIs New network manager APIs mean we don't have to do any scanning through the active networks and synchronize state ourselves.
Created attachment 253296 [details] [review] network: Use one notification globally for connection status Rather than one per device.
Review of attachment 253295 [details] [review]: Mostly good ::: js/ui/status/network.js @@ +1437,1 @@ } I thought we were supposed to prefer the activating connection to the active one? @@ +1579,3 @@ } else { let dev = this._mainConnection._primaryDevice; + this._primaryIndicator.visible = (dev != null); Are we fully hiding the icon, if it's wired?
Review of attachment 253296 [details] [review]: ::: js/ui/status/network.js @@ +1338,3 @@ + _("Connection failed"), + _("Activation of network connection failed"), + MessageTray.Urgency.HIGH); onActivationFailed still comes from NMConnectionDevice, so it doesn't help in the wired case. @@ +1457,2 @@ this._mainConnectionStateChangedId = this._mainConnection.connect('notify::state', Lang.bind(this, this._mainConnectionStateChanged)); this._mainConnectionStateChanged(); Ops, yes, squash with the previous patch.
(In reply to comment #5) > I thought we were supposed to prefer the activating connection to the active > one? I could go either way on this one, but I believe aday said that we should prefer the active connection to any activating one. > Are we fully hiding the icon, if it's wired? Yes; that's the design.
(In reply to comment #6) > onActivationFailed still comes from NMConnectionDevice, so it doesn't help in > the wired case. Yes, which is unfortunate. Do you have any suggestions? > Ops, yes, squash with the previous patch. Gah, it's too easy to accidentally amend in my workflow...
Attachment 253295 [details] pushed as e1c4cfd - network: Update for new APIs Attachment 253296 [details] pushed as 3f15a41 - network: Use one notification globally for connection status pushed with suggested fixes