DHCP Relay doesn't work properly since Update to 22.1.8

[Tony Martin]

After having updated OPNsense to version 22.1.8 the DHCP relay doesn't work properly anymore. The interface settings in the GUI are not completely taken over to the config file so that not all VLAN's are getting ip addresses. Only killing the process and starting it manually via the CLI is succesful. Is this a bug in 22.1.8? Anyone having the same issue?

[amw]

...seems config.xml is correct but not to be taken on the startup of /usr/local/sbin/dhcrelay.

[TA_Soft]

Hi, i have the same problem and unfortunately restarting via the CLI doesn't do anything for me either. How did you proceed in the CLI?

-TA

[amw]

Kill the process and start it again with the interfaces you need. Thats it.

ps aux|grep dhc
kill -9 ID
/usr/local/sbin/dhcrelay -i XXX -i XXX....... IPDHCP IPDHCP

[Tony Martin]

@Moderator: Will there be a patch solving the issue or is it gonna be fixed with the next major release?

[franco]

I'm looking at https://github.com/opnsense/changelog/blob/master/community/22.1/22.1.8 and wonder what could possibly be reported here. I don't see a bug or ample evidence that 22.1.8 is the cause. I see no confirmation of 22.1.7 working as intended either.

I'm happy to help, but without sensible information this is a goose chase.


Cheers,
Franco

[amw]

Franco, do need more details? We only updated from 21.1.7 to 22.1.8. All look ok - config.xml:

<dhcrelay>                                                                                                                                                                                                       <interface>opt2,opt8,opt4,opt7,opt9,opt10</interface>

but when dhcrelay starts 3 of 6 Interfaces are missing in the option of the process with the "-i" option.

[franco]

So how do you confirm this or what is the operational issue? I'd use

# ps auxwww | grep dhcrelay

which doesn't crop the argument list.

The problem still stands: with no code changed, what sort of operational issue/bug are we looking at?


Cheers,
Franco

[grunge]

I’ve got the same issue. When rebooting my nas, dhcp does not provide anything bit weirdly if I refresh the relay web page, it provides an ip. Restarting the service seems to fix it

[amw]

Reload or Reboot doesn't help:

@franco: Here is the output to get it running again...

after reboot or reload:
root@XXX:~ # ps aux|grep dhc
root    11019    0.0  0.0   15460    4040  -  Ss   17:04     0:00.01 /usr/local/sbin/dhcrelay -i vlan01 -i lagg1_vlan511 -i lagg1_vlan501 -i lagg1_vlan512 -i lagg0_vlan516 192.168.X.X 192.168.X.X
root    16395    0.0  0.0   12740    2204  1  S+   17:04     0:00.00 grep dhc

To get it working again:
root@XXX:~ # kill -9 11019
root@XXX:~ # /usr/local/sbin/dhcrelay -i vlan01 -i lagg1_vlan511 -i lagg1_vlan501 -i lagg1_vlan512 -i lagg1_vlan513 -i lagg1_vlan514 -i lagg0_vlan516 192.168.X.X 192.168.X.X
Requesting: vlan01 as upstream: Y downstream: Y
Requesting: lagg1_vlan511 as upstream: Y downstream: Y
Requesting: lagg1_vlan501 as upstream: Y downstream: Y
Requesting: lagg1_vlan512 as upstream: Y downstream: Y
Requesting: lagg1_vlan513 as upstream: Y downstream: Y
Requesting: lagg1_vlan514 as upstream: Y downstream: Y
Requesting: lagg0_vlan516 as upstream: Y downstream: Y
Internet Systems Consortium DHCP Relay Agent 4.4.2-P1
Copyright 2004-2021 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on BPF/lagg0_vlan516/d4:f5:ef:37:29:60
Sending on   BPF/lagg0_vlan516/d4:f5:ef:37:29:60
Listening on BPF/lagg1_vlan514/d4:f5:ef:37:29:68
Sending on   BPF/lagg1_vlan514/d4:f5:ef:37:29:68
Listening on BPF/lagg1_vlan513/d4:f5:ef:37:29:68
Sending on   BPF/lagg1_vlan513/d4:f5:ef:37:29:68
Listening on BPF/lagg1_vlan512/d4:f5:ef:37:29:68
Sending on   BPF/lagg1_vlan512/d4:f5:ef:37:29:68
Listening on BPF/lagg1_vlan501/d4:f5:ef:37:29:68
Sending on   BPF/lagg1_vlan501/d4:f5:ef:37:29:68
Listening on BPF/lagg1_vlan511/d4:f5:ef:37:29:68
Sending on   BPF/lagg1_vlan511/d4:f5:ef:37:29:68
Listening on BPF/vlan01/d4:f5:ef:37:29:60
Sending on   BPF/vlan01/d4:f5:ef:37:29:60
Sending on   Socket/fallback
root@XXX:~ #


You see that two networks are missing, but they are enabled in the webgui.

[franco]

If it's a about a missing -i implementation I'd first check if all selected interface have proper IP configuration while dhcrelay is starting (best as static). It could be a side effect. I can only repeat the dhcrelay code wasn't changed in 22.1.8 but the code is also trying to figure out if all is operational so that might not be the case.


Cheers,
Franco

[amw]

For example we have the same configuration as in vlan512... So all interfaces have an IP. Why is it not a case? It worked before and now not. Is there a way to debug this? Or open a case at the development?

[franco]

It's likely easy to debug this on the machine in question that exhibits this behaviour, but from within the forum I can't do much other than point into the right direction.


Cheers,
Franco

[franco]

After a bit of debugging it seems that dhcp code in general reacts "strange" to bridges when it's not necessary. A patch was added as follows which should become available in 22.7:

https://github.com/opnsense/core/commit/3f98dc83c41


Cheers,
Franco

[amw]

Thank you!