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=Kh0usLic; 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 E4DC65A004E for ; Thu, 12 Feb 2026 21:09:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770926979; 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=wEaK5JrTlEdgMHxF7fe9cz2O4Ap0l57Hd2CZvTT+6Ac=; b=Kh0usLicqrzRjB/Y7Mer+ofWK4Eepp+AOlz+DACaLpSkepUoDPS8bjU2fPrOmK2ke9phSZ 2g4Euog4YJM/IfZBPc0sXTIEvRBNvWCSK0+jLMMJVxF0X22/vbdYNnwzvD6vMLKY8nC7Lg PBBuwuuG3yvVQRFoW8MNYpsdtW5nX6Y= 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-230-Mc7XxYzWOfO6EqnA8srnxA-1; Thu, 12 Feb 2026 15:09:37 -0500 X-MC-Unique: Mc7XxYzWOfO6EqnA8srnxA-1 X-Mimecast-MFC-AGG-ID: Mc7XxYzWOfO6EqnA8srnxA_1770926976 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-4359849d324so169022f8f.1 for ; Thu, 12 Feb 2026 12:09:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770926976; x=1771531776; h=date:content-transfer-encoding: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; bh=wEaK5JrTlEdgMHxF7fe9cz2O4Ap0l57Hd2CZvTT+6Ac=; b=evgAQp9l7k+SQN3bnACC7vxV/xbyHNjm85FDnf6+ssTpmPw6py/I3BiEF0Tgu9FWxh ln3FOM+V8B8AOaEfrg4x/9XZ050A/Vcs6GvK6eWZncykqhHFF32H1Mg586yOBBrWYQXU jDsC8mCQXtCtSrTMJQFupOncb6WhPBnj/FSh8tJ10QqVER03I0Wh1UP/Z5jPtNhc02mV rDeVjpyV5iKOeym/v3glquEzF+GPMzqbrohzTwRWwCsfHdFZQL2by65ERf6Qj4vOBV77 7ibG61bAYUHziFSTmNUCi0jBUXZB4/jrbZoUoQN4JhKvj8RTjhsiL3vbqiNQmrak5vpl Ug+A== X-Forwarded-Encrypted: i=1; AJvYcCWQyEP52rVgC90+uKdpfGVawlB9jwvicJpSjng5UfXANftUzhYDlYo7bilhmG+83og0f2ntR1Ac/14=@passt.top X-Gm-Message-State: AOJu0YxQLjoFhIpE6xJLXkOG+DgaKkbZRB+Z2pFtGNHV9JQf2ZKgzCuq pTnUIsZ/oFVxDB9KhHY6rdLDdKiU0y9R307u+qBCQkfwXboG1ohHtsBgE9ZTsUx7kWfyPTjCSgQ rA5+uMK7UZDRlJuEL2Zb7VrqbLN0w2YihE+fjIpFW84Lo4jizOKUIMQ== X-Gm-Gg: AZuq6aKL1UDAknEp4Rr7zNVceUiaAark8d9R/yQGydgawcEy5mROmYaUayLxEoEsrw/ f1b1vkoOd9/St3gD2hOOSHa6HnNmLJdBRE9u3Wu7CFSl1bOa/tFe+3qsEskDJODcVayg1FG2sb1 30dl+F0i1JpAf4OWGKvxhgxRAzpItCKPx0CE9AP0BeRfHGOQOqJ0DPz/EgIxzITSkwwkn5+LBW9 k2+nqPaauctC9mOZyVQzroBrxEy4HYSn8T61HWh3zkGq8/vIYWh1vAUaiQWHoyJoeSlkOkptsz/ QRvtXq9Y+CS2Pq1eHQceASb/FGLjzp/HSXNKdudpJYfzZN0jp5fOaRYWxUrR0a62TdDA7gdP28J ZIpBqYu/+5T4a+GLKsxKiNKy2YbpS1N+wdTLRLAHr53pOc0fMig== X-Received: by 2002:a05:6000:615:b0:435:bcbe:d104 with SMTP id ffacd0b85a97d-43796ad7a62mr212907f8f.34.1770926975772; Thu, 12 Feb 2026 12:09:35 -0800 (PST) X-Received: by 2002:a05:6000:615:b0:435:bcbe:d104 with SMTP id ffacd0b85a97d-43796ad7a62mr212881f8f.34.1770926975330; Thu, 12 Feb 2026 12:09:35 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796ac82f7sm266855f8f.28.2026.02.12.12.09.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Feb 2026 12:09:34 -0800 (PST) From: Stefano Brivio To: Jon Maloy Subject: Re: [PATCH v10] conf: Support CIDR notation for -a/--address option Message-ID: <20260212210932.3fb8abff@elisabeth> In-Reply-To: <20260210231845.1107905-1-jmaloy@redhat.com> References: <20260210231845.1107905-1-jmaloy@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: Thu, 12 Feb 2026 21:09:34 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: W-GaeJWDWylufk1YikWz055hLjxfIT9aPu-tKSML19M_1770926976 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: YGWEHFGLIMFRQ4SUSDYZKHXWI7N2PAMZ X-Message-ID-Hash: YGWEHFGLIMFRQ4SUSDYZKHXWI7N2PAMZ 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: dgibson@redhat.com, david@gibson.dropbear.id.au, 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: Thanks for following up, the patch looks good to me, except for the trivial conflict on ip.c which I already reported on v9 (but I can fix it myself). Just one thing I'm not sure about: On Tue, 10 Feb 2026 18:18:45 -0500 Jon Maloy wrote: > We extend the -a/--address option to accept addresses in CIDR notation > (e.g., 192.168.1.1/24 or 2001:db8::1/64) as an alternative to using > separate -a and -n options. > > We add a new inany_prefix_pton() helper function that: > - Parses address strings with a compulsory /prefix_len suffix > - Validates prefix length based on address family (0-32 for IPv4, > 0-128 for IPv6), including handling of IPv4-to-IPv6 mapping case. > > For IPv4, the prefix length is stored in ip4.prefix_len when provided. > Mixing -n and CIDR notation results in an error to catch likely user > mistakes. ...is this intended at this point: --- $ ./pasta --config-net -a 2600::/42 ip -6 a s scope global 2: enp9s0: mtu 65520 state UNKNOWN qlen 1000 inet6 2600::/64 scope global nodad valid_lft forever preferred_lft forever --- ? because yes, I see we don't store the prefix length, and I've been suggesting that always using /64 for IPv6 might make sense regardless of what we see on the host or what the user configures. But the new usage text, as well as the man page, seem to suggest that the prefix length would be taken into account for IPv6 addresses as well. If this is something that goes away in a newer version of your other series, I don't see a problem with it. I just thought I would ask if this is intended, first, before applying this. -- Stefano