Mean catch in DHCP configuration

Started by meyergru, March 13, 2021, 06:41:27 PM

Previous topic - Next topic
March 13, 2021, 06:41:27 PM Last Edit: March 14, 2021, 02:43:29 PM by meyergru
Today I fought with a mean catch in DHCP: I tried migrating from the Edgerouter 4 and switched one VLAN after another to OpnSense.

I found that the "Response delay" setting in DHCP zones to be a nice feature in order to be able to have the old router come first as long as it is present but have OpnSense take over once it is gone.

This seemed to work, but after the final switch, I found that some VLAN devices did not get any IP reservations despite everything looked fine.

After much trial and error, I found these log entries:


Mar 13 16:38:28 OPNsense dhcpd[34310]: DHCPDISCOVER from 00:1d:63:15:73:9f via ixl3_vlan107: configured min-secs value (2) is greater than secs field (0).  message dropped.
Mar 13 16:38:31 OPNsense dhcpd[34310]: DHCPDISCOVER from 00:1d:63:15:73:9f via ixl3_vlan107: configured min-secs value (2) is greater than secs field (0).  message dropped.
Mar 13 16:38:35 OPNsense dhcpd[34310]: DHCPDISCOVER from 00:1d:63:15:73:9f via ixl3_vlan107: configured min-secs value (2) is greater than secs field (0).  message dropped.


Effectively, when you set a response delay, you render the DHCP zone invalid without knowing.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

It's up to the clients to report how long they have been trying to get a DHCP lease (that's the secs value in the request). If the client never increases this value, it will never get a lease.

So it seems you're dealing with misbehaving clients, not a bug in the DHCP server.

Cheers

Maurice
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).

Yup, you are correct. That also explains why only some clients had problems. However, most other DHCP GUIs do not expose that setting at all. There should be a large warning sign that goes along with it, since many modern IoT devices seem to be affected.

I changed the thread title since it is not really a 'bug'.

Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

Quote from: meyergru on March 14, 2021, 02:47:11 PM
Yup, you are correct. That also explains why only some clients had problems. However, most other DHCP GUIs do not expose that setting at all. There should be a large warning sign that goes along with it, since many modern IoT devices seem to be affected.

I changed the thread title since it is not really a 'bug'.

Lots of bad code out there, especially with IoT thingies. Which is why I like as many of them to be POE powered as possible.  Make a major change on the network?  Just unplug my POE switches, count to 10, plug back in and all my stuff get's rebooted :)

When in doubt, shut up and reboot
https://dilbert.com/strip/1999-08-04