On Mon, Jul 20, 2026 at 9:54 AM David Gibson
Mark Client FQDN (option 81) as concatenation-requiring per RFC 4702, Section 2. When the encoded FQDN exceeds 255 bytes, fill() now splits it across DHCP message fields using the RFC 3396 splitting infrastructure instead of silently dropping it.
Link: https://bugs.passt.top/show_bug.cgi?id=192 Signed-off-by: Anshu Kumari
--- v5: - New patch: mark Client FQDN (option 81) as concatenation-requiring On Fri, Jul 17, 2026 at 11:26:44PM +0530, Anshu Kumari wrote: per RFC 4702
--- dhcp.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/dhcp.c b/dhcp.c index 6bebb5f..a54ac58 100644 --- a/dhcp.c +++ b/dhcp.c @@ -484,9 +484,15 @@ enum dhcp_overload { */ static bool is_concat_opt(int o) { - if ((size_t)o >= ARRAY_SIZE(dhcp_opt_types)) - return false; - return dhcp_opt_types[o] == DHCP_OPT_STR_CONCAT; + if ((size_t)o < ARRAY_SIZE(dhcp_opt_types) && + dhcp_opt_types[o] == DHCP_OPT_STR_CONCAT) + return true; + + /* RFC 4702, Section 2: Client FQDN option requires concatenation */ + if (o == 81) + return true;
Why is this explicitly special cased, rather than setting the type in the table? Come to that, does this do anything, since we don't appear to currently allow option 81 anyway.
As option 81 is internally supported inside passt, that's why I have not included inside table as parsing option 81 has a special format of 3 flag bytes + DNS-encoded domain name.
Special condition is mentioned for option 81 in is_concat_opt() function because FQDN length can exceeds 255 bytes for a very long domain name. Without this condition, such FQDN are dropped in current approach. With this condition, they are split across DHCP fields per RFC 3396.
+
+ return false; }
/** -- 2.54.0
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
-- Anshu