PFSense DHCP Server doesn't work with RHEL 6 machines

renanb02

I have a DHCP Server working on PFSense 2.4.4. While it works perfectly with RHEL 7/CentOS 7 machines, it doesn't work on RHEL6/CentOS 6 (both with fixed IP or dynamic range).

This is what DHCP Server Logs show (IP and MAC are obfuscated):

DHCPREQUEST for xxx.xx.255.15 from aa:bb:cc:dd:ee:ff via bge0
DHCPACK on xxx.xx.255.15 to aa:bb:cc:dd:ee:ff via bge0
send_packet: Host is down
dhcp.c:3976: Failed to send 318 byte long packet over fallback interface.

Here is what service network restart shows in CentOS 6:

alt text

And here is what /var/log/messages shows (xxx.xxx.255.3 is the Pfsense DHCP Server address; xxx.xxx.255.1 is the default route; xxx.xxx.255.15 is the supposed address that should be bound to the machine):

Lastly, here is my PFSense server info if it helps:

BIOS Vendor: Dell Inc.
Version: 2.6.0
Release Date: Tue Oct 31 2017

Version 2.4.4-RELEASE (amd64)
built on Thu Sep 20 09:03:12 EDT 2018
FreeBSD 11.2-RELEASE-p3

CPU Type Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
24 CPUs: 2 package(s) x 6 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (inactive)

I've tried rebooting those Centos 6 machines, rebooting PFSense, and I made sure the machines and PFSense packages are all updated. Nothing works.

Any help is appreciated.

renanb02

After struggling with this I found this in DHCP Server option in PfSense:

Additional BOOTP/DHCP Options

I configured it like this:

alt text

Turns out DHCP wasn't providing the Subnet Mask to CentOS 6 instances and with this option enabled, the mask is appended to the lease file.

johnpoz

Sorry but NO...

How would you think this error

Failed to send 318 byte long packet over fallback interface.

Has anything to do with the mask of the IP for the client?

And your accepting that answer as correct on stacks - Sorry dude but NO...

renanb02

Hi, John. No need to be harsh.

I'm just explaining what solved the problem and got ride of those errors in the log, since other people might find themselves in the same situation. The errors aren't necessarily related, but are a consequence of this problem since the server and the machines are trying to communicate.

What we debugged here indicates that DHCP communicated with the machine, but it wasn't able to set the IP. When the DHCP Ack was sent, it couldn't find the host because it didn't have an IP.

johnpoz

No that did NOT solve your problem!!!

You post an error, then says something completely unrelated and also pointless, since the mask is always included in the offer.. fixed it... Which is just plain not correct.

Did you sniff to see what was in the offer after the discover?

chrismacmahon

I fired up a test VM of CentOS 6.10 minimal, got a DHCP address.

Were you able to pull a Packet Capture on the switch to see the DHCP transaction?

johnpoz

No he did not would be my guess, or he would of seen that the mask is already included in the offer..

renanb02

Yes, we checked the DHCP transaction. Let me be clearer: the mask wasn't appended to the lease file, even if the offer had the mask. With that option enabled, the mask is now appended to the lease file that dhclient script uses to set the IP.

chrismacmahon

Do you still have a copy of the pcap file that we can see?

Edit:
DHCP request should be in RFC1918 space, no need to obscure that data.