I recently set up a new filewall with IPFire, but sometimes hosts that pull a DHCP address don’t get propagated into the DNS server properly. When this happens, if I log into the firewall and do this:
# /etc/init.d/dhcp restart
…then the host will show up in DNS.
My suspicion is that whatever mechanism that the unbound-dhcp-leases-bridge process uses to tell when it should regenerate the table is not working reliably. What can I do to help troubleshoot this?
Jeff, I dont have an answer but experience the same issue. I bring a laptop into the Green network, DHCP server shows its mac and ip but the bridge does not notify unbound. My solution is what you typed, restart dhcp and then I can resolve the host. My Perl skills are not good to troubleshoot the code. Hopefully, a skilled person could take a look.
Hi Jeff & Paul,
I’ve been seeing the same thing. I’ve been trying to figure out the process for the dhcp server & leases and how they interact with unbound but it is over my head!
I think the link/bridge is unbound-dhcp-leases-bridge.
I’ve been monitoring the files below and I can see changes in /var/state/dhcp/dhcpd.leases (like when you bring your laptop into the green network). But there is no corresponding entry in /etc/unbound/dhcp-leases.conf. Weird, eh?
[root@ipfire pmacct]# ls -al {/var/state/dhcp/dhcpd.leases,/var/ipfire/dhcp/fixleases,/etc/unbound/dhcp-leases.conf}
-rw-r--r-- 1 root root 4833 Sep 6 13:35 /etc/unbound/dhcp-leases.conf
-rw-r--r-- 1 nobody nobody 878 Sep 3 14:18 /var/ipfire/dhcp/fixleases
-rw-r--r-- 1 root root 12050 Sep 9 11:24 /var/state/dhcp/dhcpd.leases
[root@ipfire pmacct]#
And I think that is created by unbound-dhcp-leases-bridge. But this is beyond me.
I don’t know if this is a bug or me not understanding how things work!
EDIT: I decided to add a bug report:
https://bugzilla.ipfire.org/show_bug.cgi?id=12694
I have had a look at this bug and am trying to reproduce it and struggling a bit.
If I have a fixed IP address for a specific mac address and have the hostname defined in the IPFire Hosts page then whenever that computer joins the network I can always resolve the hostname to the IP address.
However it seems that you are talking about a computer getting a dhcp IP address so nothing can be put in the IPFire Hosts page as the IP address for that hostname could be different the next time it connects.
So the only information on the hostname of the connecting computer is what it has stored in its /etc/hostname file
If I connect with a vm computer onto my vm IPFire I get a new IP Address provided by dhcp but I can not resolve the hostname that the computer has at all, even when I restart dhcp because that hostname is only specified in that computers /etc/hostname file and no where in IPFire.
Could you specify in more detail the steps you are taking and what you expect to find in which file by what command and what you are actually getting.
That might help me understand how to duplicate what you are doing.
@bonnietwin I logged on to ipfire and tail -f /var/log/messages Then I switched on my laptop. As you see, the MAC is discovered. Within parentheses, the hostname of that laptop. So now DHCP server knows ip, mac, and hostname.
Sep 14 08:40:17 ipfire dhcpd: DHCPDISCOVER from c4:46:19:50:47:ac via green0
Sep 14 08:40:18 ipfire dhcpd: DHCPOFFER on 10.0.0.27 to c4:46:19:50:47:ac (e6500) via green0
Sep 14 08:40:18 ipfire dhcpd: DHCPREQUEST for 10.0.0.27 (10.0.0.1) from c4:46:19:50:47:ac (e6500) via green0
Sep 14 08:40:18 ipfire dhcpd: DHCPACK on 10.0.0.27 to c4:46:19:50:47:ac (e6500) via green0
It’s the job of the bridge (which runs as a daemon) to notify unbound. Trying to ping laptop, unbound not a clue. Then, I run my little script to restart DHCP and laptop is pingable.
[root@ipfire ~]# ping e6500
ping: e6500: Name or service not known
[root@ipfire ~]# . rst
Stopping DHCP Server... [ OK ]
Stopping Unbound DHCP Leases Bridge... [ OK ]
Starting DHCP Server... [ OK ]
Starting Unbound DHCP Leases Bridge... [ OK ]
Stopping Unbound DNS Proxy... [ OK ]
Starting Unbound DNS Proxy... [ OK ]
[root@ipfire ~]# ping e6500
PING e6500.lan (10.0.0.27) 56(84) bytes of data.
64 bytes from e6500.lan (10.0.0.27): icmp_seq=1 ttl=64 time=201 ms
64 bytes from e6500.lan (10.0.0.27): icmp_seq=2 ttl=64 time=11.1 ms
HTH
Thanks. That helps. I will follow the same steps and see if I get the same result.
Your script restarts both dhcp and unbound. What commands do you use in your script for that so I can make sure I am duplicating what you do.
A small script, 3 lines.
[root@ipfire ~]# cat rst
/etc/init.d/dhcp stop
/etc/init.d/dhcp start
/etc/init.d/unbound restart
This might help (and it took me a little while to figure out!)
If you add a -vv to unbound-dhcp-leases-bridge and then run /etc/init.d/dhcp restart it will add lots of info into the dhcp logs.
You’ll see info about Adding records and removing records.
So I hit a problem at the first bit. Your dhcp communication included the host name in brackets. My communication is completely missing that.
Sep 14 21:56:28 ipfire dhcpd: DHCPDISCOVER from 08:00:27:51:88:6f via blue0
Sep 14 21:56:29 ipfire dhcpd: DHCPOFFER on 192.168.220.20 to 08:00:27:51:88:6f via blue0
Sep 14 21:56:29 ipfire dhcpd: DHCPREQUEST for 192.168.220.20 (192.168.220.254) from 08:00:27:51:88:6f via blue0
Sep 14 21:56:29 ipfire dhcpd: Wrote 0 deleted host decls to leases file.
Sep 14 21:56:29 ipfire dhcpd: Wrote 0 new dynamic host decls to leases file.
Sep 14 21:56:29 ipfire dhcpd: Wrote 1 leases to leases file.
Sep 14 21:56:29 ipfire dhcpd: DHCPACK on 192.168.220.20 to 08:00:27:51:88:6f via blue0
my hostname and hosts file on the computer on blue are as follows:-
less /etc/hostname
blue3
less /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1 localhost
127.0.1.1 blue3.localdomain blue3
How does this compare to yours.
What options do you have in your dhcp client on your laptop. Maybe I am missing something that sends the hostname to the server.
I will check my dhcpcd.conf for my client on the blue vm computer.
OK, I solved the problem of the missing hostname. My dhcpcd.conf file on my blue vm computer had the hostname line commented out.
I uncommented it restarted my dhcpcd client and IPFire now gets the blue3 hostname in brackets.
I will now follow the following steps you both took and see if I can now reproduce what you experience.
@jon I will definitely add in the double verbose. That will help a lot with the detail of what occurs.
Will let you know if I am successful in reproducing it.
In my dhcp log the only time I see local IP addresses in parens ( ) is for my blue network gateway (I think that is the right word!)
Sep 5 20:14:44 ipfire dhcpd: DHCPREQUEST for 192.168.65.110 (192.168.65.1) from 4O:6O:32:ed:4O:Od (ecobee) via blue0
Sep 5 20:14:44 ipfire dhcpd: DHCPACK on 192.168.65.110 to 4O:6O:32:ed:4O:Od (ecobee) via blue0
.
EDIT: added host/hostname info
iMac:~ $ cat /etc/hostname
cat: /etc/hostname: No such file or directory
iMac:~ $ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
By brackets, you mean parentheses ( ) To me, brackets are square [ ] and curly brackets are { }
My laptop is Linux Mint 20.2, stock, basic install nothing custom.
user@e6500:~$ cat /etc/hostname
e6500
user@e6500:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 e6500
for me these are braces. I was taught to remember the dentist adds { } to your teeth to get them straightened. (yes - this is true!)
Consistency in naming of things.
() are brackets or parentheses
[] are square brackets
{} are curly brackets or braces
Anyway, I solved the hostname in parentheses bit. Modified my dhcpcd.conf file to uncomment hostname
@jon if you don’t have a hostname on the computer you are trying to get a dhcp IP address for, then what would be put into the DNS to be able to resolve to the IP Address.
I thought the problem was that you had a hostname but the DNS in IPFire was not resolving this to the IP Address that dhcp had given it.
Sorry for the confusion: Found the hostname in a different location on a Mac:
iMac:~ $ scutil --get ComputerName
iMac
iMac:~ $ scutil --get HostName
iMac
iMac:~ $ scutil --get LocalHostName
iMac
everyone is different!
() parentheses or parens
[] brackets
{} braces
Note that it doesn’t happen every time.
It looks like the bridge process uses inotify to watch for changes to the lease file, and that works fine sometimes, but it seems like other times it misses noticing that the file has changed. I haven’t been able to catch it in the act though to see why this happens.
Thank you! This was one of the pieces I completely missed!
Ah, that could make it challenging to figure out what is going wrong and be able to fix it.
So I followed Paul’s steps and had my blue3 hostname in parentheses in the log details.
I tried pinging blue3 and it could not be resolved.
I then stopped dhcp and started dhcp. The dhcp start also ran the bridge. After this step (so no restart of unbound) I ran ping on blue3 and it was correctly resolved.
I then shut down the blue computer and rebooted my IPFire vm and after it was fully up I then started the blue computer and once it was up I again ran ping blue3 and this time blue3 was resolved without needing to restart dhcp.
So this confirms what Jeffrey has indicated, that this is going to be a problem that is not consistent in its occurrence.
It seems to me if the lease runs out (expires) we will run into the same issue.
And It could be the combination of things: the lease expires AND the /etc/unbound/dhcp-leases.conf updates and unbound updates.
Just my guess…