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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 27 Dec 2019 13:38:29 -0800 From: PGNet Dev <pgnet.dev@...il.com> To: Stephen Hemminger <stephen@...workplumber.org> Cc: netdev@...r.kernel.org Subject: Re: with kernel 5.4.6, two Eth interfaces -- one 'reliably named', the other not. used to work , what's changed? On 12/27/19 1:35 PM, Stephen Hemminger wrote: > Network renaming is not a kernel responsibility. This list is not directly relevant to your issue. > > Various user packages (usually systemd/udev) do this based on distribution. ah, I'll find a different home for it then. thx!! > On Tue, 24 Dec 2019 11:24:09 -0800 > PGNet Dev <pgnet.dev@...il.com> wrote: > >> I recently upgraded a linux/64 box to >> >> uname -rm >> 5.4.6-24.ge5f8301-default x86_64 >> >> For 'ages' prior, I've had two functional Eth interfaces on it >> >> inxi -n >> (1) Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 >> IF: eth0 state: down mac: 18:d6:c7:01:15:11 >> (2) Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 >> IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: 00:52:35:50:44:04 >> >> where (2)'s the Mobo ETH, and (1)'s an ETH PCI-e card >> >> Both expect/use the same driver, >> >> lspci -tv | grep -i eth >> +-04.0-[02]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller >> +-06.0-[03]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller >> >> >> The driver's up >> >> lsmod | grep 8169 >> r8169 94208 0 >> libphy 98304 2 r8169,realtek >> >> provided by >> >> rpm -q --whatprovides /lib/modules/5.4.6-24.ge5f8301-default/kernel/drivers/net/ethernet/realtek/r8169.ko >> kernel-default-5.4.6-24.1.ge5f8301.x86_64 >> >> the cards are available, >> >> I've had reliable naming enabled >> >> cat /proc/cmdline >> ... net.ifnames=1 biosdevname=0 >> >> and the two interfaces, Mobo & PCI, _had_ always appeared as enp2s0 & enp3s0 >> >> with current kernel, >> >> uname -rm >> 5.4.6-24.ge5f8301-default x86_64 >> >> & firmware packages, >> >> rpm -qa | grep -i kernel-firmware | sort >> kernel-firmware-all-20191118-36.13.noarch >> kernel-firmware-amdgpu-20191118-36.13.noarch >> kernel-firmware-ath10k-20191118-36.13.noarch >> kernel-firmware-atheros-20191118-36.13.noarch >> kernel-firmware-bluetooth-20191118-36.13.noarch >> kernel-firmware-bnx2-20191118-36.13.noarch >> kernel-firmware-brcm-20191118-36.13.noarch >> kernel-firmware-chelsio-20191118-36.13.noarch >> kernel-firmware-dpaa2-20191118-36.13.noarch >> kernel-firmware-i915-20191118-36.13.noarch >> kernel-firmware-intel-20191118-36.13.noarch >> kernel-firmware-iwlwifi-20191118-36.13.noarch >> kernel-firmware-liquidio-20191118-36.13.noarch >> kernel-firmware-marvell-20191118-36.13.noarch >> kernel-firmware-media-20191118-36.13.noarch >> kernel-firmware-mediatek-20191118-36.13.noarch >> kernel-firmware-mellanox-20191118-36.13.noarch >> kernel-firmware-mwifiex-20191118-36.13.noarch >> kernel-firmware-network-20191118-36.13.noarch >> kernel-firmware-nfp-20191118-36.13.noarch >> kernel-firmware-nvidia-20191118-36.13.noarch >> kernel-firmware-platform-20191118-36.13.noarch >> kernel-firmware-qlogic-20191118-36.13.noarch >> kernel-firmware-radeon-20191118-36.13.noarch >> kernel-firmware-realtek-20191118-36.13.noarch >> kernel-firmware-serial-20191118-36.13.noarch >> kernel-firmware-sound-20191118-36.13.noarch >> kernel-firmware-ti-20191118-36.13.noarch >> kernel-firmware-ueagle-20191118-36.13.noarch >> kernel-firmware-usb-network-20191118-36.13.noarch >> >> The TPLINK PCI card no longer comes up as an 'en*'-named card, per >> >> https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html >> >> but rather, incorrectly (?), as 'eth0' >> >> hwinfo --netcard | egrep -i "Ethernet controller|Driver|addr|Model:|Device:|Device file" >> 07: PCI 300.0: 0200 Ethernet controller >> Model: "Realtek RTL8111/8168 PCI Express Gigabit Ethernet controller" >> Device: pci 0x8168 "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller" >> SubDevice: pci 0x8168 "RTL8111/8168 PCI Express Gigabit Ethernet controller" >> Driver: "r8169" >> Driver Modules: "r8169" >> Device File: enp3s0 >> HW Address: 00:52:35:50:44:04 >> Permanent HW Address: 00:52:35:50:44:04 >> Driver Info #0: >> Driver Status: r8169 is active >> Driver Activation Cmd: "modprobe r8169" >> 11: PCI 200.0: 0200 Ethernet controller >> Model: "TP-LINK TG-3468 Gigabit PCI Express Network Adapter" >> Device: pci 0x8168 "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller" >> SubDevice: pci 0x3468 "TG-3468 Gigabit PCI Express Network Adapter" >> Driver: "r8169" >> Driver Modules: "r8169" >> ?? Device File: eth0 >> HW Address: 18:d6:c7:01:15:11 >> Permanent HW Address: 18:d6:c7:01:15:11 >> Driver Info #0: >> Driver Status: r8169 is active >> Driver Activation Cmd: "modprobe r8169" >> >> noting, >> >> ls -1 /sys/class/net/ >> enp3s0@ >> eth0@ >> lo@ >> >> in `dmesg` >> >> dmesg | egrep -i "eth|enp" >> [ 4.564854] r8169 0000:02:00.0 eth0: RTL8168e/8111e, 18:d6:c7:01:15:11, XID 2c2, IRQ 27 >> [ 4.564856] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] >> [ 4.568641] r8169 0000:03:00.0 eth1: RTL8168c/8111c, 00:52:35:50:44:04, XID 3c4, IRQ 18 >> [ 4.568643] r8169 0000:03:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko] >> [ 4.614030] r8169 0000:03:00.0 enp3s0: renamed from eth1 >> [ 28.179613] RTL8211B Gigabit Ethernet r8169-300:00: attached PHY driver [RTL8211B Gigabit Ethernet] (mii_bus:phy_addr=r8169-300:00, irq=IGNORE) >> [ 28.283488] r8169 0000:03:00.0 enp3s0: Link is Down >> [ 30.498955] r8169 0000:03:00.0 enp3s0: Link is Up - 1Gbps/Full - flow control rx/tx >> [ 30.498976] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready >> >> Something's changed -- as both interfaces used to be properly named per reliable-naming standard. >> >> I _can_ bring up the network on the Mobo's renamed enp3s0 interface ... but no longer on the PCI card. >> >> I'm not clear on why one interface IS using the reliable-naming scheme, and the other is NOT. >> >> Any hints/clues as to the problem &/or a fix? >> > > Network renaming is not a kernel responsibility. This list is not directly relevant > to your issue. > > Various user packages (usually systemd/udev) do this based on distribution. > > The naming schemes mostly rely on information reported by sysfs, such as PCI address, slot or other > values. Look for any changes in that information that might cause naming to change. I.e one > version had PCI slot information, and the other did not. > > Read the documentation here: https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html > To see what the systemd policy is. >
Powered by blists - more mailing lists