Allow compiling out the DHCP client and UDP - #177
Merged
Merged
Conversation
The DHCP client was compiled into every build, and the poll loop calls into it unconditionally, so --gc-sections could not drop it either. A static-address target paid for a protocol it never runs. Gate the implementation on WOLFIP_ENABLE_DHCP, defaulting to 1, so every existing build is unchanged: with the default, the preprocessed wolfip.c is identical to before. It is the macro the ports' config.h already use to decide whether to define DHCP, so setting it to 0 there now also drops the client from the library. DHCP keeps its meaning as the application-level switch for calling dhcp_client_init(). Guarded are the client itself, the DAD probe, the two DAD conflict checks in arp_recv, and the poll loop's dhcp_timer_recover() call. The dhcp_* fields stay in struct wolfIP: a few dozen bytes, and keeping them lets the DHCP_IS_RUNNING() checks stay plain runtime tests that are always false. The declarations in wolfip.h stay ungated: an unresolved call is a clearer error than an undeclared one. Measured on a TC4Dx TLS demo with WOLFIP_ENABLE_DHCP 0: 3012 bytes of flash, and no dhcp symbols in the image.
With WOLFIP_ENABLE_DHCP 0, MAX_UDPSOCKETS 0 already compiles and behaves: every udpsockets[] access is either a loop bounded by MAX_UDPSOCKETS or preceded by its own ">= MAX_UDPSOCKETS" check, so at zero each UDP path becomes unreachable rather than unsafe, and wolfIP_sock_socket() finds no slot to hand out. DNS goes with it: it cannot open its socket, and the linker drops it. The one unchecked access was in the DHCP client, which that setting compiles out. An #error rejects MAX_UDPSOCKETS 0 while DHCP is still enabled, since the client needs a UDP socket. Document the configuration so it is supported rather than accidental, and build it in CI (with the check that no DHCP symbols are left) so it stays that way. The zero-length array is the same GNU extension struct dhcp_option::data already uses. Measured on a TC4Dx TLS demo, on top of gating DHCP: 2028 more bytes of flash and 18372 bytes of RAM, the per-socket UDP buffers that no longer exist.
Frauschi
force-pushed
the
dhcp-optin
branch
from
September 28, 2026 10:38
c010048 to
36b89c1
Compare
Member
Author
|
@wolfSSL-Fenrir-bot review |
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #177
Scan targets checked: wolfip-src, wolfip-bugs
Coverage: 1 of 1 in-scope changed file(s) opened by the reviewer
Fenrir result: Approved ✅
No new issues found in the changed files.
Advisory only — this automated result does not count as a GitHub approval.
Review tier: Lite
danielinux
approved these changes
Sep 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Static-address targets currently carry the whole DHCP client, and every target pays for the per-socket UDP buffers even when it never opens a UDP socket. This PR makes both removable at compile time. The defaults do not change: with no new settings, the preprocessed
wolfip.cis identical to master.WOLFIP_ENABLE_DHCP(default1): set it to0to compile out the DHCP client, its DAD probe and conflict checks inarp_recv, and thedhcp_timer_recover()call in the poll loop. This is the macro the ports'config.halready use to decide whether to defineDHCP, so a port that sets it to0now also drops the client from the library.DHCPkeeps its meaning as the application-level switch for callingdhcp_client_init().MAX_UDPSOCKETS 0is now a supported configuration when DHCP is disabled. Everyudpsockets[]access is already bounded byMAX_UDPSOCKETS, so at zero each UDP path becomes unreachable,wolfIP_sock_socket()finds no UDP slot, and DNS fails to allocate its socket. An#errorrejectsMAX_UDPSOCKETS 0while DHCP is still enabled.The DHCP declarations in
wolfip.hstay ungated, so calling the API from a build that has DHCP disabled fails at link time with an unresolved symbol.Savings
Measured on a TC4Dx TLS demo:
WOLFIP_ENABLE_DHCP 0MAX_UDPSOCKETS 0Testing
wolfip.cwithWOLFIP_ENABLE_DHCP=0andMAX_UDPSOCKETS 0under-Wall -Werror -Wextra, and fails if anydhcpsymbol is left in the object.-Wall -Werror -Wextra:IP_MULTICASTmakebuilds and linkstest-dns.Docs
docs/API.md: notes that the DHCP functions compile unlessWOLFIP_ENABLE_DHCPis 0.docs/dhcp_dns_howto.md: explains how to drop the client, and documents the no-UDP configuration.