I am expiriencing an issue with DHCP using 8devices habanero with v23.05.2
Scenario:
I have 5 devices conected to my router via ethernet.
I remove power from my router and bring power back back.
After a while all of my devices are getting an IPv6 address but only some of them gets an ipv4 address (I donwt block it on any of the devices).
The issue doesn't resolve automatically over time, and the number of devices that doesn't get ipv4 address and which device or what eth port is used is totally random.
The issue can be manually fixed by disabling and enabling the connection on the DHCP client side.
E.G running: nmcli c down "Wired connection 1" ; nmcli c down "Wired connection 1"
After the router reboot, all contents of /tmp are wiped out, so /tmp/dhcp.leases is gone and the webgui doesn't have anything to show.
As soon as the devices start asking again for DHCP settings, they will show up there.
Having said that, if a device never acknowledges the new IP, it will not show up there. Meaning that it may ask for its old IP, the router offers another and the device doesn't accept that.
We can have a look at the uci export dhcp as well the extended logs for some clues.
uci del dhcp.lan.quietdhcp
uci set dhcp.lan.logdhcp='1'
uci commit dhcp
service dnsmasq restart
reboot
(after the reboot)
logread -f -e dnsmasq
Devices will only renew their IP address (and appear on that page) when their lease expires; if you wait long enough, I'm sure they all will appear there.
@eduperez I think that the problem is that the devices renew leases with ipv6 address and not ipv4 , and thats why the problem doesn't resolve itself (since they should also get an ipv4 address)
@sfx2000 Usually after router reboot the bug doesn't reproduce.
I guess that it's because the dhcp-client-device already have an old lease, and in the mechnism of DHCP it renew leases instead of recieving a new one from the DHCP server. So if it has a good lease with ipv4 address the bug will not reproduce. The issue is reproduces mainly when I un plug the router for some time and bring it back up while many devices are already connected to its switch, and even then some have the issue and some doesn't. Has seen in the original post
I will try to debug further with the option uci set dhcp.lan.logdhcp='1' and tcpdump in the future
I think you've solved it - do the reboot vs yoinking power seems to be the right approach here, as this clears out the dhcp leases file over in /tmp...
It's not a solution I will have hundres of routers in production which will have this issue on first boot, and probably in some more usecases during its life.
I solve the issue by adding a cronjob in the client-dhcp-devices which reconnects to the router if it recognizes the issue.
But the issue shouldn't be there in the first place
