GNOME Bugzilla – Bug 723155
Per interface connection status
Last modified: 2020-11-12 14:25:54 UTC
The latest GNOME system status designs [1] indicate network status per interface. For example, you might have "wi-fi: no route" and "wired: no route" indicated independently. This has a number of fairly obvious advantages, since you can see the status of the various connections you have, or see why you have fallen back to a particular interface type. I hear that this isn't currently possible with network manager, but it is something that we would like to have for GNOME 3.12. [1] https://wiki.gnome.org/Design/OS/SystemStatus
From the design document: "In use" is defined as being used by network manager as the default route (interfaces are selected using a hard-coded ranking). There is always only one default route interface. Therefore for that purpose you would only need access to the global status and the connection information for the default active connection. I'm not sure whether you can query which connection is the default one, one of the other developers could give out that information. The menu items seem to be already available e.g. in Gnome Shell's network indicator. Could you please specify what requirements you have and which of them are not met by NetworkManager?
(In reply to comment #1) > From the design document: > > "In use" is defined as being used by network manager as the default route > (interfaces are selected using a hard-coded ranking). > > There is always only one default route interface. Therefore for that purpose > you would only need access to the global status and the connection information > for the default active connection. There are situations where we would like to show more than one status icon in the top bar (if you are using mobile broadband and have a wi-fi connection with a "no route" state, for example). We also want to show status in the menu for all the interfaces you can see there (see the second menu on the wiki page [1]). > I'm not sure whether you can query which connection is the default one, one of > the other developers could give out that information. OK. I don't know exactly how the shell decides which icon to show in the top bar. Obviously it would be good if we could use network manager for that though. It should be noted that we'd quite like to indicate the default route in the menu too (or even show up/down traffic per interface), but haven't figured out a good way to do that yet. > The menu items seem to be already available e.g. in Gnome Shell's network > indicator. Sure... (I think I'm missing what you mean by this sentence). > Could you please specify what requirements you have and which of them are not > met by NetworkManager? I filed this bug after a conversation with danw on irc; since he suggested that the behaviour we want isn't currently possible. Dan - could you chime in, perhaps? [1] https://wiki.gnome.org/Design/OS/SystemStatus#Menu_Items
I've added some details on which interface states I would like to communicate through the system status area: https://wiki.gnome.org/Design/OS/SystemStatus#Network_States I think this is probably a bit incomplete, and would appreciate some feedback on what is missing. There probably needs to be an error state for each interface type, for example, but I'm not entirely sure what the status string should say in there.
(In reply to comment #2) > > The menu items seem to be already available e.g. in Gnome Shell's network > > indicator. > > Sure... (I think I'm missing what you mean by this sentence). Simply that I don't see what's missing in NetworkManager to do what you want. > > Could you please specify what requirements you have and which of them are not > > met by NetworkManager? > > I filed this bug after a conversation with danw on irc; since he suggested that > the behaviour we want isn't currently possible. Dan - could you chime in, > perhaps? Good idea. If Dan already knows what's needed, it would be useful if he specified the missing API bits in the bug report on your behalf.
> Simply that I don't see what's missing in NetworkManager to do what you want. What's missing is per-interface connectivity status; we have a global disconnected/locally-connected/behind-a-portal/connected-to-internet state, but we don't have that state for each interface, which they need for the UI proposed here. > <aday> danw, any thoughts on bug 723155 ? i'd like to know where we are ahead of ui freeze Hm... I guess I thought this was for some farther-away release... There won't be a new NM release before GNOME 3.12.0, so anything that requires new API won't be possible for 3.12. (I think, in the current version of the wiki page, that's the -no-route and -error icons.)
(In reply to comment #5) > > Simply that I don't see what's missing in NetworkManager to do what you want. > > What's missing is per-interface connectivity status; we have a global > disconnected/locally-connected/behind-a-portal/connected-to-internet state, but > we don't have that state for each interface, which they need for the UI > proposed here. As I said on bug 723570, I don't understand why you would have per interface connectivity status. Connectivity is a property of the default route: either is a useful default route (ie, it gets you somewhere), or it's not good. OTOH, per-interface connectivity checks in NM would be useful in picking a better default route, in case there is a choice. And then maybe we could have something like "Wi-Fi disabled because it's slow" (Android >= 4.2 does it)...
(In reply to comment #6) > (In reply to comment #5) > > > Simply that I don't see what's missing in NetworkManager to do what you want. > > > > What's missing is per-interface connectivity status; we have a global > > disconnected/locally-connected/behind-a-portal/connected-to-internet state, but > > we don't have that state for each interface, which they need for the UI > > proposed here. > > As I said on bug 723570, I don't understand why you would have per interface > connectivity status. Connectivity is a property of the default route: either is > a useful default route (ie, it gets you somewhere), or it's not good. I'm curious about that as well. All connections have their state but the overall connectivity status is IMO only related to default routing and default DNS. > OTOH, per-interface connectivity checks in NM would be useful in picking a > better default route, in case there is a choice. And then maybe we could have > something like "Wi-Fi disabled because it's slow" (Android >= 4.2 does it)... Yes, but that's another story and should be handled in NetworkManager itself. It's related to multiple default route support as well as multiple same-destination route support. Bug #709478 and bug #723178 are good starting points for that. I would be very curious as how exactly and how well android does that. If you have such information, we could start a new bug report to track it.
(In reply to comment #6) > As I said on bug 723570, I don't understand why you would have per interface > connectivity status. Connectivity is a property of the default route: either is > a useful default route (ie, it gets you somewhere), or it's not good. Yes, but even if the wifi isn't the default route, it still either is or is not behind a portal. So the concept is perfectly well-defined.
(In reply to comment #8) > (In reply to comment #6) > > As I said on bug 723570, I don't understand why you would have per interface > > connectivity status. Connectivity is a property of the default route: either is > > a useful default route (ie, it gets you somewhere), or it's not good. > > Yes, but even if the wifi isn't the default route, it still either is or is not > behind a portal. So the concept is perfectly well-defined. How will you know whether a non-default-routing wifi is or isn't behind a captive portal? Isn't default route one of the prerequisities for portal detection?
And the other thing is, if you have working ethernet, do you even care that wifi is behind a portal? (If you have working 3g, and NM keeps using that instead of bugging you to log into wifi, then you care, but this isn't the case today)
(In reply to comment #10) > And the other thing is, if you have working ethernet, do you even care that > wifi is behind a portal? Yes. That's why I'm all the time curious about specific requirements for this UI design work and also whether they are practically achievable. I can imagine the user is interested in disconnected->connecting->connected sequence but I can't imagine how the default device specific values could help non-default device status representation in the UI. > (If you have working 3g, and NM keeps using that instead of bugging you to log > into wifi, then you care, but this isn't the case today) That would be a much more interesting user experience research. Currently the UI allows you to connect/disconnect but not to select your default routing/DNS device.
(In reply to comment #11) > > (If you have working 3g, and NM keeps using that instead of bugging you to log > > into wifi, then you care, but this isn't the case today) > > That would be a much more interesting user experience research. Currently the > UI allows you to connect/disconnect but not to select your default routing/DNS > device. And I'm not even sure whether and how they will present the (internally done) default device choice in the UI.
(In reply to comment #9) > > Yes, but even if the wifi isn't the default route, it still either is or is not > > behind a portal. So the concept is perfectly well-defined. > > How will you know whether a non-default-routing wifi is or isn't behind a > captive portal? Isn't default route one of the prerequisities for portal > detection? Currently, yes, but that's a problem; if you have a working wifi connection, and you bring up an ethernet connection, you really want to test if the ethernet connection is usable *before* you make it the default route, rather than temporarily breaking routing and then switching back to the wifi connection only after you've determined that the ethernet connection doesn't work. dcbw had attempted to do this in the past using SO_BINDTODEVICE, but it didn't quite work. (I don't remember the details.) (In reply to comment #10) > And the other thing is, if you have working ethernet, do you even care that > wifi is behind a portal? That's a question for bug 723570
(In reply to comment #13) > (In reply to comment #9) > > > Yes, but even if the wifi isn't the default route, it still either is or is not > > > behind a portal. So the concept is perfectly well-defined. > > > > How will you know whether a non-default-routing wifi is or isn't behind a > > captive portal? Isn't default route one of the prerequisities for portal > > detection? > > Currently, yes, but that's a problem; if you have a working wifi connection, > and you bring up an ethernet connection, you really want to test if the > ethernet connection is usable *before* you make it the default route, That's not technically correct. You need a *default route* for the testing. And you could support multiple default routes in NM, one of them being preferred and the others testable. But that's bug 709478 and related to bug 723178. Giovanni is right here that you're not interested in hotspot status for non-default-route interfaces. What you're interested in is per-interface status of default-route interfaces and the current code base doesn't support that. > dcbw had attempted to do this in the past using SO_BINDTODEVICE, but it didn't > quite work. (I don't remember the details.) I guess that with bug 709478, it's good enough to bind to the first global address of the device and you don't need quirks like that. People are already using it source based routing, just without NetworkManager. When it works with NetworkManager, which would open all sorts of new technology to NM users including Multipath TCP, we can talk about the UI work on top of it. But I guess to support the feature fully, you'll need some kernel features as well to distinguish between hotspot test routes and openly usable routes. That said, without bug 709478, we're pretty much stuck.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).