Removing wifi card causes pfSense not to boot.
-
Not sure if this is only 2.1 but I removed a wireless adapter from my pfSense and I get the following: (only way I managed to boot up again was through console)
Warning: Interface 'ath0' does not exist. Network interface mismatch -- Running interface assignment option. Valid interfaces are: re0 00:90:7f:2f:6e:21 (up) RealTek 8139C+ 10/100BaseTX re1 00:90:7f:2f:6e:22 (up) RealTek 8139C+ 10/100BaseTX re2 00:90:7f:2f:6e:23 (up) RealTek 8139C+ 10/100BaseTX re3 00:90:7f:2f:6e:24 (up) RealTek 8139C+ 10/100BaseTX re4 00:90:7f:2f:6e:25 (up) RealTek 8139C+ 10/100BaseTX re5 00:90:7f:2f:6e:26 (up) RealTek 8139C+ 10/100BaseTX ovpns200:bd:e1:3e:00:02 (up) Do you want to set up VLANs first?Even though this was not the WAN or LAN I removed, it stopped the firewall from booting. I think it should continue to boot if LAN is still operational… IMHO
-
This is normal behaviour on any version.
pfSense tries to setup it's interfaces according to the config file but can't because one of them is missing. It falls back to the interfaces setup.Steve
-
Hmm.. But I would think if there is LAN that we should be able to access the webgui… I have a console that I could use.. no biggie...
-
Although this is normal behaviour. I also think this should not be the case for USB hardware removed, when a lan & wan interface remain unchanged.
-
I'll third that, as long as the LAN interface is present, it should boot and allow WebGUI access.
-
There is some discussion about what to do here but it's not quite so simple.
Imagine this situation:
You have 5 cards, em0, em1, em2, em3, em4.
Imagine that em2 is your LAN, and em3 is a WLAN you don't trust.
If the em2 card dies, when it comes back up, em3 would be em2, and em4 would be em3, and until you trace the cables out or confirm the link somehow, you have no idea which one is which. Any one of them could have died. If it just kept booting without stopping, the em3 network (now running on em2, using em2's settings) just got more access to the rest of the network than you intended.
Going into an ugly warning when you lose a NIC is the safest thing to do, so an interface doesn't end up gaining privileges.
Now in the future that could maybe be tracked,confirmed with MAC addresses, or auto-disable limited to chips known to be USB, or any one of a dozen other things, but what we do now is still the safest default behavior in these cases.
-
Ah, I see, could it be set to read the LAN NIC's MAC address and require that to be unchanged + disable EVERYTHING except WebGUI access (on the confirmed LAN NIC) to reconfigure interfaces?
-
Ah, I see, could it be set to read the LAN NIC's MAC address and require that to be unchanged + disable EVERYTHING except WebGUI access (on the confirmed LAN NIC) to reconfigure interfaces?
Agreed; particularly with USB devices, the very likely difficult step of tying interface identification to something more permanent than boot load order becomes very important; if I move a couple USB devices around/add/remove them, and even swap PCI(e) card slots, I'd prefer to have the interface assignments follow actual cards, not where they happen to be. Ideally, base it on ID (8086:422c for an Intel 6200) plus and MAC address, and then use the some other ordering (the current system or one of the alternates below) to resolve duplicates. If there are duplicates, any anything was seen to change, then yes, don't risk giving an adapter more permissions than it should have. If there aren't duplicates, then it should be safe.
Given the likely difficulty of that, as a stopgap can the interface ordering be done so hardwired interfaces are given IDs first, and USB/hotswappable ones second, still sequentially. This would again allow those hardwired interfaces to be safe from renumbering based on USB device changes.
Alternately, can we have nonsequential or more specifically ordered numbering? Hardwired interfaces [PCI(e)] get 0-N in whatever order, and USB gets N+1-M?
-
Agreed; particularly with USB devices, the very likely difficult step of tying interface identification to something more permanent than boot load order becomes very important; if I move a couple USB devices around/add/remove them, and even swap PCI(e) card slots, I'd prefer to have the interface assignments follow actual cards, not where they happen to be. Ideally, base it on ID (8086:422c for an Intel 6200) plus and MAC address, and then use the some other ordering (the current system or one of the alternates below) to resolve duplicates.
That introduces its own problems. Have a box die on you, get a warranty replacement, restore your config, and it works perfectly the way things work now. Do this, and it no longer works. Numerous vendors ship boxes with custom pre-assigned NICs, which this would break. MAC spoofing also breaks this as the NIC's hardware MAC is gone once it's spoofed. There are countless other caveats. No matter how you handle interface assignments it introduces complications, breaks things that currently work that many people rely on, and has other caveats, in addition to being a very bug prone and work intensive process to change. This is one of those things that may seem simple at the surface but is actually very complicated. We've been discussing this one for going on 8 years off and on, and it's a real mess to do any differently. Hence it's not changing any time soon.
