Broken DHCP in 152

I’m having an issue with DHCP in Core 152. I am re-posting this issue from the security area since initially I thought this was a security related issue, but it is more of a networking thing
12/21 - AM -------
I came into work this morning to find that multiple people had DNS issues resolving names that normally have no problems, and nobody could get into our ERP system. I rebooted the clients, and I rebooted the ERP database server, and I shut down a clone of the ERP Database server that I started to set up, which fixed the issue.

The name was not fully qualified domain names (public), just internal only. The name in question was dylanschoeneck.inside.my-domain-name.com Normally the names resolve without any problems. I could ping the IP address of the machine without issue, but I could not ping by name using just the dylanschoeneck or the full domain name.

I had further problems later in the day with IP addresses. Note I am on IPFire 2.25(x86_64 Core update 152. I had one machine named BRIANHAYES10. This is a pretty standard Dell XPS Windows 10 Pro machine, with a DHCP Reservation of 10.5.1.108.

He was having problems with network drives that were online, then 10 seconds later offline, then online, then offline. At first I thought his machine had a virus, but full scans with two different tools revealed nothing.

I then looked in IPFire and there was a second mac address that was listed with the same IP address 10.5.1.108 even WITH the reservation entry saved and in use in the DHCP area!?!

The other machine was a vmware virtual machine that I had just set up to test out CentOS Stream. The CentOS box was just set to DHCP, and I had not configured any reservations for that mac address yet.

I then looked back at the DHCP area and noticed there was not just one, but 14 different entries for Brian’s machine:

Note - the line was not through the date/time area on the right of the DHCP page indicating the lease expired, it looked ative like a normal lease

This morning I updated drivers, ran windows updates and did a full malware scan with two tools on his machine, to rule out foul play on the PC side, no malware found.

The other thing that I discovered today was that I was setting up some new DHCP reservations, and I mistakenly typed in the same IP address for multiple mac addresses, and the system LET me save that entry. Previous IPFire versions did not allow you to post two DHCP reservations to the same IP address, this one did. I do not know where the files are in the background or how to restart the services from the shell or where the log file is for entry results, perhaps /var/log/messages?

I wanted to post this specifically here because something is seriously broken with DHCP in this release.

Has anyone else experienced weird issues like this?

I posted in your previous post before I saw that you had started this in a new section.

Having read what you have put above, it seems that BRIANHAYES10 has a fixed lease allocated but that it is showing up in the dynamic leases section. I have not seen that happen.

Just as a check, can you confirm that all of your fixed leases do not overlap into the dynamic range that you have set. The fixed and dynamic sets of ip addresses must always be separate sets. That is something that IPFire does not currently check for and flag up but has been registered in the IPFire bugzilla.

If your dynamic and fixed ip addresses are completely separate sets then I don’t understand what could be driving the effects that you are seeing.

1 Like

@cwensink I’ve seen similar issues, as @bonnietwin wrote, there is conflict between static and dhcp offered ip’s. I have a short script in my ipfire console, this usually clears any conflicts.

Sometimes, I have to stop DHCP from the WUI, all dhcp entries are gone, start DHCP again, then one by one as the systems renew, they appear in the DHCP table (and all the crossed-out entries are gone)

/etc/init.d/dhcp stop
sleep 2
/etc/init.d/dhcp start
sleep 2
/etc/init.d/unbound restart

I can try that but I’ll have to wait until after normal business hours. Thanks for the suggestion.

Chris