I use a pretty much unconfigured GNOME 50 on Arch Linux using NetworkManager. I normally have both ethernet and wireless connections active, and GNOME shows the “wired connection” icon in the menu bar.
Sometimes, and I’m not sure in what circumstances this gets triggered, the icon turns into the “wireless connection” icon instead, even though both connections are still active and this fact is displayed when I click the icon.
If I toggle my ethernet connection on and off again through the menu, the icon goes back to “wired connection”. If I toggle my wifi connection on and off again, though, it stays at “wired” connection - so it’s not just whatever one connected most recently.
I find this behavior strange. Is it intended?
Here are my network devices under normal conditions:
% nmcli dev status
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected Wired connection 2
wlp0s20f3 wifi connected redacted
tailscale0 tun connected (externally) tailscale0
docker0 bridge connected (externally) docker0
lo loopback connected (externally) lo
br-dae9db902211 bridge connected (externally) br-dae9db902211
p2p-dev-wlp0s20f3 wifi-p2p disconnected --
enp40s0 ethernet unavailable --
This does not look like an actual networking failure. Your nmcli output looks normal, and both ethernet (eth0) and Wi-Fi (wlp0s20f3) are still connected at the same time.
The issue is most likely related to GNOME Shell / NetworkManager status-selection behavior rather than a driver or hardware problem. GNOME does not always follow a strict “wired always wins” rule for the panel icon. In some situations the displayed icon appears to follow route priority, connectivity reevaluation, or whichever connection is currently treated as the primary/default route.
That would also explain why toggling ethernet immediately restores the wired icon.
You could try restarting GNOME Shell or NetworkManager, but checking route metrics is probably more useful:
Thanks, I agree that there isn’t a real connectivity issue, I am however interested in correcting the cosmetic discrepancy as I find it confusing. You mentioned checking the ipv4.route-metric values, however I don’t see anything like that from the command you gave:
% nmcli connection show
NAME UUID TYPE DEVICE
Wired connection 2 103c8302-4f4f-35c4-83f9-83e26b2d83e4 ethernet eth0
redacted 49bf523b-39fa-4caa-b4a7-2a7224e2b1c8 wifi wlp0s20f3
tailscale0 da1018d6-b9b4-49f6-b2a8-0770bea71458 tun tailscale0
docker0 04524ee7-222b-4871-87c0-d807e7446626 bridge docker0
lo f8f6a80c-28ab-4a08-a997-e3c9654822fd loopback lo
br-dae9db902211 bc95c9cc-6965-4821-9854-51660ff5d743 bridge br-dae9db902211
redacted 4c9b6717-27ca-46d4-a72a-3da7256c5496 wifi --
redacted f9f28cba-51f3-4921-b840-eca89bb9d99a wifi --
Wired connection 1 3a0b304e-fded-35b5-8da3-b158b9e14c5b ethernet --
I checked the man page and found that I could supply --fields=all and it gives a larger table, but still doesn’t report route metrics. Just autoreconnect priority.
Oh, I gotcha, that makes sense. So what’s probably happening here is my network connection becomes unstable, and the connectivity check fails for both wifi and wired connections, but perhaps out of sync from each other, or staggered. Then the check passes again for wireless, and it’s preferred until the check passes for wired as well. That makes sense and is fine with me, so long as it repairs itself in a timely manner.
I see the following in /usr/lib/NetworkManager/conf.d/20-connectivity.conf:
interval
Specified in seconds; controls how often connectivity is checked when a
network connection exists. If set to 0 connectivity checking is disabled.
If missing, the default is 300 seconds.
Since that parameter isn’t specified in the configuration file, I presume that my system should return to its normal state within 5 minutes after a network interruption. Next time I see this, I will check if that’s the case! Thanks for the pointer.
Also, I checked the man pages a bit more and found that there is a nmcli networking connectivity check command that I could use to refresh the connectivity check state. At least I think that’s what it does - it’s a little confusing to me that I don’t specify an individual connection, maybe it refreshes all of them. I’ll try, next time I see the issue.
Ok, update: it doesn’t look like the connectivity check. When the issue is occurring:
% ip route show default table all
default via 192.168.1.1 dev wlp0s20f3 proto dhcp src 192.168.1.190 metric 600
default via fe80::8269:1aff:fe23:8d76 dev eth0 proto ra metric 100 pref medium
default via fe80::8269:1aff:fe23:8d76 dev wlp0s20f3 proto ra metric 600 pref medium
So, no penalty from connectivity check. And no change from this either: