Feature #410
closed
Eliminate the interface mismatch prompt and try to do the right thing automatically
0%
Description
Especially for embedded platforms, I think it would be useful to completely do away with the interface mismatch screen on the console and try to work things out automatically in some way, if possible. There shouldn't be any loss of functionality by trying to do it automatically, since the assign interfaces option on the console menu does the exact same thing. This would eliminate most cases for needing to use the serial console on nanobsd or a monitor and keyboard on others. Upon encountering an interface mismatch it should probably write some flag to a file that will be cleared at a successful startup, to show the interface mismatch prompt at the next boot if the flag isn't cleared, in case it can't boot from the automatic configuration for any reason.
Some ideas related to the case where there is already an existing configuration and physical interfaces have been changed or removed, causing there to be not enough interfaces to fill the slots. These would only be used after all new interfaces have been assigned to the slots where the interfaces disappeared. In either case, the web gui should probably inform the user of this so they can fix it (though maybe not require fixing it?).
1) If there is any kind of virtual interface that could be assigned kind of like a "none" option, it would be useful to allow preserving the configuration of the remaining slots where interfaces disappeared.
2) If referring to a non-existant interface would be ok, maybe just leave it alone if there aren't any remaining interfaces to fill it.
Updated by Erik Fonnesbeck over 14 years ago
- Assignee set to Erik Fonnesbeck
- Target version set to 2.0
I'm considering maybe implementing this myself for 2.0, though probably in my own fork/branch until it is approved.
Updated by Chris Buechler over 14 years ago
There is already something along these lines that will auto-assign interfaces if there is a mismatch. I believe it was disabled after problems arose and the contributor didn't respond. The code should still be there.
There's a lot of potential risk in doing this, the previous discussion resulted in some things to considerably limit risk. The former way relied on checks to ensure it wasn't hosing a valid config that had just lost a NIC due to hardware problems or other changes. It would only auto-assign if:
1) The assign interfaces prompt timed out (it waited 10 seconds)
2) trigger_initial_wizard is set (indicating reset to defaults or a new install)
3) The default config.xml interface assignments were in place
Updated by Erik Fonnesbeck over 14 years ago
- Target version deleted (
2.0)
I probably shouldn't have set a target version.
Anyway, some additional ideas I had:
For the unassigned interfaces, I thought of a system for determining where to fill in the blanks.
1) First of all, it would look for missing interfaces that match known names of wireless adapters and try to find an unassigned wireless adapter to fill it in.
2) Next it would look for unassigned wired interfaces, giving priority to the name with the highest count (counting both assigned and unassigned). My idea behind this is that multiples of the same type of interface probably would usually mean the hardware was picked out with the intention of using them, and interfaces with only one of the type are more likely an integrated interface that was unwanted.
3) When there are no more missing wireless interfaces and all unassigned wired interfaces have been exhausted, the remaining slots could maybe be filled with loopback interfaces.
Other things to do:
1) Make sure something is assigned to lan, or wan if lan doesn't exist.
2) Also keep track of what has been done, at least until a successful boot, so that if the chosen assignments prevent booting, it can go to a more basic configuration on the next boot.
3) Optionally, if that still doesn't work, maybe it could even try assigning an interface of a different name after each unsuccessful boot.
All mismatch cases would probably have a timeout period where you could press a key to manually assign interfaces.
Updated by Ermal Luçi over 14 years ago
This sounds like over-engineered.
What is needed is just to make sure that the interface at boot matches the one before reboot.
If this is a first boot than just auto assign on embedded.
The other problems can be solved by just checking if the interface exists before doing any operation on it.
Updated by Erik Fonnesbeck over 12 years ago
- Assignee deleted (
Erik Fonnesbeck)
Removing myself from this since there wasn't quite an agreement on what exactly should be done here and I have no immediate plans to implement this yet.
Updated by dont care about 11 years ago
I'd like to add a situation that I recently eperienced: One interface was gone (just a usb stick for WLAN) and network interface mismatch ran on boot.
I would have expected to be asked if I care about the missing interface and done, but instead I had to reconfigure EVERYTHING, I had to reassign LAN and WAN, though they were still there and did not change! Because I also have several VLANs on my LAN, I finally gave up and restored a backup.
To keep it short: Please, don't let the user reconfigure already configured things!
Also I would like it if pfsense would continue with the known interfaces, without guessing any interfaces and then show the errors on the webinterface and in addition on the console prompt that's shown after successfull boot. Better for embedded systems and also reduces downtime for e.g. internet access: in my case booting stopped because WLAN was gone and therefore also internet access wasn't possible from system using ethernet. so the network interface mismatch stuff made my problem worse than it was.
As a compromise, a good solution until there is maybe more time to work on this would be to offer the user the choice to continue with the found / still available interfaces without reconfiguring them. I don't know the current code, but I guess just keeping the configuration for existing interfaces should be quite easy to implement? Showing stuff on webinterface etc. could then maybe added later.
Updated by dont care about 11 years ago
about restong the backup, that only works if that yet doesn't include the missing interface. my wlan usb stick was quite new, so that was no problem. but if my wlan stick fails in a year, I won't have a backup without usb wlan stick interface and up to date firewall rules! so then I would have to reconfigure everything manually on the console ):
Updated by Jim Pingle over 5 years ago
- Status changed from New to Resolved
There have been changes for this in recent years to do the right/expected things on recognized (and common) hardware platforms. To me that seems to be good enough without major reengineering.