First, I strongly agree that limiting to only one enabled interface is a Good Thing
™, if for no other reason than due to existing code presuming there was only one network interface. Reduces complexity significantly.
I really like your suggestions. In addition to hiding them, I’d also suggest explicitly saving the SSID/password fields as though they were empty, when ethernet is enabled (both in UI, and enforced in code). This is to prevent the saved credentials from being left around w/o being seen in UI.
EDIT – Just listing the foundation for next post, as there now appears to be agreement on the following:
-
Only one IP interface should be active at any time.
-
Therefore, when ethernet is enabled, WiFi should be disabled.
-
Re-use of existing IP configuration page, where Ethernet of “None” is renamed to “Wifi”
-
When Ethernet is enabled, SSID and Password fields are hidden from view, and saved as blank entries (aka deleted)
-
WiFi fallback is not a general feature … but to be considered is enabling WiFi AP if the ethernet fails to initialize(*)
That’s a good foundation to start a list of tasks with…
(*) Why WiFi fallback is generally out-of-scope
It is acknowledged that it would be “nice” if WiFi could be automatically enabled if ethernet loses connectivity. However, the complexity of detecting this, is quite complex.
There are many edge cases and state transitions that would need defined actions, and not all of them have clear answers. As examples, what results …
- … when ethernet is working, but there is no internet connectivity (which may be intentional)?
- … when no IP address is initially obtained via DHCP initially? (e.g., if router with DHCP server is slower to boot, which is common).
- … when ethernet is enabled, but no cable is connected?
- … when ethernet is working, with cable being connected → disconnected → reconnected?
Even if the goal would be to revert to ethernet, there are cautions:
- should WiFi be disabled? is disabling of WiFi a mainstream (tested) code path?
- what to do with pending network connections?
Thus, although it may be considered in the future, it would make the feature much more complex (and less testable) to be rightfully considered in a first feature release.
But ... WiFi AP should be enabled if ethernet config fails ...
When configured to use ethernet, but ethernet configuration fails, it’s important to enable the WiFi AP (if that option is enabled in the GUI). This is to allow reconfiguration via the WiFi AP, if (for example) the wrong ethernet configuration was selected.
Since ethernet configuration occurs only once, at boot, this is a “safe” exception to the attempt to reduce the complexity of the system, and would not result in both WiFi and Ethernet being enabled simultaneously.
This would still be disabled, based on the UI setting to disable this capability.