From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=XrkpTuFq; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id C14D55A061C for ; Tue, 11 Feb 2025 11:40:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739270436; 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=upT28J3nUr6q3MeIm4KJ8pafK99Xwcs0qoc8DmFW1DA=; b=XrkpTuFqSwP8OF4jJp22vpjPZ9hPqAFSKTSWBPB0CPanK/72Bu8oQmgpY/wWa9MX56B0g8 83rwh4xlyD6Pd0hxR6q5gR053wIdFKvEKXgVJcoA/zHoNKKZcXwmYyYCwygqj4jcrx+IXV fUk7sfWoLSKm4vwSRgpgHYRSsdBPJh0= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-331-gtKm3_o2Nla7y49XQBWRVw-1; Tue, 11 Feb 2025 05:40:34 -0500 X-MC-Unique: gtKm3_o2Nla7y49XQBWRVw-1 X-Mimecast-MFC-AGG-ID: gtKm3_o2Nla7y49XQBWRVw Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-38dafe1699cso3566401f8f.3 for ; Tue, 11 Feb 2025 02:40:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739270433; x=1739875233; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QYSjpYT4MaOhIulPnJEaIkI9e6H+zqTW+7Qnh/bRL+Q=; b=CdpzsK14lQcEgxatrDHNBd0/roBrMkw7Ywu9/Ri1SxznhUEBbrrARKsqBagMeGEOaq NkHLffXWMJCccMrtFqalv+SiMMAhMAR2kIXyYB0TZJ+p1jemvmhCcLXFeWe2cD0DtMft qZLcz1ZLsDRFvXPaFUYk01JlldGhM0lxHOmJBDAV4Z7C0J6/80/+a+WjdB85QG6S5ZT9 K2X3DPFN0UhiR0mat9NyGMlZOBzB05VwxAgx6GMqaRak8UMt+8P030AO7scLXx92vOWw U1D/LS0/9z4t1HdTs6tMelv86nK2m/MSrNc+/A/yFw8ZJ3LZABt9XKiTNaKVvL6xXFmf ug2w== X-Gm-Message-State: AOJu0YyIQZuroaPM/MmgokNMWQn7wBdmiTUdZlfn+7xHXrKJ/Myq0LNy UsxdYwJueocx1lu4b2okzjGz5+Ssyto8LrRDS/lRnQeaP5RA8XBMM5DRvUrv90w76oocPKtdtgm pCchYBq39HtnxcwIbRj+pFm2bIdgdZq+ujm4NR4m8oQXAozRoPAR1f0IsbB+cRWoW+ADe00wm+J FpEYMsridvbexLYZhkxRknnJo2zMbFXklE X-Gm-Gg: ASbGncv6mCHu1ImjQZkTWH26LSOqi0pC5lmUcUl/LkWCCIPQHskRo/rEU8VE7NOglRH TOguYEkbJfTd569uZMqcNNkEAhBqQ5wtTr10kVbBLrnwKX0SHc5oJlQqcmrEeSNp/0XHcBeidda 9MdOIsgBP44PjGMBRoZ4egFvGRZRR0YFZDv2YDmiQ+JQ6eyyBLgNywjhabOoKtpk4Oc83AKdjUB jr+WWCMufkIw6mvdL26leUftHqZxhD9DCcFMmMJgQ4g509NA6DwK+vyzF3D9sQkY+OTDdtbQMlL PEouibT2uxtsIC9KAE1n5Dn/nQu8MbXPqw== X-Received: by 2002:a5d:5988:0:b0:38d:dd43:8bcd with SMTP id ffacd0b85a97d-38ddd438e9dmr8631882f8f.22.1739270432842; Tue, 11 Feb 2025 02:40:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IFKvcp9Xz0VSgCZ2gPrY7dRcOBUmoTYDUbz4oQVEnVvmE5gpK8QQhL7nBJgOWLCpEJc5nZSOw== X-Received: by 2002:a5d:5988:0:b0:38d:dd43:8bcd with SMTP id ffacd0b85a97d-38ddd438e9dmr8631748f8f.22.1739270430768; Tue, 11 Feb 2025 02:40:30 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4390db1150csm209015985e9.39.2025.02.11.02.40.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2025 02:40:29 -0800 (PST) Date: Tue, 11 Feb 2025 11:40:19 +0100 From: Stefano Brivio To: Enrique Llorente Pastora Subject: Re: [PATCH v11] dhcp, dhcpv6: Add hostname and client fqdn ops Message-ID: <20250211114019.772f522a@elisabeth> In-Reply-To: References: <20250207113655.575213-1-ellorent@redhat.com> <20250210191547.5cf0698a@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: y-ZO5xXIn7nLhUmzu0E9HKNIZ0etV1f_iuDhnL37Pco_1739270433 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: FZ7MRYQADCDXRNYIYB32ON6BD2RCHSFV X-Message-ID-Hash: FZ7MRYQADCDXRNYIYB32ON6BD2RCHSFV 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 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 Tue, 11 Feb 2025 11:36:41 +0100 Enrique Llorente Pastora wrote: > On Mon, Feb 10, 2025 at 7:15=E2=80=AFPM Stefano Brivio wrote: >=20 > > On Fri, 7 Feb 2025 12:36:55 +0100 > > Enrique Llorente wrote: > > =20 > > > Both DHCPv4 and DHCPv6 has the capability to pass the hostname to > > > clients, the DHCPv4 uses option 12 (hostname) while the DHCPv6 uses = =20 > > option 39 =20 > > > (client fqdn), for some virt deployments like kubevirt is expected to > > > have the VirtualMachine name as the guest hostname. > > > > > > This change add the following arguments: > > > - -H --hostname NAME to configure the hostname DHCPv4 option(12) > > > - --fqdn NAME to configure client fqdn option for both DHCPv4(81) an= d > > > DHCPv6(39) > > > > > > Signed-off-by: Enrique Llorente =20 > > > > I tried to break it but this time my little hammer broke instead... > > > > Applied, thanks! > > > > I noticed one (pre-existing) issue: > > =20 > > > +/* Total option size (excluding end option) is 576 (RFC 2131), minus > > > + * offset of options (268), minus end option and its length (2). > > > + */ > > > +#define OPT_MAX 306 > > > + > > > /** > > > * dhcp_init() - Initialise DHCP options > > > */ > > > @@ -122,7 +127,7 @@ struct msg { > > > uint8_t sname[64]; > > > uint8_t file[128]; > > > uint32_t magic; > > > - uint8_t o[308]; > > > + uint8_t o[OPT_MAX + 2 /* End option and its length */ ]; =20 > > > > ...actually, option 255 is special in that it takes just one byte, > > because it has no length byte. > > > > I just assumed things from my memory without re-reading the RFC, sorry > > for that. That's RFC 2131, section 3.2. > > > > It's different from option 80, Rapid Commit, RFC 4039, which takes two > > bytes (zero length, and one length byte). > > > > So we should change the two code lines above, and drop my stupid: > > > > m->o[offset++] =3D 0; >=20 > And also change the "o" declaration as the following right ? >=20 > uint8_t o[OPT_MAX + 1 /* End option */ ]; Yes. I haven't checked the rest. > > It's harmless because padding is harmless (option 0, also without > > length byte, taking one byte), but not needed, and we could stuff one > > extra byte in the response. >=20 > I will push a little follow up with these things. Thanks! --=20 Stefano