Incorrect subnet config broke DHCP

[OzziGoblin]

Hi
I had an unfortunate incident this evening, wasn't concentrating and changed one of the vlan subnets to use a /29 address range and had configured the available addresses to be x.x.x.2 - x.x.x.20  Not sure why but this broke the network and it took me a while to determine that DHCP was broken.
Once I discovered that I was able to get into the console and troubleshoot.

Is this a bug????

I don't mean to raise issues that aren't but I didn't expect it to break DHCP.

Thanks

[Patrick M. Hausen]

use a /29 address range and had configured the available addresses to be x.x.x.2 - x.x.x.20

How is this supposed to work? A /29 is 8 addresses, 6 of which are usable.

x.x.x.0 ... x.x.x.7. 1 - 6 usable.

[Seimus]

As Patrick said.

You basically committed a violation, this is not a BUG.

Regards,
S.

[OzziGoblin]

My Appologies everyone, I know the configuration error is entirely my fault, I've only known OpnSense to be extremely reliable and robust and all errors I've experienced have been of my own making.

My surprise though, was that a misconfiguration of 1 of the DHCP scopes, broke the DHCP service and renedered the firewall unable to assign any IP on the remaining 5 scopes I have configured.  I would have expected it to be confined the misconfigured scope, and that's why I wondered if it was a bug.

Sorry

[EricPerl]

Did it crash the DHCP server?
Did you check if it was still running?

[OzziGoblin]

HI, the DHCP service wouldn't start while the configuration was incorrect.

It took me a while to figure out what was wrong but easy to fix once I assigned a static IP to my computer and connected to the console.

[Patrick M. Hausen]

You are right in your expectation that a misconfiguration in one "instance" of DHCP should not break it for all other interfaces.

Unfortunately most Unix services have been written in a way that there are actually no separate instances. At startup the server reads the configuration file. Sendmail, BIND, Unbound, DHCPd, ...

And if there is a syntax error or a semantic misconfiguration aywhere, it simply refuses to start.

Fail early, fail hard was the mantra of the day. And it still has some relevenace. Picture a typo in a certain parameter in a database configuration. And also that this parameter is necessary or your data will be destroyed. What's better? The database silently ignoring unknown options or aborting startup because of them?

Big problem with things that rely on YAML like e.g. Ansible. Misplace an indentation or make a typo - that will not produce a syntax error, it's still valid YAML. And Ansible will just silently ignore anything in the dictionary that the plays do not explicitly use. Have fun debugging that 🙂

[OzziGoblin]

thanks for that feedback, I'll have to be more careful now that I know that :-)

[EricPerl]

It still means the server went from running to reloading config to stopping.
The server no longer starting was a clue. I wonder if there were more clues in the logs wrt the mismatch.