[pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Christian Ebner]

The installer assumes to have a valid mac address for all interfaces
as provided by the runtime env json file. Deserialization will fail
if this is not the case.

In some cases, the interface might however not provide a valid MAC
address, for example the WWAN module without any SIM installed on
some laptops.

Fix this by defaulting to an all zero MAC address if non is detected.

Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
---
Please note: Untested, but I can test it based on an iso installer on
affected hardware

 Proxmox/Install/RunEnv.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm
index e4f0eb0..d7ee258 100644
--- a/Proxmox/Install/RunEnv.pm
+++ b/Proxmox/Install/RunEnv.pm
@@ -110,7 +110,7 @@ my sub query_netdevs : prototype() {
         $ifs->{$name} = {
             index => $index,
             name => $name,
-            mac => $mac,
+            mac => $mac // '00:00:00:00:00:00',
             state => uc($state),
         };
         $ifs->{$name}->{addresses} = \@valid_addrs if @valid_addrs;
-- 
2.47.2



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Christian Ebner]

On 7/11/25 10:03, Christian Ebner wrote:
> The installer assumes to have a valid mac address for all interfaces
> as provided by the runtime env json file. Deserialization will fail
> if this is not the case.
> 
> In some cases, the interface might however not provide a valid MAC
> address, for example the WWAN module without any SIM installed on
> some laptops.
> 
> Fix this by defaulting to an all zero MAC address if non is detected.
> 
> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>

Forgot to add:

Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Gabriel Goller]

On 11.07.2025 10:03, Christian Ebner wrote:
>The installer assumes to have a valid mac address for all interfaces
>as provided by the runtime env json file. Deserialization will fail
>if this is not the case.
>
>In some cases, the interface might however not provide a valid MAC
>address, for example the WWAN module without any SIM installed on
>some laptops.
>
>Fix this by defaulting to an all zero MAC address if non is detected.
>
>Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>---
>Please note: Untested, but I can test it based on an iso installer on
>affected hardware
>
> Proxmox/Install/RunEnv.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm
>index e4f0eb0..d7ee258 100644
>--- a/Proxmox/Install/RunEnv.pm
>+++ b/Proxmox/Install/RunEnv.pm
>@@ -110,7 +110,7 @@ my sub query_netdevs : prototype() {
>         $ifs->{$name} = {
>             index => $index,
>             name => $name,
>-            mac => $mac,
>+            mac => $mac // '00:00:00:00:00:00',
>             state => uc($state),
>         };
>         $ifs->{$name}->{addresses} = \@valid_addrs if @valid_addrs;

To be honest I'd rather filter out this interface. A zeroed out mac is
reserved for loopback interfaces and usually isn't routed.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Christian Ebner]

On 7/11/25 10:27, Gabriel Goller wrote:
> On 11.07.2025 10:03, Christian Ebner wrote:
>> The installer assumes to have a valid mac address for all interfaces
>> as provided by the runtime env json file. Deserialization will fail
>> if this is not the case.
>>
>> In some cases, the interface might however not provide a valid MAC
>> address, for example the WWAN module without any SIM installed on
>> some laptops.
>>
>> Fix this by defaulting to an all zero MAC address if non is detected.
>>
>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>> ---
>> Please note: Untested, but I can test it based on an iso installer on
>> affected hardware
>>
>> Proxmox/Install/RunEnv.pm | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm
>> index e4f0eb0..d7ee258 100644
>> --- a/Proxmox/Install/RunEnv.pm
>> +++ b/Proxmox/Install/RunEnv.pm
>> @@ -110,7 +110,7 @@ my sub query_netdevs : prototype() {
>>         $ifs->{$name} = {
>>             index => $index,
>>             name => $name,
>> -            mac => $mac,
>> +            mac => $mac // '00:00:00:00:00:00',
>>             state => uc($state),
>>         };
>>         $ifs->{$name}->{addresses} = \@valid_addrs if @valid_addrs;
> 
> To be honest I'd rather filter out this interface. A zeroed out mac is
> reserved for loopback interfaces and usually isn't routed.

Okay, given that it might be better to filter it out and log that.

Will send a v2 (including the subject prefix `pve-installer` I did 
forget on this patch)


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] superseded: [PATCH] run-env: fallback to all zero mac for interfaces without

[Christian Ebner]

superseded-by version 2:
https://lore.proxmox.com/pve-devel/30178a02-c6a4-4cb5-b5e7-f421dde03245@proxmox.com/T/


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Thomas Lamprecht]

Am 11.07.25 um 10:27 schrieb Gabriel Goller:
> On 11.07.2025 10:03, Christian Ebner wrote:
>> The installer assumes to have a valid mac address for all interfaces
>> as provided by the runtime env json file. Deserialization will fail
>> if this is not the case.
>>
>> In some cases, the interface might however not provide a valid MAC
>> address, for example the WWAN module without any SIM installed on
>> some laptops.
>>
>> Fix this by defaulting to an all zero MAC address if non is detected.
>>
>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>> ---
>> Please note: Untested, but I can test it based on an iso installer on
>> affected hardware
>>
>> Proxmox/Install/RunEnv.pm | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm
>> index e4f0eb0..d7ee258 100644
>> --- a/Proxmox/Install/RunEnv.pm
>> +++ b/Proxmox/Install/RunEnv.pm
>> @@ -110,7 +110,7 @@ my sub query_netdevs : prototype() {
>>         $ifs->{$name} = {
>>             index => $index,
>>             name => $name,
>> -            mac => $mac,
>> +            mac => $mac // '00:00:00:00:00:00',
>>             state => uc($state),
>>         };
>>         $ifs->{$name}->{addresses} = \@valid_addrs if @valid_addrs;
> 
> To be honest I'd rather filter out this interface. A zeroed out mac is
> reserved for loopback interfaces and usually isn't routed.

It's not like we set the MAC to zero, rather it's just used for displaying.
This way an admin can at least see the interface and select it for usage,
even if they then need to correctly configure it manually after installation
to make it actually work.

That said, as manual intervention is required either way, filtering out
might be OK, but your arguments here are IMO not justifying why that route
should be chosen. FWIW, a third alternative might be that the rust
implementation might also just have to learn to not expect a MAC...


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Christoph Heiss]

On Fri Jul 11, 2025 at 11:14 AM CEST, Thomas Lamprecht wrote:
> Am 11.07.25 um 10:27 schrieb Gabriel Goller:
[..]
>> To be honest I'd rather filter out this interface. A zeroed out mac is
>> reserved for loopback interfaces and usually isn't routed.
>
> It's not like we set the MAC to zero, rather it's just used for displaying.
> This way an admin can at least see the interface and select it for usage,
> even if they then need to correctly configure it manually after installation
> to make it actually work.
>
> That said, as manual intervention is required either way, filtering out
> might be OK, but your arguments here are IMO not justifying why that route
> should be chosen. FWIW, a third alternative might be that the rust
> implementation might also just have to learn to not expect a MAC...

FWIW, there's also been a Bugzilla report a few days about this problem
[0].

I've took a cursory glance at going about the third route here, although
didn't really get to write much code due to other, more pressing things.

If anyone wants to pick that up, short summary w.r.t the Rust part:

- It's mostly about doing a `String` -> `Option<String>` conversion for
  `proxmox_installer_common::setup::Interface`, the MAC address from
  that is then only ever used the post-hook.
- There's also `proxmox_auto_installer::sysinfo::NetdevWithMac`, which
  tries to read the MAC address from /sys/class/net.

[0] https://bugzilla.proxmox.com/show_bug.cgi?id=6508


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Christian Ebner]

On 7/11/25 11:47, Christoph Heiss wrote:
> On Fri Jul 11, 2025 at 11:14 AM CEST, Thomas Lamprecht wrote:
>> Am 11.07.25 um 10:27 schrieb Gabriel Goller:
> [..]
>>> To be honest I'd rather filter out this interface. A zeroed out mac is
>>> reserved for loopback interfaces and usually isn't routed.
>>
>> It's not like we set the MAC to zero, rather it's just used for displaying.
>> This way an admin can at least see the interface and select it for usage,
>> even if they then need to correctly configure it manually after installation
>> to make it actually work.
>>
>> That said, as manual intervention is required either way, filtering out
>> might be OK, but your arguments here are IMO not justifying why that route
>> should be chosen. FWIW, a third alternative might be that the rust
>> implementation might also just have to learn to not expect a MAC...
> 
> FWIW, there's also been a Bugzilla report a few days about this problem
> [0].
> 
> I've took a cursory glance at going about the third route here, although
> didn't really get to write much code due to other, more pressing things.
> 
> If anyone wants to pick that up, short summary w.r.t the Rust part:
> 
> - It's mostly about doing a `String` -> `Option<String>` conversion for
>    `proxmox_installer_common::setup::Interface`, the MAC address from
>    that is then only ever used the post-hook.
> - There's also `proxmox_auto_installer::sysinfo::NetdevWithMac`, which
>    tries to read the MAC address from /sys/class/net.
> 
> [0] https://bugzilla.proxmox.com/show_bug.cgi?id=6508

Okay, can have a look at this too, but do feel free to beat me to it! 
Not so familiar with the installer codebase and this smells like having 
some regression potential.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Thomas Lamprecht]

Am 11.07.25 um 12:03 schrieb Christian Ebner:
> On 7/11/25 11:47, Christoph Heiss wrote:
>> On Fri Jul 11, 2025 at 11:14 AM CEST, Thomas Lamprecht wrote:
>>> Am 11.07.25 um 10:27 schrieb Gabriel Goller:
>> [..]
>>>> To be honest I'd rather filter out this interface. A zeroed out mac is
>>>> reserved for loopback interfaces and usually isn't routed.
>>>
>>> It's not like we set the MAC to zero, rather it's just used for displaying.
>>> This way an admin can at least see the interface and select it for usage,
>>> even if they then need to correctly configure it manually after installation
>>> to make it actually work.
>>>
>>> That said, as manual intervention is required either way, filtering out
>>> might be OK, but your arguments here are IMO not justifying why that route
>>> should be chosen. FWIW, a third alternative might be that the rust
>>> implementation might also just have to learn to not expect a MAC...
>>
>> FWIW, there's also been a Bugzilla report a few days about this problem
>> [0].
>>
>> I've took a cursory glance at going about the third route here, although
>> didn't really get to write much code due to other, more pressing things.
>>
>> If anyone wants to pick that up, short summary w.r.t the Rust part:
>>
>> - It's mostly about doing a `String` -> `Option<String>` conversion for
>>    `proxmox_installer_common::setup::Interface`, the MAC address from
>>    that is then only ever used the post-hook.
>> - There's also `proxmox_auto_installer::sysinfo::NetdevWithMac`, which
>>    tries to read the MAC address from /sys/class/net.
>>
>> [0] https://bugzilla.proxmox.com/show_bug.cgi?id=6508
> 
> Okay, can have a look at this too, but do feel free to beat me to it! 
> Not so familiar with the installer codebase and this smells like having 
> some regression potential.

Yeah, maybe, that's why simply falling back to some "unknown"-like value
sounded promising to me. If we do not have any parsing/checks for the MAC
value, we could indeed fall back to a literal "unknown", then it would be
noticed if we try to use it (e.g., for interface link name-pinning in the
installer)

btw. what does the interface looks like, does it really have no MAC
in the ip link output?




_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH] run-env: fallback to all zero mac for interfaces without

[Christian Ebner]

On 7/11/25 12:25, Thomas Lamprecht wrote:
> Am 11.07.25 um 12:03 schrieb Christian Ebner:
>> On 7/11/25 11:47, Christoph Heiss wrote:
>>> On Fri Jul 11, 2025 at 11:14 AM CEST, Thomas Lamprecht wrote:
>>>> Am 11.07.25 um 10:27 schrieb Gabriel Goller:
>>> [..]
>>>>> To be honest I'd rather filter out this interface. A zeroed out mac is
>>>>> reserved for loopback interfaces and usually isn't routed.
>>>>
>>>> It's not like we set the MAC to zero, rather it's just used for displaying.
>>>> This way an admin can at least see the interface and select it for usage,
>>>> even if they then need to correctly configure it manually after installation
>>>> to make it actually work.
>>>>
>>>> That said, as manual intervention is required either way, filtering out
>>>> might be OK, but your arguments here are IMO not justifying why that route
>>>> should be chosen. FWIW, a third alternative might be that the rust
>>>> implementation might also just have to learn to not expect a MAC...
>>>
>>> FWIW, there's also been a Bugzilla report a few days about this problem
>>> [0].
>>>
>>> I've took a cursory glance at going about the third route here, although
>>> didn't really get to write much code due to other, more pressing things.
>>>
>>> If anyone wants to pick that up, short summary w.r.t the Rust part:
>>>
>>> - It's mostly about doing a `String` -> `Option<String>` conversion for
>>>     `proxmox_installer_common::setup::Interface`, the MAC address from
>>>     that is then only ever used the post-hook.
>>> - There's also `proxmox_auto_installer::sysinfo::NetdevWithMac`, which
>>>     tries to read the MAC address from /sys/class/net.
>>>
>>> [0] https://bugzilla.proxmox.com/show_bug.cgi?id=6508
>>
>> Okay, can have a look at this too, but do feel free to beat me to it!
>> Not so familiar with the installer codebase and this smells like having
>> some regression potential.
> 
> Yeah, maybe, that's why simply falling back to some "unknown"-like value
> sounded promising to me. If we do not have any parsing/checks for the MAC
> value, we could indeed fall back to a literal "unknown", then it would be
> noticed if we try to use it (e.g., for interface link name-pinning in the
> installer)
> 
> btw. what does the interface looks like, does it really have no MAC
> in the ip link output?

No, the only content for the link line is `link/none`, no mac and brd 
address.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel