"Warning in DNSMASQ core:
not giving name pihole-server.lan to the DHCP lease of 192.168.1.251 because the name exists in /etc/hosts with address 127.0.0.1
Warning in DNSMASQ core:
not giving name pihole-server to the DHCP lease of 192.168.1.251 because the name exists in /etc/hosts with address 127.0.0.1"
To get rid of this warning I remove
"127.0.0.1 pihole-server" from the Hosts file
…and then the “..unable to resolve host….” warning returns.
Can any kind soul please give me a shove in the right direction?
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
This message is typical for a Raspberry Pi connected via both ethernet and wifi if one of the interfaces doesnt have a static IP configuration.
This interface will try to acquire an IP from Pi-hole's own DHCP service, and during the DHCP lease transaction, will advertise its own hostname to the DHCP server (Pi-hole).
The DHCP service is refusing this name thats advertised via DHCP because it already exists in the /etc/hosts file.
Thank you for that,. It sort of helps inasmuch that I have now disabled wifi.
However the issue remains when updating Pi or restarting services I get
“sudo: unable to resolve host pihole-server: Name or service not known”
Re static IP addresses:
The Pi eth0: is configured as 192.168.1.133/24.
I really would like to know if this is the right place to post the debug log url which I have refreshed again - see below https://tricorder.pi-hole.net/rYOhYkyQ/
Thank you for taking the time to respond. I followed your wise guidance and rebooted.
I subsequently discovered that I had foolishly not amended the dhcpdc file to reflect the hostname under
"# Inform the DHCP server of our hostname for DDNS.
webserver"
[new hostname webserver applied in hostname and hosts files .]
This has been done and the problems described appear to have gone away.
However, if I then run pihole-FTL dhcp-discover I get a new warning....
"Warning in dnsmasq core: no address range available for DHCP request via lo"
I understand this is something to do with 'loopback' [?] Interestingly running the inbuilt generate debug log also fires up dhcp-discover and generates the same error [as one would expect]
Everything appears to be working so do I just ignore the lo warning, or does it suggest something in my setup needs attention?
Pi-hole is operating alongside Apache2 [Port 80]. lighttpd has an additional external.conf file with "server.port = 8080". I'm not sure if lightpd is being used?
pi@ph5a:~ $ man dhcpcd
[..]
-h, --hostname hostname
Sends hostname to the DHCP server so it can be registered
in DNS. If hostname is an empty string then the current
system hostname is sent. If hostname is a FQDN (i.e., con‐
tains a .) then it will be encoded as such.
This setting is intended for if the host were to acquire an IP via DHCP.
If correct, your Pi doesnt acquire an IP via DHCP anymore and instead, those details are set statically:
# Inform the DHCP server of our hostname for DDNS.
hostname
Nothing to worry about, I have the same message when do a dhcp-discovery:
pi@ph5a:~ $ pihole -t
[..]
00:26:25 dnsmasq-dhcp[6589]: DHCPDISCOVER(eth0) b8:27:eb:xx:xx:xx
00:26:25 dnsmasq-dhcp[6589]: DHCPOFFER(eth0) 10.0.0.33 b8:27:eb:xx:xx:xx
00:26:25 dnsmasq-dhcp[6589]: no address range available for DHCP request via lo
Its highly unusual to assign an IP address to the loopback interface named lo via DHCP.
Addresses (EDIT: IPv4 + IPv6) for the lo interface are already set during boot:
pi@ph5a:~ $ ip -br address show lo
lo UNKNOWN 127.0.0.1/8 ::1/128
Ps. when copy & paste code output to here, best to select/highlight the code output with your mouse, and click on the </> button so the output gets displayed like in my examples above:
# Inform the DHCP server of our hostname for DDNS.
webserver
and we are back to square one-ish. I now get warnings;
Warning in dnsmasq core:
not giving name webserver.lan to the DHCP lease of 192.168.1.202 because the name exists in /etc/hosts with address 127.0.1.1
2022-01-18 18:22:17 DNSMASQ_WARN Warning in dnsmasq core:
not giving name webserver to the DHCP lease of 192.168.1.202 because the name exists in /etc/hosts with address 127.0.1.1
I also find Pi intermittently flaky. On reboot, it would randomly reinstate wifi after disabling it in the GUI. I have hopefully permanently clobbered it with an entry in /boot/config under
[All]
dtoverlay=disable-wifi
Irritatingly I have to keep setting the Wifi country to GB, for it seems to intermittently forget, despite a correct entry in
/etc/wpa_supplicant/wpa_supplicant.conf
So we are almost back to square one. At least the sudo: unable to resolve host... has gone away, for now! Ha!
pi@arcade:~ $ dmesg -T | grep brcmfmac
[Wed Jan 19 01:32:16 2022] brcmfmac: F1 signature read @0x18000000=0xXXXXX
[Wed Jan 19 01:32:16 2022] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001
[Wed Jan 19 01:32:16 2022] usbcore: registered new interface driver brcmfmac
[Wed Jan 19 01:32:16 2022] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[Wed Jan 19 01:32:16 2022] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.39 Inc Compiler: 1.29.4 Inc ClmImport: 1.36.3 Creation: 2017-10-23 03:47:14
[Wed Jan 19 01:32:17 2022] brcmfmac: power management disabled
Some more tools for diagnosing, below one shows interface links (including MAC addresses):
ip -br l
Below one IP's:
ip -br a
Below one the journals for the dhcpcd network manager:
journalctl -u dhcpcd
Below one shows DHCP log entries:
grep dnsmasq-dhcp /var/log/pihole.log
Above sounds like another issue.
First fix the current ones and if still experience above issue, create a new help request/topic/thread pls?
EDIT: Come to think of it, you've posted similar mistakes in dhcpcd.conf twice already.
Makes me wonder if dhcpcd is just ignoring that dhcpcd.conf file bc of errors and does what it do default without configuration, acquire an IP via DHCP for all detected interfaces including the eth0 one.
Check the dhcpcd journals!
EDIT2: With below one you can restart dhcpcd if corrected the dhcpcd.conf file:
Apologies for the delay in responding, but I needed to make sure the problems really have gone away!
More apologies for it was a typo when I wrote .
# Inform the DHCP server of our hostname for DDNS.
webserver
I had already set it to
# Inform the DHCP server of our hostname for DDNS.
hostname
and rebooted.
Further info in response to your questions.
lsb_release -a
Description: Raspbian GNU/Linux 10 (buster)
and
cat /proc/cpuinfo
Model : Raspberry Pi 3 Model B Plus Rev 1.3
lsmod showed no presence of brcmfmac until I re-enabled wifi - which is what I would expect. Trying both " dtoverlay=pi3-disable-wifi " and " dtoverlay=disable-wifi " both disabled wifi nicely and reverting to " dtoverlay=disable-wifi" appears to be doing fine and brcmfmac is no longer listed.
I ran the various tools and nothing really stood out, but the truly weird thing is that all the issues have seeming gone away [for now....] and I cannot account for them because the only change made, was to run pihole -up update to Update local cache of available packages. Similarly no change has been made to the router settings.
So for now Pi-hole Diagnosis is empty and there are no nags coming from the Pi, but I fear this will not benefit others stumbling across this dialogue. However, it must be said that throughout this period, Pi-hole has been doing an admirable job!
Thanks for the feedback!
I removed your serial number in above reply for privacy.
Could you mark one of the replies as a solution pls?
Happy ad hunting!
