From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 1C27B1FF13C for ; Thu, 05 Feb 2026 16:56:56 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7075F15B4D; Thu, 5 Feb 2026 16:57:27 +0100 (CET) From: Maximiliano Sandoval To: "Shannon Sterz" Subject: Re: [pve-devel] [PATCH proxmox-widget-toolkit] ui: mac-prefix-validation In-Reply-To: (Shannon Sterz's message of "Fri, 08 Nov 2024 12:41:23 +0100") References: <20241108113049.263998-1-m.almalat@proxmox.com> User-Agent: mu4e 1.12.9; emacs 30.1 Date: Thu, 05 Feb 2026 16:56:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770306934498 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.086 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: WJ5VS7B5S7BHFYSL77KO5ZCH7ZXNZCEP X-Message-ID-Hash: WJ5VS7B5S7BHFYSL77KO5ZCH7ZXNZCEP X-MailFrom: m.sandoval@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Proxmox VE development discussion X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: "Shannon Sterz" writes: > On Fri Nov 8, 2024 at 12:30 PM CET, Moayad Almalat wrote: >> >> Allow four-octet MAC prefixes in Web UI validation >> update the MAC prefix validation in the Web UI to support four-octet >> prefixes. >> >> Signed-off-by: Moayad Almalat >> --- >> src/Toolkit.js | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/Toolkit.js b/src/Toolkit.js >> index 8a0138d..42dbfaa 100644 >> --- a/src/Toolkit.js >> +++ b/src/Toolkit.js >> @@ -70,7 +70,7 @@ Ext.apply(Ext.form.field.VTypes, { >> MacAddressText: gettext('Example') + ': 01:23:45:67:89:ab', >> >> MacPrefix: function(v) { >> - return (/^[a-f0-9][02468ace](?::[a-f0-9]{2}){0,2}:?$/i).test(v); >> + return (/^[a-f0-9][02468ace](?::[a-f0-9]{2}){0,3}:?$/i).test(v); > > this still does not match `BC:24:11:0` as we recommend in our docs as > this regex requires the fourth octet to also be complete and not just a > nible. you could do something like this: > > ``` > /^[a-f0-9][02468ace](?::[a-f0-9]{2}){0,2}(?::[a-f0-9]{0,2})?:?$/i > ``` > > this would allow the last octet to be incomplete too, but i wonder if at > that point we want to generally allow longer prefixes and just make sure > that a prefix address is not a) a multicast prefix b) a broadcast prefix > and c) a complete set of 6 octets. that may be simpler and more future > proof? Regarding this point, if you pick an apple from a bag with N apples k times, returning the apple to the bag each time, the probability for picking different apples each time is f(k,N) = 1 * (N - 1)/N * ... * (N - (k - 1)) / N thus the probability of picking at least one apple more than once (which would be bad) would be g(k,N) = 1 - f(k, N). With our current longest prefix `00:00:00:` we have 16^6 = 16.777.216 available mac addresses, and with this patch with the longest prefix `00:00:00:00:` we are down to 16^4 = 65.536 options. One can check that g(100, 16777216) = 0.000295 g(100, 1048576) = 0.004710 # with a prefix like 00:00:00:0 g(100, 65536) = 0.072784 g(100, 4096) = 0.072784 # if we allowed 00:00:00:00:0 So the chances of mac address collisions on a system with 100 guest goes from ~0.03% to ~7.3% with the proposal here, adding one more hex value would leave us at a ~73% probability of having at least one collision. Given the effect of such a collision I would rather be conservative on how much this is extended. > >> }, >> MacPrefixMask: /[a-fA-F0-9:]/, >> MacPrefixText: gettext('Example') + ': 02:8f - ' + gettext('only unicast addresses are allowed'), > > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel -- Maximiliano