Hi,
Thank you!
On 2/24/26 2:00 PM, Fabian Grünbichler wrote:
> typo in the subject - a 4-bit prefix makes no sense 😉
In the subject I meant to say 4-bit suffix extension to mac_prefix. I
can send v3 if needed.
>
> On February 24, 2026 1:05 pm, Moayad Almalat wrote:
>> Signed-off-by: Moayad Almalat <[email protected]>
>> ---
>> src/Toolkit.js | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/Toolkit.js b/src/Toolkit.js
>> index d4e579b..39513b8 100644
>> --- a/src/Toolkit.js
>> +++ b/src/Toolkit.js
>> @@ -72,7 +72,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,2}:?|[a-f0-9][02468ace](?::[a-f0-9]{2}){2}:[a-f0-9])$/i.test(v);
>
> I think this is not quite correct - the [02468ace] part here is for only
> allowing unicast addresses, but that only applies to the first octet!
>
> the old regex allowed 1-3 octets (with the first octet always being
> restricted to not allow multicast), and you want to extend it to 4
> octets AFAIU? that would simply require replacing the `{0,2}` with a
> `{0,3}`, I think?
>
> but note that the backend in PVE has the same checks and would need to
> be adapted as well..
>
The unicast restrection applies only to the first octet, both
alternatives start at the beginning, so that part is unchanged.
The intent is to allow a single extra hex nibble after 3 full octets
e.g., `BC:24:11:0` and I tested that in 3 LXC:
```
root@pve-a:/tmp# pct config 102 | grep hwaddr
....hwaddr=BC:24:11:0E:0B:F3,ip=dhcp,ip6=auto,type=veth
root@pve-a:/tmp# pct config 103 | grep hwaddr
....hwaddr=BC:24:11:0A:DD:DD,ip=dhcp,ip6=auto,type=veth
root@pve-a:/tmp# pct config 104 | grep hwaddr
....hwaddr=BC:24:11:06:58:1C,ip=dhcp,ip6=auto,type=veth
root@pve-a:/tmp#
```
>> },
>> MacPrefixMask: /[a-fA-F0-9:]/,
>> MacPrefixText:
>> --
>> 2.47.3
>>
>>
>>
