lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 14 Dec 2023 21:55:10 +0100
From: Lucas Nussbaum <lucas.nussbaum@...ia.fr>
To: Ivan Vecera <ivecera@...hat.com>
Cc: Julia Lawall <julia.lawall@...ia.fr>, "David S. Miller" <davem@...emloft.net>, linux-kernel@...r.kernel.org
Subject: Re: Failed to start Raise network interfaces error

Hi,

On 12/12/23 at 17:44 +0100, Ivan Vecera wrote:
> 
> 
> On 12. 12. 23 17:33, Julia Lawall wrote:
> > > Look at 'systemd.net-naming-scheme' man page for details how the interface
> > > names are composed.
> > After booting into 6.7.0-rc4, I have the following in
> > /etc/network/interfaces:
> > 
> > # This file describes the network interfaces available on your system
> > # and how to activate them. For more information, see interfaces(5).
> > 
> > source/etc/network/interfaces.d/*
> > 
> > # The loopback network interface
> > auto lo
> > iface lo inet loopback
> > 
> > auto enp24s0f0
> > iface enp24s0f0 inet dhcp
> 
> Just change 'enp24s0f0' in /etc/network/interfaces to 'enp24s0f0np0'

But is this change of interface naming really the desired behaviour?

>From a user point of view, this is likely to cause hassle during upgrades
from older kernels (or generally when switching between kernel versions
-- think bisecting).

Is there really a benefit to that change? On a dual-port XXV710 NIC, the
naming changes from e.g. enp98s0f0 / enp98s0f1 to enp98s0f0np0 /
enp98s0f1np1, because udev previously computed the name using:
enp98s0f0: PCI path identifier: domain=0 bus=98 slot=0 func=0 phys_port= dev_port=0 → p98s0f0
and now uses:
enp98s0f0np0: PCI path identifier: domain=0 bus=98 slot=0 func=0 phys_port=p0 dev_port=0 → p98s0f0np0

Are there NICs using i40e where the function number is different from
the physical port number?

Best,

Lucas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ