From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=RTboTxfi; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 269275A0265 for ; Mon, 20 Jul 2026 09:39:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784533153; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2alRvkCLo90tgzzOObyJ8i13zQ8kmIWOi8AyWuXnShE=; b=RTboTxfiF5r5O1SaSLw4CqRrAjWhfXJHESBGuGocleQA6hhTYtSOxK7KOUxEz0YKovCuH4 xYjJ+3Gd9JOlo+PeMlIspyKt8F0hsFAdqw1A55FwosGm4zLcTLFunpW1rw7j35Da/Irqgr iM9/ReEQg4wj6QWodBcI7J32B4lHBy8= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-186-XQ7RqwVMNSy331sELWzMrg-1; Mon, 20 Jul 2026 03:39:10 -0400 X-MC-Unique: XQ7RqwVMNSy331sELWzMrg-1 X-Mimecast-MFC-AGG-ID: XQ7RqwVMNSy331sELWzMrg_1784533149 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-5aea2b3e942so6013429e87.0 for ; Mon, 20 Jul 2026 00:39:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784533149; x=1785137949; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=2alRvkCLo90tgzzOObyJ8i13zQ8kmIWOi8AyWuXnShE=; b=oZPYsJW7+7tOt8eLbsTqHyJ8Az9KAa/VbDsnHCjP1bq6czXxUn2V+1kxjUsoFZyhBk 6w3YAouTSFGHDqzelZ31cdJfc/Wqcz8lY7Dxu+Y4Z3/dPmZ7bywYaJnbBjZ8HspjkENl iwCTXUa3vQgQcUbmjilpi59AclUb4icUivEkIa/KTjJc3x4eW9NiTnfOQjDH0+LQxJr8 jdnCG1ppXtTHmnQqfqZcgs4qq9qQrJG2B55fjOHsoHe3PqPchioWT036SFfN8UgfyLXx D3GaMjG5PlVPzxFRuHWyVT7rpWDtNYlCwfK6SXyhpMsVWm/9OpdvPy2l17rwBpeGkv31 hw4g== X-Forwarded-Encrypted: i=1; AHgh+RqBNihwhIee0MYYBy0MTUytR/E+Jsi/atjWKI1QmGwniFtdO7FZP1Gjn06pXBTSydJqEMN1AgNGDek=@passt.top X-Gm-Message-State: AOJu0YxNOmxsVlypk47Fl/0RL6OlyTqamdyNY9p1NOe0RcEL5F61Byc1 Q1xXIlBidLcqQqPBQB3B8yIlAsdyKp5nujG3pri/hDfwca1j4q3xjL02ZzVp1VjuwmW5HeluX8X n0e1ud1RjYBO8MQmR8YxyX91sHkFlHTKtSYMca1n7hPbULjZY5fUXQNFlfWEWjxkFD81OGU6A5R DbJMnSwyqiYSpR6qJKLWevhaH10JnE X-Gm-Gg: AfdE7ck6PxNuLRmYkug2MyAQKZbm2WQedn5r36SRmeHTbi7XB+95YehyujaHfEUD0GK oR5hEEdo2AEtqnizrOPNthtBRiUnpistbqwnCjVNzq55w0G6S8dQwPi3dYJsh2fuGNj03ZB5FvW m03OlpIbJjntjkStAz178nsict135iv2uOlMJWa2yZuKLFulfm8dvbRHPmVFFoa7PnPKhvQmYsG /90Vztel1A+4LFCOw== X-Received: by 2002:a05:6512:63c8:10b0:5ae:bb31:4b98 with SMTP id 2adb3069b0e04-5b28f8693e9mr1510160e87.20.1784533148970; Mon, 20 Jul 2026 00:39:08 -0700 (PDT) X-Received: by 2002:a05:6512:63c8:10b0:5ae:bb31:4b98 with SMTP id 2adb3069b0e04-5b28f8693e9mr1510153e87.20.1784533148060; Mon, 20 Jul 2026 00:39:08 -0700 (PDT) MIME-Version: 1.0 References: <20260717175648.879152-1-anskuma@redhat.com> <20260717175648.879152-8-anskuma@redhat.com> In-Reply-To: From: Anshu Kumari Date: Mon, 20 Jul 2026 13:08:56 +0530 X-Gm-Features: AUfX_mxz1Je4-1OWeEX__seOnM0Eb_Qokopih03dpuHm_PFwTU71WKKgdWBwAp8 Message-ID: Subject: Re: [PATCH v5 7/7] dhcp: Handle FQDN option with RFC 3396 concatenation To: David Gibson X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: vwgXamJhaRBXgJxdjNH9PaJax6bbS-27m_h5ZOg098M_1784533149 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000006166e00657060014" Message-ID-Hash: PD5F5QWS7ZQ775NIFOBZ5BJ4BKPQP2EI X-Message-ID-Hash: PD5F5QWS7ZQ775NIFOBZ5BJ4BKPQP2EI X-MailFrom: anskuma@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: sbrivio@redhat.com, passt-dev@passt.top, lvivier@redhat.com, jmaloy@redhat.com X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000006166e00657060014 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2026 at 9:54=E2=80=AFAM David Gibson wrote: > On Fri, Jul 17, 2026 at 11:26:44PM +0530, Anshu Kumari wrote: > > 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=3D192 > > Signed-off-by: Anshu Kumari > > --- > > v5: > > - New patch: mark Client FQDN (option 81) as concatenation-requiring > 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 >=3D ARRAY_SIZE(dhcp_opt_types)) > > - return false; > > - return dhcp_opt_types[o] =3D=3D DHCP_OPT_STR_CONCAT; > > + if ((size_t)o < ARRAY_SIZE(dhcp_opt_types) && > > + dhcp_opt_types[o] =3D=3D DHCP_OPT_STR_CONCAT) > > + return true; > > + > > + /* RFC 4702, Section 2: Client FQDN option requires concatenation > */ > > + if (o =3D=3D 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 wa= y > | around. > http://www.ozlabs.org/~dgibson > --=20 Anshu --0000000000006166e00657060014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 20,= 2026 at 9:54=E2=80=AFAM David Gibson <david@gibson.dropbear.id.au> wrote:
On Fri, Jul 17, 2026 at 11:26:44PM= +0530, Anshu Kumari wrote:
> Mark Client FQDN (option 81) as concatenation-requiring per
> RFC 4702, Section 2.=C2=A0 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=3D192<= /a>
> Signed-off-by: Anshu Kumari <anskuma@redhat.com>
> ---
> v5:
>=C2=A0 =C2=A0- New patch: mark Client FQDN (option=C2=A081) as concaten= ation-requiring per RFC 4702
> ---
>=C2=A0 dhcp.c | 12 +++++++++---
>=C2=A0 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 {
>=C2=A0 =C2=A0*/
>=C2=A0 static bool is_concat_opt(int o)
>=C2=A0 {
> -=C2=A0 =C2=A0 =C2=A0if ((size_t)o >=3D ARRAY_SIZE(dhcp_opt_types))=
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return false;
> -=C2=A0 =C2=A0 =C2=A0return dhcp_opt_types[o] =3D=3D DHCP_OPT_STR_CONC= AT;
> +=C2=A0 =C2=A0 =C2=A0if ((size_t)o < ARRAY_SIZE(dhcp_opt_types) &am= p;&
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dhcp_opt_types[o] =3D=3D DHCP_OPT_S= TR_CONCAT)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return true;
> +
> +=C2=A0 =C2=A0 =C2=A0/* RFC 4702, Section 2: Client FQDN option requir= es concatenation */
> +=C2=A0 =C2=A0 =C2=A0if (o =3D=3D 81)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return true;

Why is this explicitly special cased, rather than setting the type in
the table?=C2=A0 Come to that, does this do anything, since we don't appear to currently allow option 81 anyway.

As optio= n 81 is internally supported inside passt, that's why I have not includ= ed inside table
as parsing option 81 has a special format of 3 flag bytes=C2=A0+ DNS-enc= oded domain name.

Spe= cial condition is mentioned for option 81 in=C2=A0 is_concat_opt() function= because FQDN length can exceeds=C2=A0
255 bytes for a very long domain name. Without th= is condition, such FQDN are dropped in current approach.
<= span style=3D"background-color:transparent">With this condition,=C2=A0they are split across DHCP f= ields per RFC 3396.

> +
> +=C2=A0 =C2=A0 =C2=A0return false;
>=C2=A0 }
>=C2=A0
>=C2=A0 /**
> --
> 2.54.0
>

--
David Gibson (he or they)=C2=A0 =C2=A0 =C2=A0 =C2=A0| I'll have my musi= c baroque, and my code
david AT gibson.dropbear.id.au=C2=A0 | minimalist, thank you, not th= e other way
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | around.
http://www.ozlabs.org/~dgibson


--
Anshu
--0000000000006166e00657060014--