Another DHCP regeneration fail on 203

Network DHCP
1

Add me to the cases of having to remediate a DHCP configuration with a bunch of fixed leases after 203.

I upgraded my hardware and made a new installation, which is how I ended up in this mess. My previous upgrade to 203 had gone well; this time it was a clean installation followed by restoring an .ipf backup from that working 203 system.

Disabling DHCP in the WUI, clicking Save, then re-enabling it and clicking Save again after a few seconds seems to have fixed it.

Unfortunately that was not the first thing I tried. The reason was simply that I was effectively doing a clean installation of 203 and restoring a backup from a known-working 203 installation, so it did not seem obvious that I could be hitting this particular DHCP configuration problem.

Before that, it was quite a mess, with fixed leases not being respected and devices ending up on unexpected addresses.

Oh, and in case anyone wonders, my DNS firewall was and is not active, so I doubt this has anything to do with that, after all I was restoring an inactive Knot conf on to an inactive Knot, but then again, someone wrote that Knot could somehow cause this ?

This is my HW link, btw

2

I think your problem is related to the fact that the dhcp and knot-resolver services are not restarted after restoring the configuration.

It is preferable to reboot the system after restoring a configuration.

3

Which was done. Basic troubleshooting if you don’t want to mess with restarting each service individually…

Have you never worked with IT Support :winking_face_with_tongue:

4

OK, that wasn’t mentioned, and I hadn’t realized you worked in IT support. :grinning_face_with_smiling_eyes:

So, what’s your diagnosis then?

5

I don’t work in IT Support any longer, but did for a decade when I headed Mercedes-Benz retailer support in Scandinavia a decade ago.

“Have you tried restarting the computer?” is one of those automated phrases I banned from slentrian usage.

As for the specific problem in IPFire I do not know what is wrong, I just reported what seems to be something a few others have come across.

6

Indeed, there have been a few issues reported here with CU203, particularly regarding DHCP static leases.

However, those issues were related to the DNS configuration change between CU202 and CU203 (CU202: Unbound → CU203: Knot Resolver).
In your case, restoring a CU203 configuration onto CU203 should not cause any problems.

The only possibility I can think of is that your DHCP clients connected before the restoration and did not renew their leases afterwards. But that’s only a guess in the absence of any logs.
As for Knot Resolver, it can indeed be a bit temperamental (That’s why, for the moment, I have stayed with CU202 in production)

But without more details, it is difficult to make a proper diagnosis.

7

I could try to get more details, I will be reinstalling the firewall again in a few days and do the same manoeuvre again because I was having a mdadm issue, seems the refurbished P883 drives I bought was not “linux-cleaned” from previous conf, only “windows-cleaned” - go figure.

What should I look for?

8

start with look in /var/log/messages.

For DHCP:
cat /var/log/messages | grep -E 'dhcp'

For DNS:
cat /var/log/messages | grep -E '(knot_resolver.*: |supervisord: |kresd\[.*\]: |unbound: \[.*?\])'

And for errors:
cat /var/log/messages | grep -iE 'error|failed|failure|critical'

But you should know all that already. :wink:

9

I know it up to a point… still have to look up the finer details and switches.

10

As you surely know, troubleshooting this type of issue is a rather tedious task.
Spotting errors in the logs can be like looking for a needle in a haystack, especially when there are no explicit error messages.

However, you can at least monitor whether your DHCP assignments are correct:
tail -f /var/log/messages | grep -E 'dhcp'