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=BMT4x9s2; 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 DCDBC5A026E for ; Wed, 01 Jul 2026 19:00:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782925224; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zepTq5sIgyDEZ81xAUPaCT05RsDp3RcRI71UsYQeeys=; b=BMT4x9s2yvAC3lYm5osN2Urig+E6smvSQolGd1dxA15urEYi8i+sqCNHjExkNay8CnMFWF 0wxXNw8z2hey3tmObTfUyzpyuZX38SYkdOQGMG7N1mgqyN4pf/yvcLadDk+rU1Np357xYT EIYgYisnb3bhhQ7DPXoZ75YUnMr2ZOI= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-586-ezKfKG4HMGqW9HGFNIKynA-1; Wed, 01 Jul 2026 13:00:21 -0400 X-MC-Unique: ezKfKG4HMGqW9HGFNIKynA-1 X-Mimecast-MFC-AGG-ID: ezKfKG4HMGqW9HGFNIKynA_1782925220 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-475eba52438so933824f8f.3 for ; Wed, 01 Jul 2026 10:00:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782925220; x=1783530020; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=zepTq5sIgyDEZ81xAUPaCT05RsDp3RcRI71UsYQeeys=; b=iH3YMxJ5yPCO3C6OhXXdqruCOb1bf5rwoW3y2N0IAxCdGqR4//7c2fkgfU1sZGFguR 5TEHc9E24Wazq76/msXPnk++h04Fp1tNTrubMHR6BB27GoVj/312lFJYn3NfTPxJjS0s stumVeIxfjL0XS/vefPLw66IseBy4DmOYhm8zMH90YDV17AxL0z0LVNWBHvJELWd1JhR U8JsrabVCni9MQGsFI1ssAxv2hL27eqXpKNtbOD/iCCLuyUcgx6+0SstNlZAjJ5yLTr+ ujDK0k4+nkdIqwhwyP4i/i1cNUfzrnkFzLWDPaYuNqqmskTAgLS1VTX14iPWUxvmWuiw qYfQ== X-Gm-Message-State: AOJu0YxaZWOYcIdWq3u8BpZdVnyzpvRIepOy8na0HPwYMG0XYxw/atKN NNPqoSr6cRfHgN+aW1qQKLHJ+EQWbWJQJvb7N8AILXtLp7hGmR04aQPtfXqFT5xbjIqU3Mph8r4 ZFy1eCdoT19BP+Yj+19jTZSQrwaDFwhYArCZCGsiwk8FNAMnEXuJmkw== X-Gm-Gg: AfdE7ckD0qgq2Y/7y05v4Cm5Su2nEh7lvI2gYm9R87iyAaxGgBxQStKPvo6q9Tldlnm Zh35UtQBUu1/GlunAYuTFeNHESO+Trc/qqB1OZZa9eBUPi92hTOvMbXk0qIJVGakghq8SawrzXH bVBA5U0Gadh/6p0usVPwcsOWJhAvqodrccRya4uG4VUs3DEPvO3OTQkiXQdVocjOfnSqthOvonD kGcnerCCHbR9Lgd4FpG+Q+6r2PI64NS7RX5UfrkTYmoC3Lx7N4Q/Ln5ZNJB3tdglqv2LYpQyQDE VusNBkP25QaLAIQeNhIQDnk2VSN7J1Wt3k7hqBAOoACd3oIcfOWh5bPB3RIKwCCYFMufcQRyVwo niN0XHhalRftkv0saQ2rZ4DvEmpPbSXZd41YCyD8= X-Received: by 2002:adf:ed02:0:b0:46a:bcab:3c2 with SMTP id ffacd0b85a97d-477b5296a0emr1771000f8f.34.1782925219829; Wed, 01 Jul 2026 10:00:19 -0700 (PDT) X-Received: by 2002:adf:ed02:0:b0:46a:bcab:3c2 with SMTP id ffacd0b85a97d-477b5296a0emr1770939f8f.34.1782925219108; Wed, 01 Jul 2026 10:00:19 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-477dd94cde8sm1497351f8f.22.2026.07.01.10.00.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 10:00:18 -0700 (PDT) From: Stefano Brivio To: Anshu Kumari Subject: Re: [PATCH v4 2/4] dhcp: Add option overload Message-ID: <20260701190017.0c7f0436@elisabeth> In-Reply-To: <20260617132243.1499556-3-anskuma@redhat.com> References: <20260617132243.1499556-1-anskuma@redhat.com> <20260617132243.1499556-3-anskuma@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Wed, 01 Jul 2026 19:00:17 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Slp6Jcg6umLYNgoQIsLFJWKZ6cjAT0pXtzFL2h9TorI_1782925220 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: GVG46AWUNAOGSGTJBFPXF6I4E3FXDUEB X-Message-ID-Hash: GVG46AWUNAOGSGTJBFPXF6I4E3FXDUEB X-MailFrom: sbrivio@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: passt-dev@passt.top, jmaloy@redhat.com, david@gibson.dropbear.id.au, lvivier@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: On Wed, 17 Jun 2026 18:52:36 +0530 Anshu Kumari wrote: > [...] > > +static enum dhcp_overload fill_overflow(struct msg *m, bool has_bootfile) > +{ > + enum dhcp_overload overload = DHCP_OVERLOAD_NONE; > + int sname_off = 0, file_off = 0; > + int o; > + > + for (o = 0; (size_t)o < ARRAY_SIZE(opts); o++) { > + if (opts[o].slen == -1 || opts[o].sent) > + continue; > + fill_one(m->sname, sizeof(m->sname) - 1, o, &sname_off); > + } > + > + if (!has_bootfile) { > + for (o = 0; (size_t)o < ARRAY_SIZE(opts); o++) { > + if (opts[o].slen == -1 || opts[o].sent) > + continue; > + if (fill_one(m->file, sizeof(m->file) - 1, o, > + &file_off)) > + debug("DHCP: skipping option %i" > + " (overload full)", o); > + } > + } else { > + for (o = 0; (size_t)o < ARRAY_SIZE(opts); o++) { > + if (opts[o].slen == -1 || opts[o].sent) > + continue; > + debug("DHCP: skipping option %i (overload full)", o); > + } > + } Sorry for not mentioning this earlier: reviewing the DHCPv6 series reminded me of RFC 3396. Skip right away to Section 8 for an example: https://datatracker.ietf.org/doc/html/rfc3396#section-8 ...but note that the applicability is rather limited, see Section 4: A DHCP protocol agent SHOULD NOT split an option as described in this document unless it has no choice, or it knows that its peer can properly handle split options. A peer is assumed to properly handle split options if it has provided or requested at least one concatenation-requiring option. [...] What are concatenation-requiring options? I'm not aware of any list, but Internet Draft draft-tojens-dhcp-option-concat-considerations-01 (expired without becoming an RFC) has a list of examples, at least: https://www.ietf.org/archive/id/draft-tojens-dhcp-option-concat-considerations-01.html#section-1 and, from there, I actually realised that our current implementation of RFC 4702 (FQDN option) is not complete because Section 2 requires that: [...] DHCP clients and servers supporting this option MUST implement DHCP option concatenation [9]. In the terminology of [9], the Client FQDN option is a concatenation-requiring option. While the draft reports a practical issue with the implementation of RFC 3396 itself (in Section 4), it's just an expired draft at this point, so we can't safely go with the changes proposed in Section 6. However, they look very reasonable. Note that RFC 3396 comes with an additional nuisance: it defines a strict ordering of the buffers, where 'file' comes before 'sname'. That only applies if there are split options, of course, otherwise the order is not relevant. But if we want to keep trying with 'sname' before 'file', which I think makes sense, this complicates the implementation. We have two options, I think: 1. keep the implementation as it is, ignoring RFC 3396. If somebody tries to configure an option that's longer than 255 bytes, or finds a realistic use case where options don't fit, but would fit if split, we'll think what to do 2. fix things for real... maybe it's not _that_ complicated, I'm not sure: a. mark concatenation-requiring options (say, with a type that's handled in the same way as _STR, for example STR_CONCAT) b. define the maximum supported length for those options as 64 + 128 + 312 - 2 * 3 (sname plus file plus options minus three instances of length and code). Resize the buffer in 'opts' to 496 bytes (regardless of the option code, for simplicity). c. keep trying to fill options in the current order, options field first, then sname, then file. Keep counts of how many bytes we use in each section. d. if we reach this point ("we have no choice") with one of those, see if we can fit it by splitting it (this needs a separate loop because we need to follow the options/file/sname order) e. if we can't (sum of available bytes less than length of option), just skip and print the message, but if we can, add as much as we need, starting from the options field, then file, then sname I would quickly look at option 2., not so much because of RFC 3396 (it adds fundamental problems that aren't currently addressed, so we can assume that it's not universally or completely implemented anyway), but rather because of RFC 4702 and similar, which we're not implementing properly at the moment. If it's exceedingly complicated, I'd suggest to fall back to 1. instead. After all, we never had reports from users not being able to fit the options they wanted. -- Stefano