Project

General

Profile

Actions

Feature #1571

closed

Interfaces completely reset when hardware is changed

Added by Mr Horizontal over 13 years ago. Updated over 12 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
06/01/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:

Description

I had a configuration that used 2 wireless cards (urtw) and had interfaces assigned. One of the urtw interfaces was configured, while the other was assigned but not enabled in pfSense.

When I removed one of the urtw devices (a USB wireless adapter), pfSense demanded the interfaces all be reassigned manually from the console as if I was setting up the machine rather than simply removing the offending interface in question.

This caused an immense problem as I have 11 interfaces configured (12 with the 2nd urtw), of which 3 include gigabit LAN (1x msk and 2x em), 1x wifi (urtw), and 7x OpenVPN interfaces. When I yanked the urtw, pfSense refused to assign the remaining interfaces according to the configuration, locking me out from remotely managing the box to fix the issue.

Like most firewalls, I operate this unit as a headless unit, so this caused me immense frustration to put a monitor and keyboard to it to fix the issue, and because this happened with a USB device that can easily just fall out of a machine, I think pfSense ought to be able to handle it.

As such, if an interface disappears, can you simply unassign the interface rather than resetting the ENTIRE interface configuration!

I'm using the Sun May 15 20:43:07 2011 snap.

Actions #1

Updated by Ermal Luçi over 13 years ago

  • Priority changed from Urgent to Normal
Actions #2

Updated by Chris Buechler over 13 years ago

  • Tracker changed from Bug to Feature
  • Target version deleted (2.0)
  • Affected Version changed from 2.0 to All

this is how things have always worked and how the system is intended to function. If you remove a physical interface you have to unassign it first to avoid that.

Actions #3

Updated by Mr Horizontal over 13 years ago

"this is how things have always worked" means that this is a far more serious bug than I first thought, and a fundamental design defect. A platform like pfSense that usually runs on headless machines with the NIC and web configurator / SSH as the primary interface should be fairly resilient to such changes, especially when a USB interface is involved. What kind of thinking was this to make it so purposely un-fault-tolerant?!

It's not that hard to keep a record of the NIC's hardware MAC address (or other L2 identifier) and simply unassign the interface automatically, though if it was the LAN interface, then and only then is it perhaps justifiable. For a WAN or OPT interface it most certainly is not.

Actions #4

Updated by → luckman212 about 13 years ago

Hmm, I would tend to agree with the OP on this matter. Seems like the firewall should be more fault-tolerant than going basically zombie if an interface is pulled. Consoles are not always available, in fact usually aren't. Is there any way to workaround this or are any changes planned that would mitigate this issue?

Actions #5

Updated by Jim Pingle over 12 years ago

  • Status changed from New to Rejected

Closing this, we already have #593 and #410 that cover both aspects of this. (Match by MAC, and Assign automatically)

Actions

Also available in: Atom PDF