odhcp6c, branch master

odhcp6c: fix handling of RFC6603 Prefix Exclude Option

2026-06-19T23:10:19Z

Several bugs in the encoding and (more importantly) decoding of DHCPV6_OPT_PD_EXCLUDE lead to the option being ignored in some received messages, or the excluded subnet id being mangled to an incorrect value. Fix both encoding and decoding, being more explicit and slightly more verbose for clarity. Signed-off-by: Mark H. Spatz Link: https://github.com/openwrt/odhcp6c/pull/151 Signed-off-by: Hauke Mehrtens

example: write all DNS servers to resolv.conf

2026-06-03T23:16:53Z

setup_interface() built a 'dnspart' list that was never used, then called update_resolv() with '$dns' — the leftover iteration variable from the 'for dns in $RDNSS' loop, which holds only the last RDNSS entry (or is empty when RDNSS is empty). Only that single nameserver was written to resolv.conf; the remaining servers were dropped. Drop the dead 'dnspart' block and pass the full '$RDNSS' list (already merged with $RA_DNS just above) to update_resolv(). Assisted-by: Claude:claude-opus-4-8 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens

odhcp6c: do not treat DHCPv6 option type 0 as end-of-list

2026-06-03T23:14:16Z

dhcpv6_for_each_option was structured as a chain of '&&' expressions where each link both assigned a loop variable (otype, odata, olen) and gated iteration on the assigned value being truthy. The middle link, '((otype) = _o[0] << 8 | _o[1])', made iteration stop on otype == 0. DHCPv6 has no end-of-list sentinel; option code 0 is just reserved (RFC 8415 §21, IANA registry). A server (broken or hostile) that emits an option with code 0 anywhere in the response would silently truncate the client's view of the option list, masking everything that follows — including STATUS, IA_NA / IA_PD, AUTH, etc. Switch the assignments inside the for-loop condition to use the comma operator so all three (otype, odata, olen) are unconditionally written, and gate iteration purely on the bounds check 'odata + olen <= end'. Callers see the same variables, in the same order, just without the spurious type-0 truncation. Assisted-by: Claude:claude-opus-4-7 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens

dhcpv6: enforce monotonic replay counter on Reconfigure RKAP

2026-06-03T23:14:12Z

RFC 8415 §20.4.3 requires the client to track the replay-detection field of an authenticated Reconfigure message and to reject any incoming Reconfigure whose replay value does not exceed the highest one already accepted. Without this check, a captured Reconfigure can be replayed at will: the HMAC is still valid because the message itself has not changed, and the client will happily re-trigger Renew / Rebind / Information-Request cycles on demand. Add a per-binding (reconf_replay, reconf_replay_seen) tuple, initialised in dhcpv6_promote_server_cand() alongside reconf_key so a fresh binding starts with a fresh window. Compare the wire replay field (network byte order, decoded with be64toh()) against the stored value before running the HMAC verification; only commit the value on a verified HMAC so a forged message cannot move the counter forward. Assisted-by: Claude:claude-opus-4-7 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens

dhcpv6: reject Reconfigure with malformed or duplicate Message option

2026-06-03T23:14:06Z

RFC 8415 §21.19 requires the Reconfigure Message option to appear exactly once in a Reconfigure message and carry a one-byte payload of RENEW, REBIND or INFO_REQ. The previous handler iterated the entire option list, silently ignored malformed (olen != 1) RECONF_MESSAGE options, accepted any number of well-formed ones, and processed the side-effects (zeroing t1/t2) for each one in turn via fall-through. Two consequences: * A Reconfigure carrying two RECONF_MESSAGE options of different types (REBIND then RENEW) would fire the REBIND fall-through (zero t2 then t1), and then the subsequent RENEW iteration would re-zero t1 — leaving the client in a state determined by the last option rather than rejecting the malformed message. * The fall-through made the per-option work look like state machine transitions when it was really just a one-shot side effect of the chosen response type. Walk the options, hard-reject duplicate RECONF_MESSAGE / wrong olen / unknown response type, and apply the t1/t2 reset once at the end based on the (validated) chosen response type. Behaviour for a spec-compliant Reconfigure is unchanged. Assisted-by: Claude:claude-opus-4-7 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens

dhcpv6: require known SERVERID when validating Reconfigure

2026-06-03T23:14:01Z

dhcpv6_response_is_valid() previously set serverid_ok = true whenever STATE_SERVER_ID was empty, on the assumption that an empty stored server-id only happens for Solicit/Advertise where the client has not yet bound to a server. The same code path is taken for Reconfigure messages (req_msg_type == DHCPV6_MSG_UNKNOWN), so a Reconfigure message that arrived while STATE_SERVER_ID was somehow empty (state corruption, an early Reconfigure delivered before binding completes, or a server-side bug) would be accepted without server identification. RFC 8415 §18.2.11 requires the SERVERID in a Reconfigure to match the server the client received the lease from. Only set serverid_ok = true on an empty stored server-id when we are not validating a Reconfigure; for DHCPV6_MSG_UNKNOWN we leave it false so the response is dropped. Assisted-by: Claude:claude-opus-4-7 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens

ra: clear captive-portal state when router signals unrestricted URI

2026-06-03T23:13:57Z

RFC 8910 §2 lets a router advertise that there is no captive portal by carrying the IANA-assigned unrestricted-portal URI in the option. The handler previously did the right thing when a real URI arrived (replace the stored value) but silently did nothing when the unrestricted URI arrived, so any URI cached from an earlier RA was retained forever and the state script kept reporting a captive portal that the network had since cleared. Move the odhcp6c_clear_state() call ahead of the unrestricted-URI check so an explicit "no captive portal" RA also drops any previously stored URI. The subsequent add_state() only runs for real URIs. Assisted-by: Claude:claude-opus-4-7 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens

odhcp6c: remove pidfile on exit

2026-06-03T23:13:52Z

Until now the pidfile was created on daemonize but never removed on clean shutdown. After a normal exit a stale pidfile sat in /var/run holding the pid of a process that no longer exists; the next time something pid-checked it (e.g. an init script doing 'kill -0 $(cat …)') it would either hit ESRCH or, in the worst case, signal an unrelated process that had recycled the pid. Remember the path we successfully opened, strdup() it so it remains valid through atexit handlers regardless of where main()'s buffer lives, and unlink() it from odhcp6c_cleanup(). We only register the path after a successful open(), so we do not unlink something we never wrote. Assisted-by: Claude:claude-opus-4-8 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens

ubus: don't leak an open table on malformed S46 rule/bind in s46_to_blob

2026-06-03T23:13:47Z

s46_to_blob() opens a per-option table with blobmsg_open_table() and only closes it at the bottom of the outer loop iteration. The length checks for an S46 rule and for an S46 v4v6bind, however, "continue" the outer loop when the embedded IPv6 prefix length is bogus (prefix6_len > 128, i.e. prefix6len > sizeof(in6)), skipping that blobmsg_close_table(). Because blob nesting must be balanced (blob_nest_end patches the parent length from buf->head), the dangling open table corrupts the emitted blob. The S46 container options are stored verbatim from the DHCPv6 reply, so a malicious server can trigger this and feed garbled state to every ubus subscriber and get_state caller. Close the table before continuing, matching the empty-table handling already used for options that match neither branch. The inner-loop DMR check is left untouched: it only continues the inner option loop, which does not own the table. Assisted-by: Claude:claude-opus-4-8 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens

ubus: walk entries correctly and don't leak an open table in entry_to_blob

2026-06-03T23:13:42Z

entry_to_blob() had two defects in its per-entry loop: 1. It iterated the state buffer with a fixed stride of sizeof(struct odhcp6c_entry) (e[i]), but odhcp6c_entry is a flexible record whose real size is odhcp6c_entry_size() - the head rounded up past a variable-length auxtarget area. This is the same bug already fixed for the script path in commit ("script: walk entries with odhcp6c_next_entry in entry_to_env"); the ubus serializer was left walking entries at the wrong offset whenever an entry carries a non-zero auxlen. 2. blobmsg_open_table() was called before the validity check, so the "continue" taken for an invalid (valid == 0) non-prefix entry skipped the matching blobmsg_close_table(). blob nesting requires balanced open/close (blob_nest_end patches the parent length from buf->head), so a dangling open table corrupts the emitted blob. A DHCPv6 server handing out an IA Address with a valid lifetime of 0 reaches this: the entry is parsed and stored just before ubus_dhcp_event() -> states_to_blob(), with no intervening odhcp6c_expire(), so the malformed table is sent to every ubus subscriber. Walk the buffer with odhcp6c_next_entry() (matching search_to_blob() and entry_to_env()) and perform the validity check before opening the table. Assisted-by: Claude:claude-opus-4-8 Link: https://github.com/openwrt/odhcp6c/pull/160 Signed-off-by: Hauke Mehrtens