PfSense 2.3: DHCP not working on newly added interface: wrong args for dhcpd



  • I just had a strange problem while adding a new isolated VLAN to our network with the DHCP server: This was the fourth new VLAN that has been added in the past months. All with identical rules and identical configuration on different subnets. All VLANs have their own DHCP pool. The DCHP server was configured and enabled on the new VLAN, but wasn't broadcasting on the interface network. After manually configuring IP and routes on the client I could ping the interface and external IPs, so I figured that this was either a problem with the firewall rules (which are identical to the rules for the previously created VLANs where DHCP was working flawlessly) or with the DHCP server not responding to requests on the new interface.

    I looked at /var/dhcpd/etc/dhcpd.conf and found the new VLAN configuration:

    subnet 10.223.8.0 netmask 255.255.255.0 {
            pool {
                    option domain-name-servers 8.8.8.8,8.8.4.4;
                    range 10.223.8.100 10.223.8.199;
            }
    
            option routers 10.223.8.1;
            option domain-name-servers 8.8.8.8,8.8.4.4;
    
    }
    

    I looked at the process list (ps aux from the shell) if the interface had been passed as argument to the dhcpd process, and though the checkbox in the web interface said "enabled", the interface list passed to the process didn't contain the new VLAN.

    
    /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid bridge0 lagg0_vlan3 lagg0_vlan7 lagg0_vlan8 lagg0_vlan9
    
    

    There should be a "lagg0_vlan10" argument passed to the process, but wasn't. To check if this had something to do with the argument count, I temporarily disabled vlan8 and restarted the server via web interface. Nothing changed, vlan8 remained activated and vlan10 was still missing. I re-enabled the new VLAN interface and restarted again.
    Again, nothing changed. I then stopped the DHCP server and made sure the process wasn't running anymore. After starting the DHCP server again, the passed interfaces finally matched the enabled interfaces:

    
    /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid bridge0 lagg0_vlan3 lagg0_vlan7 lagg0_vlan8 lagg0_vlan9 lagg0_vlan10
    
    

    I didn't analyze this issue any further and it didn't occur again after stopping and starting the DHCP server. I think that I hit a state where enabling and disabling the DHCP servers didn't update some sort of cache that stores the states of the DHCP and which is used when constructing the process command list.

    I leave this report here for anyone running into the same issue. I'm not sure if I collected enough data to justify a bug ticket yet.



  • I just ran into the exact same issue when creating new vlan interfaces.  At first I tried just restarting the dhcp service but that did not help. I had to do a full stop and start of the service then the proper interfaces were part of the parameter set as you described.

    2.3.2-RELEASE (amd64)


Log in to reply