Project

General

Profile

Actions

Bug #1909

closed

dhcp dies after reboot

Added by Rob Lister over 12 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
DHCP (IPv4)
Target version:
-
Start date:
09/26/2011
Due date:
% Done:

0%

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

Description

Just upgraded to to NanoBSD release from a previous 2.x RC version.

When it reboots, it comes up okay, but clients are unable to get a DHCP lease.
DHCP service shows as stopped in status -> services.

Trying to restart thows this into the logs:

php: /status_services.php: The command '/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf bridge0' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.2.1-P1 Copyright 2004-2011 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ bad range, address 172.16.1.10 not in subnet 10.10.1.0 netmask 255.255.255.0 If you did not get this software from ftp.isc.org, please get the latest from ftp.isc.org and install that before requesting help. If you did get this software from ftp.isc.org and have not yet read the README, please read it before requesting help. If you intend to request help from the mailing list, please read the section on the README about submitting bug reports and requests for help. Please do not under any circumstances send requests for help directly to the authors of this software - please send them to the appropriate mailing list as des
Sep 26 22:14:27 dhcpd: exiting.
Sep 26 22:14:27 dhcpd: exiting.
Sep 26 22:14:27 dhcpd:
Sep 26 22:14:27 dhcpd:

The IP of the bridged interface isand always has been 172.16.1.1

And the DHCP server range configured is 172.16.1.10 - 172.16.1.199

If I go into the interface configuration, do not change anything but click "Save" followed by Apply Changes,
the DHCP service starts successfully.


Files

Actions #1

Updated by Chris Buechler over 12 years ago

  • Target version changed from 2.0 to 2.0.1

can you attach your config?

Actions #3

Updated by Jim Pingle over 12 years ago

Look in /var/run/*.pid - see if there are any stale (old) pid files. It's possible something else is getting a killbypid() of a stale file there and dhcpd just happens to have that pid now.

Actions #4

Updated by Rob Lister over 12 years ago

[2.0-RELEASE][]/var/run(9): cat dhcpd.pid
[2.0-RELEASE][]/var/run(10):

[2.0-RELEASE][]/var/run(10): ps xaguwww | grep dhcp
root 44921 0.0 1.0 4944 2468 ?? Ss 10:14PM 0:00.36 /usr/sbin/syslogd -c -c -l /var/dhcpd/var/run/log -f /var/etc/syslog.conf
dhcpd 52817 0.0 2.5 8436 6056 ?? Ss 10:21PM 0:00.08 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf bridge0

[2.0-RELEASE][]/var/run(4): date
Mon Sep 26 22:34:04 BST 2011

[2.0-RELEASE][]/var/run(5): ls arlt
total 32
-r--r--r-
1 root wheel 157 Sep 26 22:08 ld-elf.so.hints
srwxr-xr-x 1 root wheel 0 Sep 26 22:08 check_reload_status
srw-rw-rw- 1 root wheel 0 Sep 26 22:08 devd.pipe
rw------ 1 root wheel 3 Sep 26 22:09 devd.pid
rw-r--r- 1 root wheel 6 Sep 26 22:09 sshd.pid
rw-r--r- 1 root wheel 6 Sep 26 22:09 lighty-webConfigurator.pid
rw------ 1 root wheel 5 Sep 26 22:09 inetd.pid
drwxr-xr-x 12 root wheel 512 Sep 26 22:09 ..
rw------ 1 root wheel 5 Sep 26 22:09 cron.pid
rw-r--r- 1 root wheel 6 Sep 26 22:09 update_alias_url_data.pid
rw-r--r- 1 root wheel 6 Sep 26 22:09 ping_hosts.pid
rw-r--r- 1 root wheel 6 Sep 26 22:09 expire_accounts.pid
srw------- 1 root wheel 0 Sep 26 22:14 logpriv
srw-rw-rw- 1 root wheel 0 Sep 26 22:14 log
rw------ 1 root wheel 5 Sep 26 22:14 syslog.pid
rw-r--r- 1 root wheel 6 Sep 26 22:21 dnsmasq.pid
rw-r--r- 1 root wheel 0 Sep 26 22:21 dhcpd.pid
rw-r--r- 1 root wheel 6 Sep 26 22:21 apinger.pid
drwxr-xr-x 2 root wheel 512 Sep 26 22:21 .
rw-r--r- 1 root wheel 4 Sep 26 22:21 filter_reload_status
rw-r--r- 1 root wheel 132 Sep 26 22:33 utmp

This gives me a thought.. I will try to reboot and see what these states and and dhcpd.conf looks like before I do the save interface settings and apply.

Rob

Actions #5

Updated by Rob Lister over 12 years ago

Hmm, okay.

After reboot, the SSH admin reports wrong IP address for INSIDE (bridge0) but web interface
reports what I set, (172.16.1.1)

Password:
  • Welcome to pfSense 2.0-RELEASE-nanobsd (i386) on pfcafe ***
WAN (wan)                 -> vr0        -> 78.33.236.29
LAN2 (lan) -> vr1 -> NONE
WLAN (opt1) -> ath0_wlan1 -> NONE
LAN1 (opt2) -> vr2 -> NONE
INSIDE (opt3) -> bridge0 -> 10.10.1.1
WLANPRIVATE (opt4) -> ath0_wlan2 -> NONE
0) Logout (SSH only)                  8) Shell
1) Assign Interfaces 9) pfTop
2) Set interface(s) IP address 10) Filter Logs
3) Reset webConfigurator password 11) Restart webConfigurator
4) Reset to factory defaults 12) pfSense Developer Shell
5) Reboot system 13) Upgrade from console
6) Halt system 14) Disable Secure Shell (sshd)
7) Ping host

The actual interface config looks like:

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether f2:b3:bc:18:fe:d1
inet 10.10.1.1 netmask 0xffffff00 broadcast 10.10.1.255
inet 172.16.1.1 netmask 0xffffff00 broadcast 172.16.1.255
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: vr2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 3 priority 128 path cost 55
member: ath0_wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 370370
member: vr1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 55

After I click "Save" and "Apply Changes" in the web GUI, the two addresses flip round:

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether f2:b3:bc:18:fe:d1
inet 172.16.1.1 netmask 0xffffff00 broadcast 172.16.1.255
inet 10.10.1.1 netmask 0xffffff00 broadcast 10.10.1.255
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: vr2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 3 priority 128 path cost 55
member: ath0_wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 370370
member: vr1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 55

After rummaging around in the config, it would appear there is an ifalias set for 10.10.1.1

Actions #6

Updated by Chris Buechler over 12 years ago

  • Target version deleted (2.0.1)
Actions #7

Updated by Michael Newton about 12 years ago

I see the same issue trying to run DHCP on an interface with an alias. Removing the alias gets everything working again. I imagine it's owing to the order in which pfSense adds the address information to the interface. The alias address should come last I'm guessing.

Actions #8

Updated by Jim Pingle about 11 years ago

  • Status changed from New to Feedback

There was some work to solve a similar issue with ordering and aliases on 2.1 recently, worth trying there, it's likely fixed now.

Actions #9

Updated by Chris Buechler over 9 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF