Project

General

Profile

Bug #3209

editing VLAN tag on OPT interface changes LAN interface instead

Added by Adam Thompson over 5 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
Interfaces
Target version:
Start date:
09/17/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
All
Affected Architecture:

Description

Changing the VLAN tag on my [renamed] OPT interface from "3" to "202" (to accommodate a change my upstream made) actually changed the VLAN tag on the [renamed] LAN interface instead.
I verified this in /conf/config.xml on the console, and fixed it by editing /conf/config.xml and rebooting.
(On a related note, the Developer Console appears to be non-functional now. Is there another way to reload config from the console?)
I'm going to re-test now just to make sure this isn't a PEBKAC issue.

Associated revisions

Revision 1c32fb7e (diff)
Added by Phillip Davis over 3 years ago

Fix #3209 editing unassigned VLAN tag can change an assigned interface

To reproduce:
a) Create VLAN 10 on some real device (e.g. em0)
b) Create VLAN 11 similarly.
c) Assign VLAN 11 (the last one in the vlan array in the config) to OPT1.
d) Edit VLAN 10 tag to be 12.
The OPT1 assignment becomes to em0 tag 12.

This is because of the wrong reference to $vlan['vlanif'] that is fixed here. At this point $vlan is a leftover from a previous loop that went through all the VLANs in the config - so it happens to be the last one from the config.

Hopefully this fixes all the various ways people have reported this in redmine #3209.

Revision b8ccb1ea (diff)
Added by Phillip Davis over 3 years ago

Fix #3209 properly

The small change I made previously was not all of it - but it did avoid the previous problem by (accidentally) referring to the (undefined) $a_vlan array! I should actually pay more attention to the detail.
This should be even better :)

Revision ddba2645 (diff)
Added by Phillip Davis over 3 years ago

Fix #3209 editing unassigned VLAN tag can change an assigned interface - RELENG_2_2

Might as well fix this bug in 2.2.* as well, since it is easy and was obviously an error.

History

#1 Updated by Adam Thompson over 5 years ago

Sadly, I've just confirmed this... and also confirmed that IT DOESN'T HAPPEN EVERY SINGLE TIME! WTF?!?
I changed OPT1/RD_LOM_DIST from 202 back to 3 - no problem.
I changed OPT1/RD_LOM_DIST from 3 back to 202 - no problem.
I then changed OPT1/RD_LOM_DIST from 3 to 203 - and blew away my LAN/HOMEPRIVATE interface.
In config.xml, my LAN interface got changed from lagg0_vlan4 to lagg0_vlan203 while OPT1 remained at lagg0_vlan202.

Things I'm doing differently: all my interfaces are VLAN subifs of lagg0.
I can attach my (working) config.xml if needed - once I figure out how to strip passwords. Or I can send it directly to someone if needed, as-is.

#2 Updated by Shahid Sheikh over 5 years ago

I am seeing this too. My workaround has been to fix the assignment from the Interfaces: Assign network ports: Interface assignments tab. As far as I can tell, its always the last two entries that get incorrect assignments.

As far as it not happening every single time - to me it was happening every time when creating new VLANs.

And if you are not paying attention and reboot the firewall then the firewall doesn't come up because of interface assignment mismatch. It sits at bootup at configuring interfaces.

#3 Updated by Adam Thompson over 5 years ago

Not verified (and I'm not going to break this firewall again just to check it), but I also believe that at some point, editing one of the VLAN subinterfaces changed the LAG members of the parent interface; during debugging, I noticed that one reason my LAG wasn't coming back up was that only em0 was a member. I am 100% certain that em1 was also a member when I started testing, as I had verified LACP partner status on both links from the switch.

#4 Updated by Chris Buechler over 4 years ago

  • Assignee set to Chris Buechler
  • Affected Documentation 0 added

#5 Updated by Chris Buechler over 3 years ago

  • Category set to Interfaces

#6 Updated by Phillip Davis over 3 years ago

This looks like it has been just a plain old dumb bug - https://github.com/pfsense/pfsense/pull/2601

#7 Updated by Phillip Davis over 3 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#8 Updated by Chris Buechler over 3 years ago

  • Status changed from Feedback to Resolved
  • Target version set to 2.3
  • Affected Version changed from 2.1 to All

Thanks Phil! never happened to hit that circumstance in trying to replicate this, but that's clearly the issue.

Also available in: Atom PDF