Project

General

Profile

Actions

Bug #7364

closed

VLAN disappears after reboot - assigned through shell

Added by Clinton Cory about 7 years ago. Updated about 7 years ago.

Status:
Resolved
Priority:
Normal
Category:
Interfaces
Target version:
Start date:
03/07/2017
Due date:
% Done:

100%

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

Description

When a VLAN interface is created and assigned as the LAN interface through the shell menu, it will disappear from config.xml after reboot. This reportedly is not an issue on older versions but I've not confirmed this. Testing was done on 2.3.3 with a SG-2220.

- Install pfSense 2.3.3 on the SG-2220
- When the shell menu comes up, select option 1 to assign interfaces
- Press 'y' when prompted to setup VLANs
- Enter the parent interface of the VLAN (ie: igb1)
- Enter VLAN tag (ie: 120)
- Press enter to skip creating another VLAN
- Set WAN interface (ie: igb0)
- Set LAN interface to the created VLAN (ie: igb1_vlan120)
- Proceed with applying changes

The LAN interface will show in the shell menu as belong to igb1_vlan120. This can also be found in config.xml. Issue a reboot command and the VLAN will be missing from config.xml and the interface list. The LAN interface will default back to the parent interface of igb1.

Actions #1

Updated by Phillip Davis about 7 years ago

I tried exactly this on a 2.3.3 VM and it works fine - I made em1_vlan42 and it got assigned to LAN and came back after reboot.
I wonder what is special about "igb" or the SG-2220 or ???

Actions #2

Updated by Chris Linstruth about 7 years ago

I can confirm this using an RCC-VE 2440 and both netgate factory and CE 2.3.3 images.

I believe this is due to running option 1 (and probably option 2) from the console does not remove /conf/trigger_initial_wizard which must cause some default interface assignment to occur on restart.

Workaround: Assigning VLANs followed by rm /conf/trigger_initial_wizard followed by a reboot left the VLANs (and, presumably, any custom interface assignments) intact.

This seems familiar and smells of regression but might not have ever been fixed from about a year ago.

Actions #3

Updated by Phillip Davis about 7 years ago

I could reproduce after doing a "reset to factory defaults" in the VM
PR https://github.com/pfsense/pfsense/pull/3626 fixes it for me.

Note: the workaround here (and often the "natural" workflow) is to use the console menu to set up the VLAN/s then access the webGUI (presumably over the VLAN just created, through a VLAN switch that is connected to the pfSense LAN...) and be presented with the initial setup wizard. You can go through the wizard or bypass it in the webGUI, either way the system knows the initial setup has been done, and the next bot is fine.

The problem is only evident if you use the console menu to set up the VLAN/s then reboot before accessing the webGUI.

Actions #4

Updated by Chris Linstruth about 7 years ago

Right.

This is probably not the place for this discussion but if a manual assignment is done in the web menu/CLI prior to entering the webgui and the setup wizard, all the console menu function has to do is unlink /conf/trigger_initial_wizard when it saves its work and everyone is happy and experiences the expected result.

I often do an initial interface configuration from the CLI. This only appears immediately after an install or factory reset.

Actions #5

Updated by Chris Linstruth about 7 years ago

Should have looked at your patch first. That is why I say IANAProgrammer.

Actions #6

Updated by Phillip Davis about 7 years ago

The initial setup wizard has other stuff for setting interface IPs, DNS servers and so on. So if someone sets their interface assignment from the console, we still want to present them with the wizard when they first login so they are prompted automagically to think about these other things.

Actions #7

Updated by Clinton Cory about 7 years ago

patch fails on 2.3.3 and 2.4

2.3:

--------------------------
/usr/bin/patch --directory=/ -t -p2 -i /var/patches/58c039ad4acfd.patch --check --forward --ignore-whitespace

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
|diff --git a/src/etc/inc/config.console.inc b/src/etc/inc/config.console.inc
|index bb2659e..1415e86 100644
|--- a/src/etc/inc/config.console.inc
|+++ b/src/etc/inc/config.console.inc
--------------------------
Patching file etc/inc/config.console.inc using Plan A...
Hunk #1 succeeded at 487 (offset 110 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/etc/rc.bootup b/src/etc/rc.bootup
|index f33b434..60919e0 100755
|--- a/src/etc/rc.bootup
|+++ b/src/etc/rc.bootup
--------------------------
Patching file etc/rc.bootup using Plan A...
Hunk #1 failed at 138.
1 out of 1 hunks failed while patching etc/rc.bootup
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/usr/local/www/wizards/setup_wizard.xml b/src/usr/local/www/wizards/setup_wizard.xml
|index 72363e2..ba6382a 100644
|--- a/src/usr/local/www/wizards/setup_wizard.xml
|+++ b/src/usr/local/www/wizards/setup_wizard.xml
--------------------------
Patching file usr/local/www/wizards/setup_wizard.xml using Plan A...
Hunk #1 failed at 35.
1 out of 1 hunks failed while patching usr/local/www/wizards/setup_wizard.xml
done

2.4:

/usr/bin/patch --directory=/ -t -p2 -i /var/patches/58c03ce3b281b.patch --check --forward --ignore-whitespace

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/etc/inc/config.console.inc b/src/etc/inc/config.console.inc
|index bb2659e..1415e86 100644
|--- a/src/etc/inc/config.console.inc
|+++ b/src/etc/inc/config.console.inc
--------------------------
Patching file etc/inc/config.console.inc using Plan A...
Hunk #1 succeeded at 377.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/etc/rc.bootup b/src/etc/rc.bootup
|index f33b434..60919e0 100755
|--- a/src/etc/rc.bootup
|+++ b/src/etc/rc.bootup
--------------------------
Patching file etc/rc.bootup using Plan A...
Hunk #1 failed at 138.
1 out of 1 hunks failed while patching etc/rc.bootup
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/usr/local/www/wizards/setup_wizard.xml b/src/usr/local/www/wizards/setup_wizard.xml
|index 72363e2..ba6382a 100644
|--- a/src/usr/local/www/wizards/setup_wizard.xml
|+++ b/src/usr/local/www/wizards/setup_wizard.xml
--------------------------
Patching file usr/local/www/wizards/setup_wizard.xml using Plan A...
Hunk #1 succeeded at 35.
done

Actions #8

Updated by Clinton Cory about 7 years ago

The previous error was due to a CE patch being applied to a factory image. Renato created a factory patch and I was able to confirm that it resolved the issue.

Actions #9

Updated by Renato Botelho about 7 years ago

  • Assignee set to Renato Botelho
  • Target version set to 2.3.3-p1
Actions #10

Updated by Phillip Davis about 7 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #11

Updated by Renato Botelho about 7 years ago

  • Status changed from Feedback to Resolved

Works

Actions

Also available in: Atom PDF