Unbound DHCP registration checkbox bug?

Ender117

no it's full of hosts

RonpfS

Maybe save the DHCP server settings?

Ender117

@ronpfs

That doesn't change anything.

Can anyone reproduce this? if yes I would go file a bug report

Gertjan

@ronpfs said in Unbound DHCP registration checkbox bug?:

Maybe save the DHCP server settings?

That, for sure, will regenerate the /var/unbound/dhcpleases_entries.conf file (DHCP leases) as the /var/unbound/host_entries.conf.conf file (contains static DHCP leases and other 'fixed' host names).
These files are created and maintained by the DHCP server(s).
Side effect : unbound is also restarted when DHCP server is saved, thus restarted.

I guess you can find the reply here : /etc/inc/system.inc : function system_dhcpleases_configure()
When "DHCP Registration" is set, a process called dhcp_leases will be created that controls unbound for rereading the leases (like restarting it ...)

This process exists when I check "DHCP Registration" :

33397  -  Is       0:00.05 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d my-pfsense-domain.tld -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts

This is the one that does the syncing between the DHCP server and unbound, the resolver.

Btw : I'm not 100 %, but already digging in there for the last ... 10 years or so.

Ender117

@gertjan
Thanks for the insight, though changing/saving DHCP setting didn't do anything for me. I will go check the process you mentioned when I got home.

I thought that when you uncheck "DHCP registration" it would comment out

include: /var/unbound/dhcpleases_entries.conf

that was the most intuitive to me.

Ender117

So I sshed in and rm the files, that fixed the problem. But if I check these boxes and then uncheck, the problem comes back. looks like a GUI bug to me

RonpfS

The line is present with the box unchecked
The file dhcpleases_entries.conf should be empty when it's unchecked.

Ender117

@ronpfs
yeah but look at my post above, what's in /var/unbound/dhcpleases_entries.conf remains unchanged with the box checked or unchecked. At least for me

RonpfS

@ender117 Did you check the box, save, uncheck the box save.
Both Unbound and DHCP server should restart when you save.

Do the same with DHCP Server settings.

Ender117

@ronpfs Yes I did saved and applied changes. DHCP server setting only allow me to save though

RonpfS

@ender117 Well have a look at the System Log to see if the services restart.

You can restart DHCP server from the Status / Services tab.

Ender117

@ronpfs restarted DHCP service while the box unchecked. Didn't clear that file as it suppose to

RonpfS

@ender117 Maybe it's time to provide more info about you pfsense box: version, hardware, packages, etc

Gertjan

@ronpfs said in Unbound DHCP registration checkbox bug?:

@Ender117 ender117 Maybe it's time to provide more info about you pfsense box: version, hardware, packages, etc

What @Ender117 sees, is what I see. Its part of pfSense current (2.4.3_1) behavior.
Installed packages, or not, the issue is the same (except if packages start to modify system files like /etc/inc/system.inc etc).

What happens can be seen here : function system_dhcpleases_configure() in /etc/inc/system.inc :
https://github.com/pfsense/pfsense/blob/7c15c19d76eac725c42133012488cb97e4dcd885/src/etc/inc/system.inc#L572

First, the main issue :

0_1536816313441_755e8c98-12d2-4b03-bea0-c36e89ab2315-image.png

My "DHCP Registration" is not checked.
Still, my unbound config file will include this file /var/unbound/dhcpleases_entries.conf, which contains leases - this is ok : but it should be empty in this case. And that's NOT the case.

# dhcpleases automatically entered
local-data: "iPhonevhristine.brit-hotel-fumel.net IN A 192.168.2.34"
local-data-ptr: "192.168.2.34 iPhonevhristine.brit-hotel-fumel.net"
local-data: "MBP-de-manu.brit-hotel-fumel.net IN A 192.168.2.162"
local-data-ptr: "192.168.2.162 MBP-de-manu.brit-hotel-fumel.net"
local-data: "iPhone-de-Julie.brit-hotel-fumel.net IN A 192.168.2.196"
local-data-ptr: "192.168.2.196 iPhone-de-Julie.brit-hotel-fumel.net"
local-data: "iPaddeVeronique.brit-hotel-fumel.net IN A 192.168.2.131"
local-data-ptr: "192.168.2.131 iPaddeVeronique.brit-hotel-fumel.net"
local-data: "android-b094ac578001045c.brit-hotel-fumel.net IN A 192.168.2.18"
local-data-ptr: "192.168.2.18 android-b094ac578001045c.brit-hotel-fumel.net"
local-data: "PO130022159.brit-hotel-fumel.net IN A 192.168.2.64"
local-data-ptr: "192.168.2.64 PO130022159.brit-hotel-fumel.net"
local-data: "Galaxy-S9.brit-hotel-fumel.net IN A 192.168.2.35"
local-data-ptr: "192.168.2.35 Galaxy-S9.brit-hotel-fumel.net"
local-data: "android-fdd7cf6422a374a4.brit-hotel-fumel.net IN A 192.168.2.88"
local-data-ptr: "192.168.2.88 android-fdd7cf6422a374a4.brit-hotel-fumel.net"
local-data: "Galaxy-Tab-S2.brit-hotel-fumel.net IN A 192.168.2.71"
local-data-ptr: "192.168.2.71 Galaxy-Tab-S2.brit-hotel-fumel.net"

Why ?

It all happens on a day, when we decided to check "DHCP Registration" and Save :

0_1536816745444_59c5db87-1f3b-4160-8d3b-842916e51140-image.png

The file /var/unbound/dhcpleases_etries.conf will get created, and a process called "dhcpleases" is started that syncs new incoming leases from the DHCP server into our /var/unbound/dhcpleases_etries.conf file- and when this happens, unbound (or the Forwarder) is restarted to take changes into account and all life happy together.

Maybe "DHCP Registration" for the Resolver and Forwarder are checked by default, when we installed pfSense ?

Now, the interesting part. we uncheck "DHCP Registration" - and Save + Apply.
The function system_dhcpleases_configure() doesn't do much anymore. The file /var/unbound/dhcpleases_entries.conf stays in place with our leases that existed at the moment "DHCP Registration" was unchecked. The file is not maintained by nothing anymore.
Forwarder or Resolver continues including and using the content. And this is (seems ,) wrong.

Or, and here it is :
If "DHCP Registration" is unchecked,, /var/unbound/dhcpleases_entries.conf should be flushed.
That's it.

I'm running this code now :

At the end of the function system_dhcpleases_configure()

} else if (isvalidpid($pidfile)) {
		sigkillbypid($pidfile, "TERM");
		@unlink($pidfile);
		}
	} 
}

I put in place :

} else if (isvalidpid($pidfile)) {
		sigkillbypid($pidfile, "TERM");
		@unlink($pidfile);
		}
	} else {
		if ((isset($config['dnsmasq']['enable']) && !isset($config['dnsmasq']['regdhcp'])) ||
			(isset($config['unbound']['enable']) && !isset($config['unbound']['regdhcp']))) {
				mwexec("truncate -s 0 {$g['unbound_chroot_path']}/dhcpleases_entries.conf");
		}
	}
}

edit 2018-09-19 : same / simpler / better :

	} else {
		if (isvalidpid($pidfile)) {
				sigkillbypid($pidfile, "TERM");
				@unlink($pidfile);
			}
		if (file_exists("{$g['unbound_chroot_path']}/dhcpleases_entries.conf"))
			mwexec("truncate -s 0 {$g['unbound_chroot_path']}/dhcpleases_entries.conf");
	}	
}

=> If running, kills the dhcpleases process.
=> Truncates (empties) the dhcpleases_entries.conf file

Now, when "DHCP Registration" is unchecked the file /var/unbound/dhcpleases_entries.conf exist (has to exist) and is empty.

Ender117

@gertjan Ahhh, glad to see someone else had looked at the same problem. And thanks for describe the problem more thoroughly and provide a solution.

Do you know if there was a bug report for this? Would be nice if your solution goes official.

Ender117

@gertjan If you don't have time for a bug report, would you mind me go ahead to file one and quote you there?

RonpfS

@ender117 Why don't you empty /var/unbound/dhcpleases_entries.conf for now ?

You can do that in Diagnostics / Edit File or run a in shell prompt :

/usr/bin/truncate -s 0 /var/unbound/dhcpleases_entries.conf

Ender117

@ronpfs I had already fixed the problem manually, but thanks for your kind suggestion anyway. I just believe this is a bug and would like to let the developers know.

Gertjan

@ender117
I agree, but I prefer not to add new bug right now. They are finalizing 2.4.4.
I still need to check if it isn't possible to propose another solution - and if this solution doesn't provoke unwanted side-effect.
I hope you agree with me that this is a minor problem (now it solved).

Ender117

@gertjan

Yeah I guess you are right. I would be better to let them finish 2.4.4 first, which I heard that first RC should be out next week. Maybe it will get fix then, who knows.