Bug 281361
| Summary: | ddclient: messages about unknown DHCP option keep cluttering the log | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Michael von Glasow <michael> | ||||||
| Component: | bin | Assignee: | Michael Osipov <michaelo> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | franco, jlduran, markj, matthew, michaelo | ||||||
| Priority: | --- | ||||||||
| Version: | 14.1-RELEASE | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280119 | ||||||||
| Attachments: |
|
||||||||
The option in question is better known as 'DHCP Option 125' -- used for 'Vendor Specific Information' See: https://datatracker.ietf.org/doc/html/rfc3925 A workaround/fix similar to bug #280119 can be applied. Created attachment 253705 [details]
dhclient: Ignore DCHP option 125 defined in RFC 3925
Probably a catch-all might be a better approach, as suggested by the OP. I do not think too much investment in dhclient is desired at this point.
Workaround:
# echo "ignore option-125;" >> /etc/dhclient.conf
Here is a patch that can be tested
Possible fix:
(See attached patch -- not tested).
Created attachment 253706 [details]
dhclient: Ignore DCHP option 125 defined in RFC 3925
Sorry, previous patch had a leftover at the bottom.
For the workaround, do I need to restart anything before it will take effect? Simply editing the config file doesn’t seem to do anything, I am still getting the same error periodically. (In reply to Michael von Glasow from comment #5) Yes, try restarting the dhclient daemon: # service dhclient restart <interface> Per dhclient.conf(5), you can apply the ignore option globally, or on a per-interface basis. The patch has been tested, and it works as expected. Running `service dhclient restart re2` gives me:
dhclient not running? (check /var/run/dhclient/dhclient.re2.pid).
're2' is not a DHCP-enabled interface
There is no PID file at /var/run/dhclient/dhclient.re2.pid, but there is one at /var/run/dhclient.re2.pid, with a PID that indeed seems to correspond to the correct dhclient process.
Running
ifconfig re2 down
ifconfig re2 up
changes that PID (so I assume dhclient restarted), but it keeps complaining about the option.
My /etc/dhclient.conf contains one single line,
ignore option-125;
except for a few comment lines.
(In reply to Michael von Glasow from comment #7) Given this is OPNsense, I'm not familiar on how it is built. Try rebooting. (In reply to Michael von Glasow from comment #7) I have glanced over OPNsense souces: https://github.com/opnsense/core/blob/ec23ffc0ef65ee3fe1f25d23c9690b709edb384c/src/etc/inc/interfaces.inc#L3307-L3309 It looks like both, the pidfile and the configuration file are expected at different locations, maybe it is using NanoBSD-like (read-only / ) mounts? I can't offer any more help past this point. Try adding Franco to this PR. The fix should land on OPNsense once this patch is added to FreeBSD (if added). Thanks for the pointer. Unfortunately, OPNsense recreates that config file whenever the interface is brought down and up again, undoing any changes made manually. Guess I’ll have to wait for the official fix to appear in OPNsense then. Thanks to everyone involved for their support and the quick resolution! PS: for anything specific to OPNsense, please refer to the original ticket: https://github.com/opnsense/src/issues/219. I have documented the workaround there. Let me do the patch. This one is trivial. Review created: https://reviews.freebsd.org/D46760. Tests welcome. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=38c63b52830c85013f30bc62b2b32f3936d84e65 commit 38c63b52830c85013f30bc62b2b32f3936d84e65 Author: Michael Osipov <michaelo@FreeBSD.org> AuthorDate: 2024-09-23 12:37:34 +0000 Commit: Michael Osipov <michaelo@FreeBSD.org> CommitDate: 2024-09-28 08:49:02 +0000 dhclient: Ignore vendor-identifying DHCP options defined in RFC 3925 Ignore DHCP options 124 and 125 to shut up the warning messages. These options are defined in the RFC 3925. PR: 281361 Reviewed by: jrm (mentor), otis (mentor), thj Tested by: jlduran@gmail.com MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D46760 sbin/dhclient/dhclient.c | 2 ++ sbin/dhclient/dhcp.h | 2 ++ 2 files changed, 4 insertions(+) Landed on main, will be on stable branches in two weeks. A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=36c370fa3e9750543b447e9efdcbe83463836388 commit 36c370fa3e9750543b447e9efdcbe83463836388 Author: Michael Osipov <michaelo@FreeBSD.org> AuthorDate: 2024-09-23 12:37:34 +0000 Commit: Michael Osipov <michaelo@FreeBSD.org> CommitDate: 2024-10-12 12:11:04 +0000 dhclient: Ignore vendor-identifying DHCP options defined in RFC 3925 Ignore DHCP options 124 and 125 to shut up the warning messages. These options are defined in the RFC 3925. PR: 281361 Reviewed by: jrm (mentor), otis (mentor), thj Tested by: jlduran@gmail.com MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D46760 (cherry picked from commit 38c63b52830c85013f30bc62b2b32f3936d84e65) sbin/dhclient/dhclient.c | 2 ++ sbin/dhclient/dhcp.h | 2 ++ 2 files changed, 4 insertions(+) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9525f5726a85c0e7f9fb2033add80cd51cce3844 commit 9525f5726a85c0e7f9fb2033add80cd51cce3844 Author: Michael Osipov <michaelo@FreeBSD.org> AuthorDate: 2024-09-23 12:37:34 +0000 Commit: Michael Osipov <michaelo@FreeBSD.org> CommitDate: 2024-10-12 12:15:07 +0000 dhclient: Ignore vendor-identifying DHCP options defined in RFC 3925 Ignore DHCP options 124 and 125 to shut up the warning messages. These options are defined in the RFC 3925. PR: 281361 Reviewed by: jrm (mentor), otis (mentor), thj Tested by: jlduran@gmail.com MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D46760 (cherry picked from commit 38c63b52830c85013f30bc62b2b32f3936d84e65) sbin/dhclient/dhclient.c | 2 ++ sbin/dhclient/dhcp.h | 2 ++ 2 files changed, 4 insertions(+) |
I keep getting the following error message in the log every time the IP config on the external interface is renewed (15 minutes with my ISP): > Error:dhclient:unknown dhcp option value 0x7d **To Reproduce** Steps to reproduce the behavior: * Set up a network with a DHCP server. * Configure the DHCP server to send an unknown DHCP option (0x7d is known to work) * Configure a short timeout (under an hour) for DHCP leases. * Configure DHCP on one interface, and connect it to the network with DHCP server configured in the previous steps. * Observe the log **Expected behavior** I would expect ddclient to silently ignore any options it does not understand (which is the recommended standard behavior for most parsers). If it does log a message at all, the log level should be Debug or Information at most, not Error. **Describe alternatives you considered** Reconfiguring the DHCP server to not set any obscure options ddclient does not need or understand is not an option: the DHCP server is beyond my control (I probably won’t get my ISP to configure their DHCP server the way I think it should be), and since lease times are such that renewals happen every 15 minutes, this really clutters up the logs. There may certainly be legit use cases why a DHCP server would specify DHCP options which some DHCP clients do not understand. **Additional context** I’ve verified DHCP traffic with a packet capture tool, and the DHCP offer indeed does have the unsupported option in it. The log entry has been around for a few versions and might have been present ever since I started using OPNsense on that particular ISP. It makes the logs hard to read when you’re trying to debug something, especially since it is logged as an error. The lower the log level, the easier it is to filter out. Should I have filed this bug against the wrong component, please feel free to move it or let me know where it should go. **Environment** OPNsense 24.7.3_1-amd64 (based on FreeBSD 14.1-release-p3); Franco Fichtner suggested I file my issue as a bug here (however, I don’t agree with him that this is just a minor annoyance)