From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202606 header.b=pT87DmXt; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 41D0B5A0269 for ; Mon, 27 Jul 2026 05:34:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1785123294; bh=wz0apjGhgeWQcinTHofLtE55IYYW0ZGYIWdAOJf6OdU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pT87DmXtDCRomyOVJzr4r9yr4n4oQ+LIIQjENJgQvarUSN51rwIYZNB/f/hRFYfj7 4LKAAqa8Y5iYQXyabBGhGT2eLq9CDxG89pFARjSdxsjy4QOVFTg3Ns4qA//0qW5vSE bL/KvafRceCE5hvtpbQr2swO1puahzMgpnGCyS5NG9Mp2TtV2+MRScD+tUy2LUQzFQ 2hCq9MTe/NSdr/BKK5bjc+kbfplHbKX557I9A8gkDJoWIrD8g4px5x7yuuTjrd40EE OJ3a4nHtMMMAc9ip/0KtQ9OT+8ys7lbV8G4Wj+pfcorHWmnyYxtlfRERf8EuXvNntd 6T83wrfZ8Q0JA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4h7kk646Hxz4w1p; Mon, 27 Jul 2026 13:34:54 +1000 (AEST) Date: Mon, 27 Jul 2026 13:00:28 +1000 From: David Gibson To: Anshu Kumari Subject: Re: [PATCH v5 6/7] dhcp: Add RFC 3396 option splitting for concatenation-requiring options Message-ID: References: <20260717175648.879152-1-anskuma@redhat.com> <20260717175648.879152-7-anskuma@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MSu4qwXi+lp7n2hI" Content-Disposition: inline In-Reply-To: Message-ID-Hash: UE74R5PNLGN36KHBSEASWRELLU3KCEK3 X-Message-ID-Hash: UE74R5PNLGN36KHBSEASWRELLU3KCEK3 X-MailFrom: dgibson@gandalf.ozlabs.org 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: --MSu4qwXi+lp7n2hI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2026 at 02:44:34PM +0530, Anshu Kumari wrote: > On Mon, Jul 20, 2026 at 9:54=E2=80=AFAM David Gibson > wrote: >=20 > > On Fri, Jul 17, 2026 at 11:26:43PM +0530, Anshu Kumari wrote: > > > Implement option splitting per RFC 3396 for options that may exceed > > > 255 bytes. A new DHCP_OPT_STR_CONCAT type marks concatenation- > > > requiring options (currently option 81, Client FQDN per RFC 4702). > > > > > > The opts[].s buffer is resized from 255 to 496 bytes to hold the > > > maximum data that can be split across the options field, file field, > > > and sname field. > > > > > > When a concatenation-requiring option does not fit as a single option > > > in any field, fill() splits it across fields in RFC 3396 order: > > > options field first, then file, then sname. > > > > > > Link: https://bugs.passt.top/show_bug.cgi?id=3D192 > > > Signed-off-by: Anshu Kumari > > > --- > > > v5: > > > - New patch: implement option splitting per RFC 3396 for options > > exceeding 255 bytes > > > - Add DHCP_OPT_STR_CONCAT type, is_concat_opt(), fill_split() helpe= rs > > > - Resize opts[].s from 255 to OPT_CONCAT_MAX (496) bytes > > > - Add /* fallthrough */ between DHCP_OPT_STR and DHCP_OPT_STR_CONCAT > > case > > > > > > --- > > > dhcp.c | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++++++= -- > > > 1 file changed, 106 insertions(+), 3 deletions(-) > > > > > > diff --git a/dhcp.c b/dhcp.c > > > index cc910ee..6bebb5f 100644 > > > --- a/dhcp.c > > > +++ b/dhcp.c > > > @@ -34,6 +34,11 @@ > > > #include "log.h" > > > #include "dhcp.h" > > > > > > +/* RFC 3396: maximum option data that can be split across options fi= eld, > > > + * file field, and sname field (minus code+length overhead per porti= on). > > > + */ > > > +#define OPT_CONCAT_MAX 496 > > > + > > > /** > > > * enum opt_state - DHCP option state > > > * @OPT_UNSET: Option not configured > > > @@ -58,7 +63,7 @@ enum opt_state { > > > struct opt { > > > int sent; > > > int slen; > > > - uint8_t s[255]; > > > + uint8_t s[OPT_CONCAT_MAX]; > > > int clen; > > > uint8_t c[255]; > > > enum opt_state state; > > > @@ -159,6 +164,7 @@ struct msg { > > > * @DHCP_OPT_UINT16: Unsigned 16-bit integer > > > * @DHCP_OPT_UINT32: Unsigned 32-bit integer > > > * @DHCP_OPT_INT32: Signed 32-bit integer > > > + * @DHCP_OPT_STR_CONCAT:Concatenation-requiring string (RFC 3396) > > > > It's not entirely clear to me that encoding this in the opt_type enum > > makes sense. Generally the dhcp_opt_type is saying how the option is > > encoded as a string for the user. This is saying how it's encoded > > within the DHCP packet itself, which seems qualitatively different > > information. > > > > Since we don't limit on the string length that user can set via > --dhcp-opt, DHCP_OPT_STR rejects > anything over 255 bytes but with STR_CONCAT longer input can be parsed. >=20 > is_concat_opt() checks dhcp_opt_types[] for STR_CONCAT to decide which > options need splitting in fill(). > I think these two concerns are coupled: an option that accepts long strin= gs > from the CLI > is exactly the same option that needs splitting on the wire. Ah, ok. I see the case for including this in the type now. However, I still think it's not the best approach on balance. Remember that unless there's only one option, the practical limit on the length of these options will be shorter - 256 is just an upper bound. We can calculate different upper bounds depending on whether it's a concat option or not, but I wouldn't consider it exactly part of the type. If we store the concat bit in a separate field of the options table, we can still apply that different upper bound calculation. Plus, we can also use it for things of other types without introducing yet more type variants. Similarly we can use it for fqdn, or anything else we don't have a parsing type for at present. --=20 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 --MSu4qwXi+lp7n2hI Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmpmybsACgkQzQJF27ox 2GeFUxAAm+N/t3QpJrGIbUodWp5w+Na0o17p3HCKPR8hRaP5oE65iR7gGPMivpY2 WBuSF04yuWJhGi/rNO+Jjae3/agt+2nqkRpqj/xn2M9OAYC1T3E5milkKlWfKCNU UijjbxajHkkCYJwn5ZzD8iEcEajcgXBxVLwEBIZvtXgUwE3lbjEFrgVGfiWqqNr2 /vJKcw3exSELK8qfXKq3wu2D2s8W0g7eqX2GuGQjj3cgR6LIRbduQ84V+knaNdSH J5W29UZjeMGh3k9V44JGD47mPyQPKVCYtDWIDzKJlOqYX88F2iMRwd7Xl1xSNVqs jAppxsF+hTrkqfNLOMYcfYHveIWFpS12fm1hYrG4yS/8PzAgBnxC+wr7hxnt5Vks lTCcOMuWDnRucmS05JitmkK2enXuw9dC542SmsLp7y3LOrhdQNJ/FwTICJ+/enVu ygByDlQ5h1g5e/e15Wpa+YPCryIBbD3VTKixtRXVxuXHS0AJnj/oorT8o6qgOE10 h224JPLIi1/tt8AoAV0oSzqNLUYnVJ6JAgPkHtI28EYU5m+yvTgHwoznVGPgeQTC PIASwrDpSCcufteKEpwl982xIy9cBVqyYuXjpZoqoovEm7gzgVSzpP+9vMG8nLlF qQyoZtCU+YC+qqlxYX6X66EvJH6RIPKzdzgoTL8Ls/Dx9kcEvT8= =mhcF -----END PGP SIGNATURE----- --MSu4qwXi+lp7n2hI--