2.0.2: Bug if DHCP server is configured from text-mode serial console

martin42

Hi, nice work with 2.0.2. Just wanted to report a small DHCP bug with initial text-mode setup over the serial port…

SETUP:
During initial setup (512M nanobsd version) via the serial port on a Soekris 5501 box, I used the text-mode console to enable the DHCP server on the LAN interface. I specified my x.x.x.x/27 net block as the LAN range, giving the uppermost 17 IP addresses as the range for my LAN DHCP clients.

PROBLEM:
The DHCP IP range is not set up correctly (parsing problem?).
Also, the IP address of the firewall is changed to one of the DHCP range numbers.
Also, the IP address of the firewall is changed again after rebooting the firewall.

WORKAROUND:
Don't configure DHCP during the initial text-mode setup. Just use fixed IPs, then start the web configurator. Once the DHCP settings are entered into the web configurator, everything works perfectly :)

ASIDE:
There is no warning if you are stupid enough to install a nanobsd image that's too big for your device. For example, if you install the 1GB CF card image onto a 512 MB CF card, then the pfSense does appear to work OK in many regards, but some things won't work (because some changes can't be saved). In an ideal world it would be nice to see lots of warning messages if the filesystem sizes are actually bigger than the physical media.

Many thanks for such a solid product :-)

neewbie

Have you tried resetting state?
For me its work.

wallabybob

@martin42:

ASIDE:
There is no warning if you are stupid enough to install a nanobsd image that's too big for your device. For example, if you install the 1GB CF card image onto a 512 MB CF card, then the pfSense does appear to work OK in many regards, but some things won't work (because some changes can't be saved). In an ideal world it would be nice to see lots of warning messages if the filesystem sizes are actually bigger than the physical media.

The software that writes the image to the CF should report if you try to write an image to a CF that is "too small". Did you miss that report?

jimp

If you could reproduce this again I'd like to know what exactly was typed in each question/step of the console config to enable DHCP when you saw this issue.

martin42

Hi,

Thanks for taking a look at this…

The good news is: I was able to reproduce the problem, after resetting to factory defaults and experimenting (see first quoted block below).

The bad news is: I also found a new bug with that option 2 of the text-mode menu (see second quoted block below).

Hope this is useful ;-)

*** Welcome to pfSense 2.0.2-RELEASE-nanobsd (i386) on pfSense ***

WAN (wan) -> re0 -> NONE (DHCP)
LAN (lan) -> vr1 -> NONE
OPT1 (opt1) -> vr0 -> 192.168.168.1

Logout (SSH only) 8) Shell

Assign Interfaces 9) pfTop

Set interface(s) IP address 10) Filter Logs

Reset webConfigurator password 11) Restart webConfigurator

Reset to factory defaults 12) pfSense Developer Shell

Reboot system 13) Upgrade from console

Halt system 14) Enable Secure Shell (sshd)

Ping host

Enter an option: 2

Available interfaces:

1 - WAN
2 - LAN
3 - OPT1

Enter the number of the interface you wish to configure: 2

Enter the new LAN IPv4 address. Press <enter>for none:

123.123.123.161

Subnet masks are entered as bit counts (as in CIDR notation) in pfSense.
e.g. 255.255.255.0 = 24
255.255.0.0 = 16
255.0.0.0 = 8

Enter the new LAN IPv4 subnet bit count:

27

Do you want to enable the DHCP server on LAN? [y|n] y
Enter the start address of the client address range: 123.123.123.174
Enter the end address of the client address range: 123.123.123.190

Please wait while the changes are saved to LAN… Reloading filter...
DHCPD...

The IPv4 LAN address has been set to 123.123.123.161/27
You can now access the webConfigurator by opening the following URL in your web browser:
http://123.123.123.161/

Press <enter>to continue.
*** Welcome to pfSense 2.0.2-RELEASE-nanobsd (i386) on pfSense ***

WAN (wan) -> re0 -> NONE (DHCP)
LAN (lan) -> vr1 -> 123.123.123.161
OPT1 (opt1) -> vr0 -> 192.168.168.1

Logout (SSH only) 8) Shell

Assign Interfaces 9) pfTop

Set interface(s) IP address 10) Filter Logs

Reset webConfigurator password 11) Restart webConfigurator

Reset to factory defaults 12) pfSense Developer Shell

Reboot system 13) Upgrade from console

Halt system 14) Enable Secure Shell (sshd)

Ping host

Enter an option: 8

[2.0.2-RELEASE][root@pfSense.localdomain]/root(1): ifconfig vr1
vr1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:00:24:c8:b1:a5
inet6 fe80::200:24ff:fec8:b1a5%vr1 prefixlen 64 scopeid 0x2
inet 123.123.123.174 netmask 0xffffffe0 broadcast 123.123.123.191
nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active

^^^ The IP address of "vr1" has been set to .174 (first IP in DHCP range), not to .161 as requested

^^^ We can access webconfigurator on .174
^^^ Clicking 'next' lots of times in webconfigurator changes IP to .161 as requested
^^^ After rebooting and logging into webconfigurator again, "Services/DHCP Server" shows that DHCP range is still wrong…:

Subnet 123.123.123.160
Subnet mask 255.255.255.224
Available range 123.123.123.161 - 123.123.123.190
Range 123.123.123.10 to 123.123.123.181</full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast></enter></enter>

So there's something a bit strange happening.

Also…. During my experiments, I found another bug on the serial port text-mode console...
This time the option "2) Set interface(s) IP address" changed the assignment of physical NICs to logical interfaces...

*** Welcome to pfSense 2.0.2-RELEASE-nanobsd (i386) on pfsense ***

WAN (wan) -> pppoe0 -> 81.187.163.40 (PPPoE)
LAN (lan) -> vr1 -> 217.169.18.161
VOICE (opt1) -> vr0 -> 81.187.9.113

Logout (SSH only) 8) Shell

Assign Interfaces 9) pfTop

Set interface(s) IP address 10) Filter Logs

Reset webConfigurator password 11) Restart webConfigurator

Reset to factory defaults 12) pfSense Developer Shell

Reboot system 13) Upgrade from console

Halt system 14) Enable Secure Shell (sshd)

Ping host

Enter an option: 2

Available interfaces:

1 - WAN
2 - LAN
3 - VOICE

Enter the number of the interface you wish to configure: 2

Enter the new LAN IPv4 address. Press <enter>for none:

217.169.18.161

Subnet masks are entered as bit counts (as in CIDR notation) in pfSense.
e.g. 255.255.255.0 = 24
255.255.0.0 = 16
255.0.0.0 = 8

Enter the new LAN IPv4 subnet bit count:

27

Do you want to enable the DHCP server on LAN? [y|n] y
Enter the start address of the client address range: 217.169.18.174
Enter the end address of the client address range: 217.169.18.190

Please wait while the changes are saved to LAN… Reloading filter...
DHCPD...

The IPv4 LAN address has been set to 217.169.18.161/27
You can now access the webConfigurator by opening the following URL in your web browser:
http://217.169.18.161/

Press <enter>to continue.
*** Welcome to pfSense 2.0.2-RELEASE-nanobsd (i386) on pfsense ***

WAN (wan) -> pppoe0 -> 81.187.163.40 (PPPoE)
LAN (lan) -> re0 -> 217.169.18.161
VOICE (opt1) -> vr0 -> 81.187.9.113</enter></enter>

So, my previous assignment of re0 / vr1 / vr0 for WAN / LAN / VOICE was corrupted.

I've worked around this by using the Webconfigurator, which works perfectly :-)

Hope this helps.

Kind regards

Martin

jimp

Hmm, I can't reproduce that at all.

Available interfaces:

1 - WAN
2 - LAN
3 - GRETEST

Enter the number of the interface you wish to configure: 2

Enter the new LAN IPv4 address.  Press <enter> for none:
> 123.123.123.161

Subnet masks are entered as bit counts (as in CIDR notation) in pfSense.
e.g. 255.255.255.0 = 24
     255.255.0.0   = 16
     255.0.0.0     = 8

Enter the new LAN IPv4 subnet bit count:
> 27

Do you want to enable the DHCP server on LAN? [y|n]  y
Enter the start address of the client address range: 123.123.123.174
Enter the end address of the client address range: 123.123.123.190

Do you want to revert to HTTP as the webConfigurator protocol? (y/n) n

Please wait while the changes are saved to LAN... Reloading filter...
 DHCPD...

The IPv4 LAN address has been set to 123.123.123.161/27
You can now access the webConfigurator by opening the following URL in your web browser:
                https://123.123.123.161/

Press <enter> to continue.
[...]
em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 08:00:27:f3:bc:84
        inet6 fe80::a00:27ff:fef3:bc84%em1 prefixlen 64 scopeid 0x2 
        inet 123.123.123.161 netmask 0xffffffe0 broadcast 123.123.123.191
        nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

: cat /var/dhcpd/etc/dhcpd.conf 
[...]
subnet 123.123.123.160 netmask 255.255.255.224 {
        pool {
                range 123.123.123.174 123.123.123.190;
        }
        option routers 123.123.123.161;
        option domain-name-servers 123.123.123.161;
}</full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast></enter></enter>

I tried it twice with two different subnets and the only change was exactly what I entered, and it was applied exactly as I entered it.

If you do a config diff in the GUI (Diag > Backup/Restore, Config History tab) what does it look like going between the step when it started and when it was set?

I know some others had seen the interface assignment shift before, I know some work went into fixing that on 2.1.

Tracing through the code I don't see anywhere where it would be possible for the interface IP and DHCP settings to get flipped either. They are read into separate variables and they don't seem to have any opportunity to stomp on each other.

martin42

Hi,

I'm thinking the exact sequence of commands is probably a factor. Sorry I don't have more detailed logs or config files to diff (I've restored by normal config to get my ADSL working again).

Since there were changes in this area for 2.1, perhaps we should ignore this bug for now, unless other users can provide better information.

Best wishes for the new year.

Martin