pfSense

Jim,

Note that:
- the interface assignment was completely legal when it was created (the x520 was functioning at that moment)
- the x520 problem started when the router was running, the dashboard status did not show, that the underlying x520 was gone
- the router was still booting even when the x520 interface had errors and also when it was not visible for the OS any more (pciconf lv)
and the router is booting "without problem" now that the x520 has been removed. In fact I am quite happy with that since my network has an 1G part and an 10G part. The 1G-part is still active allowing me to write this report, where the 10G side of my network is not reachable, since I lost the x520

Sincerely,

Louis

None of that matters. If the interface is missing when it must be present, the configuration should be rejected as with any other interface mismatch.

Hardware may fail in some way but that is not always possible to detect at runtime. A reboot should always catch since it would be missing at that time.

It doesn't matter if your particular environment still functioned partially in that state with the interface removed, it's not a valid state and must always be rejected.

https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/306

@Jim,

I object !!

• the network had stopped completely !!!*
• Now the 1G-part of the network was running completely normal. Just the 10G part was effected.
• I would have had lots of work to create a new config! Impossible in reasonable time !!!

- second point less service!, it is nonsense that a running system can not detect failing hardware. For example if a pciconf -lv does not show the used interfaces, you know something is wrong! Using pings is perhaps another option, etc. That kind of info could be shown in a hardware widget

So, very bad decisions to stop the router if there is any hardware issue! Just show it on the dashboard and let the administrator decide!

Louis

That is not the philosophy taken by pfSense for other interfaces, and it won't be changed here. There are other open issues for requests to allow disconnected or removable interfaces, but this is not the place for it.

Because it happened to partially work for you by pure luck doesn't mean we should accommodate a broken and invalid configuration when it could lead to catastrophic failures for others.

Jim,

As stated before, IMHO the fact that a particular interface fails, should NOT be a reason to shut the whole system down! I was very glad (!!) that the system was still running, at the moment one of the interfaces failed. That made it possible to use at least a significant part of the network!

However / of course the dashboard should correctly show which interfaces are down. And that was not the case when I originally initiated the ticket :(

Sincerely,

Louis

And as noted above, that may be true for your environment but not for most others. Your experience is unusual and not indicative of what most users would encounter in similar failures.

Halting and forcing the user to correct the failure is the safest path and the path we have chosen to take.

Jim,

Your choice of course however note:
- I took me longer than necessary to understand the problem by then, because the dashboard / gui did not show the problem !
- After I had identified the problem, I immediately ordered a replacement interface board ......
- however it took of course two days before that board arrived.
- I would not have been happy if the consequence had been a complete firewall outage for 2,5 days!

Louis

Behaves as expected on

2.6.0-RELEASE (amd64)
built on Tue Jan 25 19:18:35 UTC 2022
FreeBSD 12.3-STABLE

Assigned VLAN to interface, rebooted without interface, and it prompted for interface assignments.