Homelab

After a reboot of my new server, the Kea DHCP server did not respond to DHCPDISCOVERs or DHCPREQUESTs

After I upgraded my WRT3200ACM router to OpenWRT v23.05.3, my laptop took minutes to get an IPv4 address when connected to my WRT3200ACM router’s WiFi. It only takes seconds to get an IPv4 address when connected to my other WiFi.

I ended up downgrading OpenWRT on the WRT3200ACM, but first I did a lot of work trying to track down the problem.

After I upgraded to OpenWRT 23.05.3, my Linksys WRT3200ACM WiFi router seems to interact poorly with my Dell E7470 laptop. It takes many tens of seconds for that laptop to acquire an IPv4 address via DHCP.

I decided to downgrade OpenWRT Linux on the router from 23.05.3 to 19.07.10. I believe it was running 19.07 before I started on my sysadmin journey of switching to a new server.

I’ve had an interest in accurate timekeeping and NTP, the Network Time Protocol for quite a while.

At one time or another over the years, I’ve run the original ntpd, xntpd, and OpenNTPD. I currently have the chrony NTP server running on my old server, to aggregate NTP needs on my home network.

I decided to try the kea DHCP daemon on my production server.

My Arch Linux laptop started rebooting when I closed the lid and re-opened it.

As Ben Franklin noted, “Men and nations behave wisely when they have exhausted all other resources”. So it was with this problem.

I’ve used Internet Software Consortium’s dhcpd for a while.

When I was setting up my new server I found out that dhcpd was past end-of-life. ISC wanted me to use kea instead.

I’ve got a Linksys WRT3200ACM WiFi router. Of course it runs OpenWRT, but it should bridge the associated WiFi clients to my LAN, not NAT them.

I bought a Qotom Q20332G9-S10 fanless server, which I hope will eventually replace my older Dell PowerEdge R530, which was manufactured in August - December of 2014.

This started me on a journey of discovery that I could scarcely have imagined six months ago.