Bug #12170


Interface assignment mismatch is not detected if VLAN-only parent interface is removed

Added by Jim Pingle over 1 year ago. Updated about 1 year ago.

Viktor Gurov
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


If an interface is used only for VLANs (e.g. it is not assigned directly) and that interface is removed, the system does not detect this as a problem at boot time and will appear to indicate that the VLANs are up and working when they are not. Attempting to change assignments fails as that part of the code detects the missing the VLAN parent.

The system should fail to boot with an interface assignment prompt when this happens, same as if any other interface is removed. At the very least it should disable/remove affected VLAN interfaces but that would be inconsistent with other behavior.

Related issues

Has duplicate Feature #12166: Dashboard Interfaces should show "physical" interface failures Duplicate07/26/2021

Actions #1

Updated by Jim Pingle over 1 year ago

  • Has duplicate Feature #12166: Dashboard Interfaces should show "physical" interface failures added
Actions #2

Updated by Louis B over 1 year ago


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



Actions #3

Updated by Jim Pingle over 1 year ago

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.

Actions #5

Updated by Jim Pingle over 1 year ago

  • Status changed from New to Pull Request Review
  • Target version set to 2.6.0
  • Plus Target Version set to 21.09
Actions #6

Updated by Louis B over 1 year ago


I object !!

- I am very glad that the system was still running even with the defect x520. That allowed the rest of the network to stay operational *!!! If the system had rejected the config, I would have had a much bigger problem:
  • 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!


Actions #7

Updated by Jim Pingle over 1 year ago

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.

Actions #8

Updated by Anonymous over 1 year ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #9

Updated by Viktor Gurov over 1 year ago

  • Assignee set to Viktor Gurov
Actions #10

Updated by Jim Pingle over 1 year ago

  • Plus Target Version changed from 21.09 to 22.01
Actions #11

Updated by Louis B over 1 year ago


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 :(



Actions #12

Updated by Jim Pingle over 1 year ago

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.

Actions #13

Updated by Louis B over 1 year ago


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!


Actions #14

Updated by Christopher Cope about 1 year ago

Behaves as expected on

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

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

Actions #15

Updated by Jim Pingle about 1 year ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF