Been running fine with a static ip for my server, but it died yesterday and I have a new one installed.
I went to the dhcp settings and removed the previous static ip for the old server and added the new ones mac and ip address and pressed add and save.
But it is still issuing the old dynamic ip it got even though it is shown in the static ip settings and in the 04-pihole-static-dhcp.conf file.
I have restarted the ftl service to see if it would renew the ip but it didn't. Same with a reboot of the pi.
I tried setting the server to manual on the nic, but pinging it by name gives the pihole dhcp address.
In the dhcp clients I have
00:xx:76:yy:BC:E9 192.168.1.235 duo
and in the static leases I have
00:xx:76:yy:BC:E9 192.168.1.68 duo
pinging duo from a client results in .235 reply not .68 (so no ping result)
I'm not sure if I understood you correctly, but if you use pihole as DHCP server and it still hands out "old" dynamic leases instead of new static ones, you're affected by this https://github.com/pi-hole/AdminLTE/issues/1026
Workaround is to manually delete the old entire in /etc/pihole/dhcp.leases
Yes pihole is the ONLY dns server on the network, Been working fine for over a year with this setup.
Tried that, also restarted dns server., Still issuing .235 to the server.
root@pihole:/home/pi# ping duo
ping: duo: Temporary failure in name resolution
root@pihole:/home/pi# ping duo
PING duo (192.168.1.235) 56(84) bytes of data.
^C
--- duo ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 63ms
Also tried the stop ftl server, remove start. On client release & renew.
On client stopped the nic and started it from network manager.
Rebooted server.
Check in the pihole logs for DHCP transactions. Pi-hole may not be giving out the IP address - if the IP is set to static on the duo client, no request for an IP will be made by that client.
Jun 27 14:00:00 dnsmasq[13830]: DHCP 192.168.1.235 is duo.lan
Jun 27 14:00:58 dnsmasq[13830]: DHCP duo.lan is 192.168.1.235
Jun 27 14:01:09 dnsmasq[13830]: DHCP duo.lan is 192.168.1.235
Jun 27 14:02:24 dnsmasq[13830]: DHCP duo.lan is 192.168.1.235
Jun 27 14:03:23 dnsmasq[13830]: DHCP duo is 192.168.1.235
Jun 27 14:03:39 dnsmasq[13830]: DHCP duo.lan is 192.168.1.235
So how do I force it to do like it used to be on v4 and issue the set static ip address to the client?
Since using a static on the client doesn't let pihole use it as a dns address. If that makes sense?
I can't ping it from a client (not the server) if the server has a fixed ip set (not set by pihole) where as if I try to get a dhcp address it defaults to .235 instead of .68 which is where it has been for many years. And pinging from a client uses .235 instead of .68 if I set it with a fixed ip.
If I remove pihole and reinstall it, then create the static ip before setting duo to dhcp would it issue the correct ip then?
So complete purge and re-install and setup static before the client gets the lease ?
OK had duo set to manual ip for past 60 odd min.
On the client, reset the local network (loose all previous settings)
Redid the stop ftl, delete lease, start ftl
confirmed the lease was gone
reset duo to dhcp and it got the lease correctly at last.
root@pihole:/home/pi# service pihole-FTL stop
root@pihole:/home/pi# nano /etc/pihole/dhcp.leases
root@pihole:/home/pi# service pihole-FTL start
root@pihole:/home/pi# cat /etc/pihole/dhcp.leases
***leases removed ****root@pihole:/home/pi# ping duo.lan
PING duo.lan (192.168.1.68) 56(84) bytes of data.
64 bytes from duo.lan (192.168.1.68): icmp_seq=1 ttl=64 time=3.09 ms
64 bytes from duo.lan (192.168.1.68): icmp_seq=2 ttl=64 time=6.74 ms
^C
--- duo.lan ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 3.093/4.916/6.739/1.823 ms
So it seems to have fixed it!????
Only thing I can think of it is it was trying to renew the old lease .235 and pihole was allowing it rather than issuing the static ip I had set.
Sound reasonable?
OK new server arrived today.
Same issue.
Finally fixed it by editing the dhcp.leases and adding a 01: before the mac address.
so it reads
number hash mac address name 01:mac address
rather than
number hash mac address name mac address
resetting the nic didn't work this time.
I added the 01: since I saw that the static ip's already assigned were prefixed with this.