GNOME Bugzilla – Bug 740739
cannot activate shared connection on physically disconnected ethernet
Last modified: 2020-11-12 14:26:34 UTC
Use case: Connect two computers using an ethernet cable so that one shares internet with the other. Expected behavior: Connection sharing means using the computer as a router, so I would expect that I could activate this type of connection at any time, even when there's no cable connected or when the other computer is off. Actual behavior: It's not possible to activate the connection (at least via nm-applet) when the other computer is off. Rationale: Whether I want to share a connection, or, say, apply a manual configuration, shouldn't depend on the link state as NM has no clue on how I will use the connection. One possibility is to actually *boot* the other computer using network. This may not even be PXE from the other computer that would need additional configuration, it can be a HTTP based boot for example. Notes: I would even say that for manual and shared connections, it would be best to ignore carrier either always or at least by default. To state it more precisely, I would say that a connection that doesn't need to listen on the network to perform configuration (like DHCP or rdisc client) should ignore the carrier so that: 1) It can be started at any time and is thus presented to the user. 2) It doesn't drop when a cable is unplugged or the directly connected machine or switch gets rebooted. I originally wanted to file this with nm-applet but now I'm not sure whether the issue is specific to nm-applet or intrinsic to NetworkManager.
I would like to get the issue considered for 1.2. A solution would probably require that some connections (those that need to talk over the device as part of the connection procecure) are not applied until the device is physically connected, while other connections (those that don't need that) are applied immediately. DAD might be a bit tricky, though. The user would then see all connections that can be applied in the current device state.
Yeah, carrier should be ignored on shared connections, like we ignore the fact that the access point doesn't exist yet for WiFi AP/Hotspot.
(This might be already fixed. Needs testing first...)
Now a connection with ipv4.method=shared can be activated manually even if the carrier is off. But still the connection will drop when the carrier goes down; probably we only need to ignore down events when the IPv4 method is 'shared'. Also, the device doesn't auto-activate when the carrier is off (unless the device has ignore-carrier set), but I don't think this is a problem since it will eventually activate when the link goes up and then stay up.
Created attachment 321472 [details] [review] [PATCH] device: don't deactivate shared connection on link down
There is already a function connection_requires_carrier(). Maybe that should be reused?
(In reply to Thomas Haller from comment #6) > There is already a function connection_requires_carrier(). Maybe that should > be reused? Ok, but connection_requires_carrier() returns FALSE also for ipv4.method=manual and this means that when the carrier goes down, a device with static addresses would remain activated and NM global state "connected/full" even when there is no connectivity. Probably we should limit this behavior to shared connections, what do you think?
Pavel said: > I would even say that for manual and shared connections, it would be best to > ignore carrier either always or at least by default. To state it more > precisely, I would say that a connection that doesn't need to listen on the > network to perform configuration (like DHCP or rdisc client) should ignore the > carrier so that: I think in the future we wont less of one either-or "method", but more like: turning on different addressing modes. Like: [ ] DHCPv4/auto [ ] manual addresses [ ] link-local [ ] shared (shared is incompatible with auto). In such a scenario it's much less clear when the user wants to ignore carrier and when not. Eventually, I think that the connection should have a property "ignore-carrier". But really, connection_requires_carrier() allows you to activate a connection without carrier. There you have the same problem, e.g. with connected/full state. Why would that behave differently when carrier is lost? In any case, I would still reuse connection_requires_carrier(), possibly with a new argument: static gboolean connection_requires_carrier (NMConnection *connection, gboolean on_carrier_lost) That way, the logic is still in one place and you can grep for connection_requires_carrier to find all the places which ask this question.
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).