DHCP lease screen not loading

viniciusferrao

@gertjan said in DHCP lease screen not loading:

@viniciusferrao said in DHCP lease screen not loading:

DNS pointing to 127.0.0.1 and those aquired from WAN.

You've checked :

![137056bf-d384-4390-bd8a-f2705791f859-image.png](Something went wrong while parsing server response)

Do you know why ?

The attached image is not loading, I could not see it. :(

Use the console or SSH access.
Goto (cd) to /var/dhcpd/var/db/
What is the size of the /var/dhcpd/var/db/dhcpd.leases file ?

There you go:

[22.05-RELEASE][root@firewall.local.domain.example]/var/dhcpd/var/db: du -sh *
 33K	dhcpd.leases
 33K	dhcpd.leases~
512B	dhcpd6.leases

A test :
Open / edit /etc/inc/system.inc
Got around line 747.
Find
						$hostname = gethostbyaddr($item['ip']);
replace it by
//						$hostname = gethostbyaddr($item['ip']);
and test.
The DHCP leases page shows up now ?

Yes, this fixes the issue, which confirms that's DNS related.

The problem now is how to debug it, which entry is causing the issue.

[22.05-RELEASE][root@firewall.local.domain.example]/var/dhcpd/var/db: cat /etc/resolv.conf 
nameserver 127.0.0.1

Thanks.

Gertjan

@viniciusferrao

The image not loaded :

You've set this one ?
If so, why ?

Consider un checking it, as you don't care / shouldn't need the DNS servers of your ISP.
That's a concept of the past. The option exists as there for exceptional reasons.
Rule of thumb : you don't want the DNS of your ISP, neither some other company's upstream DNS resolver.

About :

//						$hostname = gethostbyaddr($item['ip']);

Add this line :

//						$hostname = gethostbyaddr($item['ip']);
						log_error("Would call gethostbyaddr() using : {$item['ip']}");

When you visit the dhcp leases page, you should see this in the main system log :

Take note of the IPs listed : they are all 'local', IP distributed by the DHCP servers on your LANs.
Right ?

viniciusferrao

@gertjan said in DHCP lease screen not loading:

@viniciusferrao

The image not loaded :

You've set this one ?
If so, why ?

It was enabled. I don't remember why it was enable. And yes, I don't need it.

We have internal DNS servers that the local unbound redirects to, so using 127.0.0.1 only is sufficient.

Consider un checking it, as you don't care / shouldn't need the DNS servers of your ISP.
That's a concept of the past. The option exists as there for exceptional reasons.
Rule of thumb : you don't want the DNS of your ISP, neither some other company's upstream DNS resolver.

Removed, but it still does not loads the page. Still receiving 504 timeouts.

About :
//						$hostname = gethostbyaddr($item['ip']);
Add this line :
//						$hostname = gethostbyaddr($item['ip']);
						log_error("Would call gethostbyaddr() using : {$item['ip']}");
When you visit the dhcp leases page, you should see this in the main system log :

Take note of the IPs listed : they are all 'local', IP distributed by the DHCP servers on your LANs.
Right ?

Yes, all are local IPs, but theres something like 300 IPs. I'm not sure if this is an issue or not to avoid loading the page.

Anything else that I should be looking for?

Thank you.

Gertjan

@viniciusferrao

So you saw 300+ "Would call ...." log lines.

When unbound receives a DNS request, initiated by the php function gethostbyaddr(local-IP), it will answer.
Mine does.
But, I presume the issue is now :

@viniciusferrao said in DHCP lease screen not loading:

We have internal DNS servers that the local unbound redirects to

and these 'internal DNS' servers don't answer ... (just guessing).

Several option to test :
Unbound is actually running ?

Ask it a question :

[22.05-RELEASE][admin@pfSense.mylocalnetwork.net]/etc: host 192.168.1.2
2.1.168.192.in-addr.arpa domain name pointer bureau2.mylocalnetwork.net.

You get an answer like that ?

Does unbound receive the request made by gethostbyaddr() ? (make it log very verbose)
Does unbound forwards these requests to your 'internal DNS' ?
Do they answer ?
What happens when you disable temporarily these 'internal DNS' servers and use a 'default' unbound/resolver configuration ?

stephen.betts

i did something similar after having an ongoing problem listing DHCP leases

have two pfsense SG1100 connected
one web interface was super slow ( compared to the other remote device )
It would not display dhcp leases and got the gateway 504 timeout

I read this thread and saw alot of talk about DNS ( I'm using 1.1.1.1 / 8.8.8.8 )

I disable the DNS resolver, applied config,
obviously i could not resolve any DNS now from my clients :-(
I enabled DNS resolver again and applied config

I then noticed that the web interface was now much faster and DHCP leases appear in 5 - 10 seconds and without the gateway 504 timeout

Its been a week or so and DHCP leases are still displaying

fritolays

@gertjan said in DHCP lease screen not loading:

Open / edit /etc/inc/system.inc
Got around line 747.
Find
						$hostname = gethostbyaddr($item['ip']);
replace it by
//						$hostname = gethostbyaddr($item['ip']);
and test.
The DHCP leases page shows up now ?

Yay old topics!

So I had this same issue with the DHCP Lease screen hanging/not loading.

Why you may ask?
Well I installed the nextdns cli and eventually it says to disable the DNS Resolver.
I do, and then DHCP Leases wont load.
The ARP Table page loads just fine, fyi.

Stop nextdns service and re-enable the resolver and it works again.

Relevant code block:

if ($lease) {
	if (empty($item['hostname'])) {
		if (is_null($dnsavailable)) {
			$dnsavailable = check_dnsavailable();
		}
		if ($dnsavailable) {
			$hostname = gethostbyaddr($item['ip']);
			if (!empty($hostname)) {
				$item['hostname'] = $hostname;
			}
		}
	}

ChatGPT described the function of the relevant block of code as:

This looks like a code snippet written in PHP that is checking whether a lease exists and then checking the hostname associated with that lease. If the hostname is empty and DNS is available, it uses the gethostbyaddr() function to attempt to look up the hostname from the IP address and assigns the hostname to the 'hostname' key of the $item array. If a hostname is found, it assigns it to the 'hostname' key, if not, it will remains empty.

Commenting out the line as described above fixes the issue of not running any DNS service as far as pf is concerned.
But , if I understand correctly, it fails when it attempts to get the hostname via ip from the dns.
So pf is aware(?) of a DNS service since it did not fail at the if (is_null($dnsavailable)) section.

I also dont see any real issue with leaving it commented out.
Do I need that page to check all my leases against a dns service?

So there is certainly an issue with that page needing to check leased ip's via dns even when no DNS service is detected.
Let alone that there are hardcoded google DNS servers tied to the check_dnsavailable function which kinda sucks.
Maybe adding an option on the DHCP Server page to disable leased ip's being looked up via dns?
Especially hardcoded ones...

fritolays

@fritolays

Sorry, this only checks ip's without a hostname.
Of which I have one...

Either way, there should be the option to disable hostname-less ip lookup via hardcoded dns.

Gertjan

@fritolays

... or : make DNS work.
I'll explain :
I followed the rabbit into the hole : I looked up the gethostbyaddr() PHP function.
I goes down (deep !) into glibc and it finally winds up talking to localhost (127.0.0.1 or ::1) or some system wide defined DNS server.
Side note : just ask yourself : why should our pfSense GUI ask a remote DNS server about a possible host name that is only known on one of our local LAN networks ? The IP used is RFC1918, something like 192.168.1.10/24, and these are by definition unknown to whatever DNS server on the Internet.
But : they will answer right away : 'unk' or unknown. So, even if asking to 8.8.8.8 : what is the host name of 192.168.1.10, the answer will be back immediate, and out DHCP lease GUI page will show up quickly.

The real issue is : gethostbyaddr() will prefer using IPv6 over IPv4.
If pfSense -> the PHP function gethostbyaddr(), and it is using the glibc library, knows IPv6 is available, IPv6 will be used.
IPv6 is available means : pfSense, the OS, starts to use IPv6, but nothing is known at that moment if IPv6 can route out to a IPv6 server somewhere on the Internet.
How many among us actually are really using IPv4 and IPv6 - example : while posting on the forum, "I" use IPv6 only :

So, I guess the real issue is : IPv6 seems to be available, but the setup is 'broken'. The function, deep below, winds up talking to the wall, and enters a wait state until some TCP/UDP requests time out. The fallback to IPv4 will result in a 'unk', and then the next lease is handled. Introducing the same delay : the entire page will shows up after a very long time. PHP times out, and you have a web browser error page.

Normally, our unbound is authorative for local host names. It should know that nas.my-local-pfsense-lan-network.tld is local, and it's IPv4 = 192.168.1.10 is local, so it will never start to resolve using root servers etc.
If the host name of a lease 192.168.1.10 is unknown, it will send a 'unk' back right away.
For this to work, unbound should work, and it should be listening on '127.0.0.1' (and ::1).

Solution is two fold :
Inform pfSense that IPv6 is not available.
Or
Make the IPv6 stack work, like the IPv4.

Also : check :

[22.05-RELEASE][admin@pfSense.my-local-network.tld]/root: sockstat | grep 'unbound' | grep ':53'
unbound  unbound    26513 3  udp6   *:53                  *:*
unbound  unbound    26513 4  tcp6   *:53                  *:*
unbound  unbound    26513 5  udp4   *:53                  *:*
unbound  unbound    26513 6  tcp4   *:53                  *:*

this says : unbound is listing on every local available interface on port 53, using UDP and TCP (!) using IPv6 and IPv4.
Btw : this is the default behavior.

hazarjast

@gertjan I have been following this thread for a long time and I must say your contributions have been some of the most valuable additions thus far.

Given your level of troubleshooting detail I think that @cmcdonald in particular might find your info very interesting given one of his recent projects appears to have been refactoring the legacy PHP code that exists in pfSense. Given this, maybe some thought could be given to the use of gethostbyaddr() here and/or implementing the IPv6 changes you have suggested. I've found him to be a breath of fresh air at Netgate so hoping he is able to review your posts and hopefully work with their teams to resolve this long-standing issue with the DHCP Leases page :)

fritolays

@gertjan

Didn't mean to send someone else down this hole; but thanks kindly...
Also, I am not sure if your solutions where meant for me to address hehe.

Nonetheless, I have "All IPv6 traffic will be blocked by the firewall unless this box is checked" unchecked in Advanced -> Networking
I also have "Enable DNS resolver" unchecked.

I tried the command you quoted but as expected since I dont have unbound running I get no output:

[2.6.0-RELEASE][root@*******]/root: sockstat | grep 'unbound' | grep ':53'
[2.6.0-RELEASE][root@*******]/root:

It does have nextdns listening on v4 & v6 however:

[2.6.0-RELEASE][root@*******]/root: sockstat | grep 'nextdns' | grep ':53'
root     nextdns    40410 11 udp4   127.0.0.1:53          *:*
root     nextdns    40410 12 tcp4   127.0.0.1:53          *:*
root     nextdns    40410 13 tcp4   192.168.x.1:53       *:*
root     nextdns    40410 14 udp4   192.168.x.1:53       *:*
root     nextdns    40410 15 udp4   *:5353                *:*
root     nextdns    40410 16 tcp6   ::1:53                *:*
root     nextdns    40410 17 tcp4   192.168.x.1:53        *:*
root     nextdns    40410 18 udp6   ::1:53                *:*
root     nextdns    40410 19 udp4   192.168.x.1:53        *:*
root     nextdns    40410 20 udp6   *:5353                *:*
root     nextdns    40410 21 udp6   *:5353                *:*
root     nextdns    40410 22 udp6   *:5353                *:*
root     nextdns    40410 23 udp6   *:5353                *:*
root     nextdns    40410 24 udp6   *:5353                *:*
root     nextdns    40410 25 udp6   *:5353                *:*
root     nextdns    40410 26 udp4   *:5353                *:*
root     nextdns    40410 27 udp6   *:5353                *:*
root     nextdns    40410 28 udp6   *:5353                *:*
root     nextdns    40410 29 udp6   *:5353                *:*
root     nextdns    40410 30 udp6   *:5353                *:*
root     nextdns    40410 31 udp6   *:5353                *:*
root     nextdns    40410 32 udp4   *:5353                *:*
root     nextdns    40410 33 udp6   *:5353                *:*
[2.6.0-RELEASE][root@*******]/root:

Looking round the internet I did come across another guide for nextdns cli on pfsense. This one leaves unbound active to perform local domain discovery/resolution, and adds a forwarder for those local domains into the nextdns.conf.

I'll give this a shot later to see if it fixes the page loading issue without commenting out the line mentioned above.

Gertjan

@fritolays said in DHCP lease screen not loading:

Nonetheless, I have "All IPv6 traffic will be blocked by the firewall unless this box is checked" unchecked in Advanced -> Networking

So, in theory, no incoming DNS requests over TCP on your LANs.
That's ok.
Still, write it on the wall : make IPv6 work. It's the future.

@fritolays said in DHCP lease screen not loading:

since I dont have unbound running I get no output:

That's normal.
You are using a forwarder = something else.
You've got it : change unbound for nextdns and you get the needed answer.

You should also have this :

As this means that the local /etc/resolv.conf contains "127.0.0.1" so that all DNS requetsing functions like gethostbyaddr() on pfSense knows it can 'socket' to 127.0.0.1:53. From there, the resolver, or your nextdns tack the relay.

You can do yourself on the command line what the GUI does when you ask for the DHCP leases page :

[22.05-RELEASE][admin@pfSense.brit-hotel-fumel.net]/root: host 192.168.1.2
2.1.168.192.in-addr.arpa domain name pointer bureau2.my-pfsense-network.net.

This host command generated this line (DNS reverse request to my unbound ) :

Btw : my 192.168.1.2 is on the DHCP leases list :

So my resolver found who "192.168.1.2" which is normal, as 192.168.1.2 is a static MAC DHCPO lease on my pfSense.

On unknown lease, like :

[22.05-RELEASE][admin@pfSense.my-pfsense-network.net]/root: host 192.168.1.94
Host 94.1.168.192.in-addr.arpa not found: 3(NXDOMAIN)

answers NXDOMAIN immediately.
Unbound is not going to ask 'upstream' as it knows 192.168.1.94 is 'local'

What I'm trying to say :
When I - the GUI - asks for a reverse DNS lookup, my local DNS used should always answer right away.
If the DHCP leases page, that fires a lot of these reverse DNS requests, doesn't show up immediately , you have a DNS issue.

I've stopped my DNS, the resolver, and refreshed the DHCP leases page.
The page didn't reload anymore .....
An that's normal, no one was listening on 127.0.0.1 any more.
And, I've told pfSense that :

is the DNS to be used.

I'm pretty sure that the functionally provided by check_dnsavailable() is flawed.
I have to study that one.
This doesn't change that you should have a working local DNS working on your 127.0.0.1

randre.wright

@gertjan Thank you. Your advice worked for me as well.

Stopped dhcpd service

cd /var/dhcpd/var/db
mv dhcpd.leases dhcpdleases.bak
mv dhcpd.leases~ dhcpdleases~.bak

Started dhcpd service