Re: Ethernet not working on a Dell notebook

[Max Nikulin]

On 16/03/2024 16:18, fran...@libero.it wrote:


root@debian:/home/frantal# networkctl
WARNING: systemd-networkd is not running, output will be incomplete.


OK, so all devices are under control of NetworkManager and there is no 
modification of its global configuration.



root@debian:/home/frantal# lspci
13:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)


In https://lists.debian.org/msgid-search/uspugc$u42$1...@ciao.gmane.io I 
asked for


lspci -vnn -s 13:00.0

and if the "firmware-realtek" package is installed

https://lists.debian.org/msgid-search/ut0d7u$o4o$1...@ciao.gmane.io

What is the reason to install r8168 and what is its origin? r8168-dkms? 
From realtek site directly?


Have you tried kernel installed from bookworm-backports?

I hope the following should provide informative log for a suitable time 
frame.


- Unplug ethernet cable
- Start journalctl as root (e.g. "sudo -i" at first)
  journalctl -o short-precise -f | tee /tmp/cable.log
- Plug in the cable
- Wait ~15 seconds
- Kill the process by [Ctrl+C]

If unrelated system activity happened at this moment then it is better 
to repeat. The result should be saved to /tmp/cable.log (or another file 
you like).


P.S. The "reply to list" button on the mail list archive pages should 
properly set In-Reply-To message headers to keep discussion within a 
thread. Does your mailer support it?

Re: Ethernet not working on a Dell notebook

[Stefan Monnier]

> advantage. Plugged in cable is detected immediately. With dhclient running
> by ifupdown, it may take some minutes till next DHCP request is sent.

[ It can take *many* minutes.  ]
You can use `ifplugd` to make it react to plugging/unplugging the cable,
in case you don't want to use NetworkManager.


Stefan

Re: Ethernet not working on a Dell notebook

[Franco Martelli]

On 15/03/24 at 03:53, Max Nikulin wrote:

On 13/03/2024 23:53, Franco Martelli wrote:

On 13/03/24 at 16:06, Max Nikulin wrote:

On 13/03/2024 21:52, Franco Martelli wrote:

They can coexist. NetworkManager in default configuration ignores 
interfaces under control of ifupdown (/etc/network/interfaces).


Detailed messages from NetworkManager related to carrier change 
events are missed in the posted log file, so the interface is 
configured by ifupdown.



Sorry Max I always knew that they cannot, my mistake…


My fault was that I tried to find NetworkManager manager messages in 
dmesg log. I have never tried to enable control of ifupdown interfaces 
in NetworkManager. In my opinion, on laptops commenting out interface in 
/etc/network/interfaces and so delegating it to NetworkManager has a 
clear advantage. Plugged in cable is detected immediately. With dhclient 
running by ifupdown, it may take some minutes till next DHCP request is 
sent.


Thanks for clarification, I never installed NetworkManager so this it 
seemed to me new.


The system may have significant changes in respect to defaults. 
Concerning NetworkManager, the following commands might give some 
additional info


    networkctl
    nmcli device
    nmcli connection
    /usr/sbin/NetworkManager --print-config

I am unsure if the line in /etc/network/interfaces had some effect since 
device name is enp19s0 and the file contained eth0.


On 13/03/2024 16:52, fran...@libero.it wrote:
[    2.771916] r8168: module verification failed: signature and/or 
required key missing - tainting kernel


tells that not r8169 from default kernel is used. What is the reason to 
install r8168 and what is its origin? r8168-dkms? From realtek site 
directly?


These questions are greats, sadly it's so hard to help Francesco 
(fran...@libero.it) he misses also the concept of variable assignment:


https://lists.debian.org/debian-user/2024/03/msg00332.html

I asked concerning more detailed lspci output and firmware package, but 
I have got no response. If firmware is installed then I would try 
backports kernel.


If cabling issues have been ruled out then perhaps it is time to ask in 
a realtek-related mailing list/forum/bugtracker.




I dunno, there are so many things unanswered…


https://wiki.archlinux.org/title/Talk:Network_configuration/Ethernet

So after configured the interfaces, you could try to add "iommu=soft 
amd_iommu" to the kernel command-line


Even if it might help, do not forget to disable it if it has no effect. 
To verify


     cat /proc/cmdline


It had no effect, I already told to restore to Francesco but I haven't 
verified


https://lists.debian.org/debian-user/2024/03/msg00336.html

he told that he has reverted the changes:

https://lists.debian.org/debian-user/2024/03/msg00362.html

--
Franco Martelli

Re: Ethernet not working on a Dell notebook

[Max Nikulin]

On 13/03/2024 23:53, Franco Martelli wrote:

On 13/03/24 at 16:06, Max Nikulin wrote:

On 13/03/2024 21:52, Franco Martelli wrote:

They can coexist. NetworkManager in default configuration ignores 
interfaces under control of ifupdown (/etc/network/interfaces).


Detailed messages from NetworkManager related to carrier change 
events are missed in the posted log file, so the interface is 
configured by ifupdown.



Sorry Max I always knew that they cannot, my mistake…


My fault was that I tried to find NetworkManager manager messages in 
dmesg log. I have never tried to enable control of ifupdown interfaces 
in NetworkManager. In my opinion, on laptops commenting out interface in 
/etc/network/interfaces and so delegating it to NetworkManager has a 
clear advantage. Plugged in cable is detected immediately. With dhclient 
running by ifupdown, it may take some minutes till next DHCP request is 
sent.


The system may have significant changes in respect to defaults. 
Concerning NetworkManager, the following commands might give some 
additional info


   networkctl
   nmcli device
   nmcli connection
   /usr/sbin/NetworkManager --print-config

I am unsure if the line in /etc/network/interfaces had some effect since 
device name is enp19s0 and the file contained eth0.


On 13/03/2024 16:52, fran...@libero.it wrote:

[2.771916] r8168: module verification failed: signature and/or required key 
missing - tainting kernel


tells that not r8169 from default kernel is used. What is the reason to 
install r8168 and what is its origin? r8168-dkms? From realtek site 
directly?


I asked concerning more detailed lspci output and firmware package, but 
I have got no response. If firmware is installed then I would try 
backports kernel.


If cabling issues have been ruled out then perhaps it is time to ask in 
a realtek-related mailing list/forum/bugtracker.



https://wiki.archlinux.org/title/Talk:Network_configuration/Ethernet

So after configured the interfaces, you could try to add "iommu=soft 
amd_iommu" to the kernel command-line


Even if it might help, do not forget to disable it if it has no effect. 
To verify


cat /proc/cmdline

Re: Ethernet not working on a Dell notebook

[Marco Moock]

Am 14.03.2024 um 17:13:12 Uhr schrieb fran...@libero.it:

> After rebooting the problem remains. 

What does dmesg say?

-- 
Gruß
Marco

Send spam to 1710432792mu...@cartoonies.org

Re: Ethernet not working on a Dell notebook

[Franco Martelli]

On 14/03/24 at 17:03, fran...@libero.it wrote:

Hello,
I did as indicated, but the connection needs the command
sudo mii-tool enp19s0 -F 10baseT-FD to enable.


revert the change to /etc/default/grub remove -iommu=soft amd_iommu-
strings:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

run again:

~# update-grub

then reboot the system.

I'm not confident with NetworkManager, maybe others readers have a 
solution for this issue, try to ask again for help posting the output of 
the following command:


~# journalctl --no-pager -b -t NetworkManager

--
Franco Martelli

Fwd: Re: Ethernet not working on a Dell notebook

[frantal]

I remove auto eth0

After rebooting the problem remains. 

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback
> 
> -- Messaggio originale --
> Da: Marco Moock 
> A: debian-user@lists.debian.org
> Data: 14/03/2024 09:38 CET
> Oggetto: Re: Ethernet not working on a Dell notebook
> 
>  
> Am 14.03.2024 schrieb fran...@libero.it:
> 
> > auto eth0
> 
> remove that.

Re: Ethernet not working on a Dell notebook

[Franco Martelli]

On 14/03/24 at 09:07, fran...@libero.it wrote:

Hi,
good morning. This is the command:
 /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" iommu=soft amd_iommu
GRUB_CMDLINE_LINUX="">



Nope the line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" iommu=soft amd_iommu
↑
must be:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash iommu=soft amd_iommu"
 ↑
then post the output of the following command:

~# update-grub

whether no error message, then reboot the system.

--
Franco Martelli

Re: Ethernet not working on a Dell notebook

[Marco Moock]

Am 14.03.2024 schrieb fran...@libero.it:

> auto eth0

remove that.

Re: Ethernet not working on a Dell notebook

[frantal]

root@debian:/home/frantal# dmesg |grep r8169
root@debian:/home/frantal# sudo dmesg |grep r8169
root@debian:/home/frantal# cat /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 eth0

> Il 14/03/2024 09:19 CET Marco Moock  ha scritto:
> 
>  
> How is /etc/network/interfaces now configured?
> 
> Unconfigure your interface there and only use the NetworkManager.
> 
> Then it should log about autoneg.
> 
> What does 
> dmesg |grep r8169
> print?

Re: Ethernet not working on a Dell notebook

[frantal]

Here again the answer of journalctl:
p19s0): state change: config -> ip-config (reason 'none', sys-iface-state: 
'managed')
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.7907] dhcp4 
(enp19s0): activation: beginning transaction (timeout in 45 seconds)
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.8003] dhcp4 
(enp19s0): state changed new lease, address=192.168.1.12
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.8017] policy: 
set 'Connessione via cavo 1' (enp19s0) as default for IPv4 routing and DNS
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.8140] device 
(enp19s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 
'managed')
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.8709] device 
(enp19s0): state change: ip-check -> secondaries (reason 'none', 
sys-iface-state: 'managed')
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.8716] device 
(enp19s0): state change: secondaries -> activated (reason 'none', 
sys-iface-state: 'managed')
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.8725] manager: 
NetworkManager state is now CONNECTED_SITE
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.8732] device 
(enp19s0): Activation: successful, device activated.
mar 14 09:02:25 debian NetworkManager[565]:   [1710403345.8750] manager: 
NetworkManager state is now CONNECTED_GLOBAL
root@debian:/home/frantal# 

> Il 13/03/2024 21:06 CET Marco Moock  ha scritto:
> 
>  
> Am 13.03.2024 um 17:53:40 Uhr schrieb Franco Martelli:
> 
> > Sadly the useful information of the command output is truncated,
> > could you post it again maximizing the window before you copy? For
> > the journalctl command use this synta
> 
> Call journalctl with --no-pager and the full line will be shown and
> wrapped where needed.
> 
> -- 
> Gruß
> Marco
> 
> Send spam to 1710348820mu...@cartoonies.org

Re: Ethernet not working on a Dell notebook

[Marco Moock]

How is /etc/network/interfaces now configured?

Unconfigure your interface there and only use the NetworkManager.

Then it should log about autoneg.

What does 
dmesg |grep r8169
print?

Re: Ethernet not working on a Dell notebook

[Marco Moock]

Am 13.03.2024 um 17:53:40 Uhr schrieb Franco Martelli:

> Sadly the useful information of the command output is truncated,
> could you post it again maximizing the window before you copy? For
> the journalctl command use this synta

Call journalctl with --no-pager and the full line will be shown and
wrapped where needed.

-- 
Gruß
Marco

Send spam to 1710348820mu...@cartoonies.org

Re: Ethernet not working on a Dell notebook

[Franco Martelli]

On 13/03/24 at 18:20, fran...@libero.it wrote:

Hello,
I did
I tried to modify as suggested.I couldn't use sudo update-grub
So I gave this command:

I think there is an error in the procedure
Waiting for suggestions...


What is the output of:

~# cat /etc/default/grub | head -10


--
Franco Martelli

Re: Ethernet not working on a Dell notebook

[frantal]

Hello,
I did
I tried to modify as suggested.I couldn't use sudo update-grub 
So I gave this command:

I think there is an error in the procedure
Waiting for suggestions...
Francesco


> Il 13/03/2024 18:10 CET Franco Martelli  ha scritto:
> 
>  
> On 13/03/24 at 17:51, fran...@libero.it wrote:
> > Sorry what is the procedure to add "iommu=soft
> >> amd_iommu" to the kernel command-line?
> > It is the first time I work with kernel.
> > I went to /etc/default/grub and on the line GRUB_CMDLINE_LINUX_DEFAULT I 
> > have ="quiet splash"
> > Have I to add ?
> > Thanks for the help
> > Francesco
> 
> Your line in /etc/default/grub becomes:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash iommu=soft amd_iommu"
> 
> then run:
> 
> ~# update-grub
> 
> then reboot the system.
> 
> HTH
> -- 
> Franco Martelli

Re: Ethernet not working on a Dell notebook

[Franco Martelli]

On 13/03/24 at 17:51, fran...@libero.it wrote:

Sorry what is the procedure to add "iommu=soft

amd_iommu" to the kernel command-line?

It is the first time I work with kernel.
I went to /etc/default/grub and on the line GRUB_CMDLINE_LINUX_DEFAULT I have 
="quiet splash"
Have I to add ?
Thanks for the help
Francesco


Your line in /etc/default/grub becomes:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash iommu=soft amd_iommu"

then run:

~# update-grub

then reboot the system.

HTH
--
Franco Martelli

Re: Ethernet not working on a Dell notebook

[frantal]

'managed')
mar 11 16:48:25 debian NetworkManager[626]:   [1710172105.9482] manager: 
NetworkManager state is now CONNECTING
mar 11 16:48:25 debian NetworkManager[626]:   [1710172105.9850] device 
(wlp18s0b1): set-hw-addr: reset MAC address to C4:17:FE:D7:54:E2 (preserve)
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0060] device 
(wlp18s0b1): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0072] device 
(wlp18s0b1): Activation: (wifi) access point 'TIM-21837165' has security, but 
secrets are required.
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0073] device 
(wlp18s0b1): state change: config -> need-auth (reason 'none', sys-iface-state: 
'managed')
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0082] 
sup-iface[6f24c84b1a640cf6,1,wlp18s0b1]: wps: type pbc start...
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0095] device 
(wlp18s0b1): supplicant interface state: disconnected -> interface_disabled
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0132] device 
(wlp18s0b1): state change: need-auth -> prepare (reason 'none', 
sys-iface-state: 'managed')
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0146] device 
(wlp18s0b1): state change: prepare -> config (reason 'none', sys-iface-state: 
'managed')
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0159] device 
(wlp18s0b1): Activation: (wifi) connection 'TIM-21837165' has security, and 
secrets exist.  No new secrets needed.
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0160] Config: 
added 'ssid' value 'TIM-21837165'
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0161] Config: 
added 'scan_ssid' value '1'
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0162] Config: 
added 'bgscan' value 'simple:30:-70:86400'
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0163] Config: 
added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK'
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0164] Config: 
added 'psk' value ''
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0285] device 
(wlp18s0b1): supplicant interface state: interface_disabled -> inactive
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.0798] device 
(wlp18s0b1): supplicant interface state: inactive -> authenticating
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.2434] device 
(wlp18s0b1): supplicant interface state: authenticating -> disconnected
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.3441] device 
(wlp18s0b1): supplicant interface state: disconnected -> scanning
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.4593] device 
(wlp18s0b1): supplicant interface state: scanning -> authenticating
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.4715] device 
(wlp18s0b1): supplicant interface state: authenticating -> associating
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.5200] device 
(wlp18s0b1): supplicant interface state: associating -> associated
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.5376] device 
(wlp18s0b1): supplicant interface state: associated -> 4way_handshake
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.6023] device 
(wlp18s0b1): supplicant interface state: 4way_handshake -> completed
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.6024] device 
(wlp18s0b1): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. 
Connected to wireless network "TIM-21837165"
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.6031] device 
(wlp18s0b1): state change: config -> ip-config (reason 'none', sys-iface-state: 
'managed')
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.6051] dhcp4 
(wlp18s0b1): activation: beginning transaction (timeout in 45 seconds)
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.6245] dhcp4 
(wlp18s0b1): state changed new lease, address=192.168.1.228
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.6263] policy: 
set 'TIM-21837165' (wlp18s0b1) as default for IPv4 routing and DNS
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.6442] device 
(wlp18s0b1): state change: ip-config -> ip-check (reason 'none', 
sys-iface-state: 'managed')
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.7091] device 
(wlp18s0b1): state change: ip-check -> secondaries (reason 'none', 
sys-iface-state: 'managed')
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.7099] device 
(wlp18s0b1): state change: secondaries -> activated (reason 'none', 
sys-iface-state: 'managed')
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.7109] manager: 
NetworkManager state is now CONNECTED_SITE
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.7123] device 
(wlp18s0b1): Activation: successful, device activated.
mar 11 16:48:26 debian NetworkManager[626]:   [1710172106.7141] manager: 
NetworkManager state is now

Re: Ethernet not working on a Dell notebook

[Marco Moock]

Am 13.03.2024 um 16:14:22 Uhr schrieb fran...@libero.it:

> mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4031]
> dhcp4 (en> mar 13 11:55:20 debian NetworkManager[569]: 
> [1710327320.4152] dhcp4 (en>

Use journalctl --no-pager -t NetworkManager
to get the complete lines.

-- 
Gruß
Marco

Send spam to 1710342862mu...@cartoonies.org

Re: Ethernet not working on a Dell notebook

[frantal]

Asking to CahtGPT was just for curiosity hoping for an eventual addressing 
where to go
About commands you suggest, hereunder the answer:

 Active: failed (Result: exit-code) since Wed 2024-03-13 11:54:42 CET; 4h 1>
   Docs: man:interfaces(5)
Process: 536 ExecStart=/sbin/ifup -a --read-environment (code=exited, statu>
Process: 635 ExecStopPost=/usr/bin/touch /run/network/restart-hotplug (code>
   Main PID: 536 (code=exited, status=1/FAILURE)
CPU: 80ms

mar 13 11:54:41 debian systemd[1]: Starting networking.service - Raise network >
mar 13 11:54:42 debian ifup[536]: ifup: unknown interface eth0
mar 13 11:54:42 debian systemd[1]: networking.service: Main process exited, cod>
mar 13 11:54:42 debian systemd[1]: networking.service: Failed with result 'exit>
mar 13 11:54:42 debian systemd[1]: Failed to start networking.service - Raise n>

root@debian:/home/frantal# sudo systemctl status NetworkManager.service
● NetworkManager.service - Network Manager
 Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; prese>
 Active: active (running) since Wed 2024-03-13 11:54:42 CET; 4h 13min ago
   Docs: man:NetworkManager(8)
   Main PID: 569 (NetworkManager)
  Tasks: 3 (limit: 9340)
 Memory: 14.6M
CPU: 1.326s
 CGroup: /system.slice/NetworkManager.service
 └─569 /usr/sbin/NetworkManager --no-daemon

mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4031] dhcp4 (en>
mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4152] dhcp4 (en>
mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4177] policy: s>
mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4366] device (e>
mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4932] device (e>
mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4938] device (e>
mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4949] manager: >
mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4958] device (e>
mar 13 11:55:20 debian NetworkManager[569]:   [1710327320.4996] manager: >
mar 13 14:55:18 debian NetworkManager[569]:   [1710338118.8885] dhcp4 (en>

root@debian:/home/frantal# sudo journalctl -u NetworkManager.service
ago 09 01:48:22 debian systemd[1]: Starting Network Manager...
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.0709] NetworkMa>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.0710] Read conf>
ago 09 01:48:23 debian systemd[1]: Started Network Manager.
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.0836] bus-manag>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.0968] manager[0>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.0968] monitorin>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2567] hostname:>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2567] hostname:>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2574] dns-mgr[0>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2590] rfkill0: >
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2593] manager[0>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2593] manager[0>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2739] Loaded de>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2818] Loaded de>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2872] Loaded de>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2891] Loaded de>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2942] Loaded de>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2947] manager: >
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2949] manager: >
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2951] manager: >
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2953] dhcp-init>
ago 09 01:48:23 debian NetworkManager[545]:   [1660002503.2997] settings:>

 
> Il 13/03/2024 15:52 CET Franco Martelli  ha scritto:
> 
>  
> On 13/03/24 at 10:19, fran...@libero.it wrote:
> > Hello,
> > 
> > thanks for your answers.
> > 
> > I used the cable with other notebooks and it worked.
> > 
> > In any case I used another cable to test it, but I had the same 
> > reactions, no connection!
> > 
> > Today I had to give the command 3 times before having a connection...
> 
> Do you have configured both NetworkManager and Debian 
> /etc/network/interfaces? They cannot coexist, instead to ask to ChatGPT 
> try this reading:
> 
> https://wiki.debian.org/it/NetworkConfiguration
> 
> What is it the output of the following commands?
> 
> ~$ sudo systemctl status networking.service
> 
> ~$ sudo systemctl status NetworkManager.service
> 
> ~$ sudo journalctl -u  NetworkManager.service
> 
> -- 
> Franco Martelli

Re: Ethernet not working on a Dell notebook

[Max Nikulin]

On 13/03/2024 21:52, Franco Martelli wrote:
Do you have configured both NetworkManager and Debian 
/etc/network/interfaces? They cannot coexist,


They can coexist. NetworkManager in default configuration ignores 
interfaces under control of ifupdown (/etc/network/interfaces).


Detailed messages from NetworkManager related to carrier change events 
are missed in the posted log file, so the interface is configured by 
ifupdown.

Re: Ethernet not working on a Dell notebook

[Franco Martelli]

On 13/03/24 at 10:19, fran...@libero.it wrote:

Hello,

thanks for your answers.

I used the cable with other notebooks and it worked.

In any case I used another cable to test it, but I had the same 
reactions, no connection!


Today I had to give the command 3 times before having a connection...


Do you have configured both NetworkManager and Debian 
/etc/network/interfaces? They cannot coexist, instead to ask to ChatGPT 
try this reading:


https://wiki.debian.org/it/NetworkConfiguration

What is it the output of the following commands?

~$ sudo systemctl status networking.service

~$ sudo systemctl status NetworkManager.service

~$ sudo journalctl -u  NetworkManager.service

--
Franco Martelli

Re: Ethernet not working on a Dell notebook

[frantal]

Here the "long" output of the 2 requested commands:
[0.306974] pci :14:00.0: proprietary Ricoh MMC controller disabled (via 
FireWire function)
[0.306975] pci :14:00.0: MMC cards are now supported by standard SDHCI 
controller
[0.306977] pci :14:00.0: [1180:e822] type 00 class 0x080500
[0.307030] pci :14:00.0: reg 0x10: [mem 0xfbc03000-0xfbc030ff]
[0.307351] pci :14:00.0: supports D1 D2
[0.307353] pci :14:00.0: PME# supported from D0 D1 D2 D3hot
[0.307710] pci :14:00.1: [1180:e230] type 00 class 0x088000
[0.307752] pci :14:00.1: reg 0x10: [mem 0xfbc02000-0xfbc020ff]
[0.308059] pci :14:00.1: supports D1 D2
[0.308061] pci :14:00.1: PME# supported from D0 D1 D2 D3hot
[0.308288] pci :14:00.3: [1180:e832] type 00 class 0x0c0010
[0.308330] pci :14:00.3: reg 0x10: [mem 0xfbc0-0xfbc007ff]
[0.308520] pci :14:00.3: Enabling fixed DMA alias to 00.0
[0.308626] pci :14:00.3: supports D1 D2
[0.308627] pci :14:00.3: PME# supported from D0 D1 D2 D3hot D3cold
[0.308936] pci :00:1c.3: PCI bridge to [bus 14]
[0.308945] pci :00:1c.3:   bridge window [mem 0xfbc0-0xfbcf]
[0.309128] pci :00:1c.4: PCI bridge to [bus 15]
[0.309134] pci :00:1c.4:   bridge window [io  0xc000-0xcfff]
[0.309139] pci :00:1c.4:   bridge window [mem 0xfb20-0xfbbf]
[0.309146] pci :00:1c.4:   bridge window [mem 0xd210-0xd2af 
64bit pref]
[0.309197] pci_bus :20: extended config space not accessible
[0.309300] pci :00:1e.0: PCI bridge to [bus 20] (subtractive decode)
[0.309325] pci :00:1e.0:   bridge window [io  0x-0x0cf7 window] 
(subtractive decode)
[0.309328] pci :00:1e.0:   bridge window [io  0x0d00-0x window] 
(subtractive decode)
[0.309330] pci :00:1e.0:   bridge window [mem 0x000a-0x000b 
window] (subtractive decode)
[0.309332] pci :00:1e.0:   bridge window [mem 0xc000-0x 
window] (subtractive decode)
[0.310457] ACPI: PCI: Interrupt link LNKA configured for IRQ 11
[0.310553] ACPI: PCI: Interrupt link LNKB configured for IRQ 5
[0.310635] ACPI: PCI: Interrupt link LNKC configured for IRQ 3
[0.310728] ACPI: PCI: Interrupt link LNKD configured for IRQ 4
[0.310820] ACPI: PCI: Interrupt link LNKE configured for IRQ 0
[0.310913] ACPI: PCI: Interrupt link LNKF configured for IRQ 0
[0.311006] ACPI: PCI: Interrupt link LNKG configured for IRQ 10
[0.311087] ACPI: PCI: Interrupt link LNKH configured for IRQ 11
[0.311783] iommu: Default domain type: Translated 
[0.311783] iommu: DMA domain TLB invalidation policy: lazy mode 
[0.311783] pps_core: LinuxPPS API ver. 1 registered
[0.311783] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo 
Giometti 
[0.311783] PTP clock support registered
[0.311783] EDAC MC: Ver: 3.0.0
[0.312445] NetLabel: Initializing
[0.312447] NetLabel:  domain hash size = 128
[0.312448] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[0.312483] NetLabel:  unlabeled traffic allowed by default
[0.312485] PCI: Using ACPI for IRQ routing
[0.328550] PCI: Discovered peer bus ff
[0.328552] PCI: root bus ff: using default resources
[0.328553] PCI: Probing PCI hardware (bus ff)
[0.328612] PCI host bridge to bus :ff
[0.328614] pci_bus :ff: root bus resource [io  0x-0x]
[0.328617] pci_bus :ff: root bus resource [mem 0x-0xf]
[0.328619] pci_bus :ff: No busn resource found for root bus, will use 
[bus ff-ff]
[0.328621] pci_bus :ff: busn_res: can not insert [bus ff] under domain 
[bus 00-ff] (conflicts with (null) [bus 00-ff])
[0.328643] pci :ff:00.0: [8086:2c62] type 00 class 0x06
[0.328746] pci :ff:00.1: [8086:2d01] type 00 class 0x06
[0.328839] pci :ff:02.0: [8086:2d10] type 00 class 0x06
[0.328916] pci :ff:02.1: [8086:2d11] type 00 class 0x06
[0.329004] pci :ff:02.2: [8086:2d12] type 00 class 0x06
[0.329100] pci :ff:02.3: [8086:2d13] type 00 class 0x06
[0.329201] pci_bus :ff: busn_res: [bus ff] end is updated to ff
[0.329204] pci_bus :ff: busn_res: can not insert [bus ff] under domain 
[bus 00-ff] (conflicts with (null) [bus 00-ff])
[0.329210] PCI: pci_cache_line_size set to 64 bytes
[0.329358] e820: reserve RAM buffer [mem 0x0009d400-0x0009]
[0.329361] e820: reserve RAM buffer [mem 0xbf594000-0xbfff]
[0.329363] e820: reserve RAM buffer [mem 0xbf80-0xbfff]
[0.329398] pci :01:00.0: vgaarb: setting as boot VGA device
[0.329398] pci :01:00.0: vgaarb: bridge control possible
[0.329398] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.329398] vgaarb: loaded
[0.333298] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[0.25] hpet0: 8 comparat

Re: Ethernet not working on a Dell notebook

[Marco Moock]

Am 13.03.2024 um 10:19:04 Uhr schrieb fran...@libero.it:

> So I give a try to ask to ChatGPT what does it mean that command and
> this was the answer:

This was already clear.
The question is now: Why does autoneg fail?

Please check dmesg and journalctl for any messages from Networkmanager.

-- 
Gruß
Marco

Send spam to 1710321544mu...@cartoonies.org

Re: Ethernet not working on a Dell notebook

[Max Nikulin]

On 12/03/2024 15:11, fran...@libero.it wrote:

13:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 
PCI Express Gigabit Ethernet Controller (rev 03)


lspci -vnn -s 13:00.0

should give more detailed info concerning your network adapter.

Finally while trying to find the solution I tried this command and after 
some seconds I was online:


sudo mii-tool enp19s0 -F 10baseT-FD


Perhaps it is obvious, but do you have the firmware-realtek package 
installed?


Inspect journalctl output, NetworkManager should log negotiation failures.

Re: Ethernet not working on a Dell notebook

[Marco Moock]

Am 12.03.2024 um 10:17:05 Uhr schrieb fran...@libero.it:

> it is connected via a Switch (Netgear) to the modem-router. 
> If I use this cable with other computers it works without problems.

Please test another cable and another switch if available. We need to
track down the problem.

-- 
Gruß
Marco

Send spam to 1710235025mu...@cartoonies.org

Re: Ethernet not working on a Dell notebook

[Anssi Saari]

fran...@libero.it writes:

> sudo mii-tool enp19s0 -F 10baseT-FD
>
> The problem is that every time I shut off the notebook Ito have ethernet 
> connection again I have to give that command by terminal. Is
> there the possibility to make default this ethernet module? Thanks and regards

You can specify ethtool commands to be run in /etc/network/interfaces,
see /usr/share/doc/ethtool/README.Debian for details. I'm not sure
if that'll work with NetworkManager, though.

But, having to force 10baseT probably indicates other issues like a bad
cable, as Marco said.

Re: Ethernet not working on a Dell notebook

[Marco Moock]

Am 12.03.2024 um 09:11:20 Uhr schrieb fran...@libero.it:

> Finally while trying to find the solution I tried this command and
> after some seconds I was online:
> 
> sudo mii-tool enp19s0 -F 10baseT-FD

That seems to be an autoneg problem.

Please tell us more about your cabling (direct, via sockets etc.) and
the device (switch, router) the laptop is connected to.

-- 
kind regards
Marco

Send spam to 1710231080mu...@cartoonies.org

Re: Ethernet device names change Bullseye => Bookworm. How to assign unchanging name to device?

[Markus Schönhaber]

20.06.23, 08:36 +0200, Rick Thomas:


I've been upgrading my machines Bullseye => Bookworm recently.  In a few of these 
upgrades, the name of the ethernet device changed.  (E.g. enP2p32s15f0 => 
enP2p0s15f0)  This required changes to /etc/network/interfaces in order to start up 
the interface.

This is only a minor inconvenience (though it may require me to take a drive 
out 30 miles to the location where a few of these machines reside -- no 
problem, it's a beautiful drive!)

However, I seem to remember that once upon a time there was a way to get (I think it 
involved udev) the system to assign an arbitrary name (e.g. (enet0") to a given 
interface based on something that doesn't change when the firmware/driver gets 
upgraded. For example, the MAC address for an Ethernet interface would be a good 
basis.

The trouble is that it was a while ago and I can't remember how to do that?

Any hints will be appreciated.  Pointers to documentation on the subject would 
be especially helpful!


systemd.link should be a way to get this done:



--
Regards
  mks

Re: Ethernet Performance Problem Solved

[Marc Auslander]

On 9/6/2022 5:00 PM, Marc Auslander wrote:
I have an Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express 
Fast/Gigabit Ethernet controller (rev 02) Subsystem: Acer Incorporated 
[ALI] RTL810xE PCI Express Fast Ethernet controller


There is also a Realtek Semiconductor Co., Ltd. Device 8161 (rev 15)
     Subsystem: Realtek Semiconductor Co., Ltd. Device 8168 100BaseT not 
being used.


lspci -v says the driver is R8169 for both.

firmware-realtek is installed and does not appear to provide R8169 but 
I'm a novice about these things.


The cable leading to the debian computer, when connected to a different 
computer, runs at almost 1000 Mb according to iperf3.


When talking to Debian Buster it runs about 100Mb give or take.

ethtool says its running Speed: 1000Mb/s Duplex: Full

I just noticed this - in the past it ran at 1000Mb/s rates. It may have 
happened when I recently went from squeeze to buster, but I can't be 
sure of that.


Any suggestion on how to proceed.


I have used iptables to go dark to probes of my machine.  I had about 
10,000 entries. Apparently, now that is is deprecated, it's gotten a 
whole lot lest efficient in Buster.  Clearing the iptables made the 
issue go away.  Now to figure out nftables.

Re: Ethernet Performance Problem

[Dan Ritter]

Marc Auslander wrote: 
> I have an Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express
> Fast/Gigabit Ethernet controller (rev 02) Subsystem: Acer Incorporated [ALI]
> RTL810xE PCI Express Fast Ethernet controller
> 
> There is also a Realtek Semiconductor Co., Ltd. Device 8161 (rev 15)
>     Subsystem: Realtek Semiconductor Co., Ltd. Device 8168 100BaseT not
> being used.
> 
> lspci -v says the driver is R8169 for both.
> 
> firmware-realtek is installed and does not appear to provide R8169 but I'm a
> novice about these things.
> 
> The cable leading to the debian computer, when connected to a different
> computer, runs at almost 1000 Mb according to iperf3.
> 
> When talking to Debian Buster it runs about 100Mb give or take.
> 
> ethtool says its running Speed: 1000Mb/s Duplex: Full
> 
> I just noticed this - in the past it ran at 1000Mb/s rates. It may have
> happened when I recently went from squeeze to buster, but I can't be sure of
> that.

Please give us names for the computers in question so we know
where the problem lies. Is it one computer which changes
depending on whether it is booted into buster or bullseye?

iperf3 is a pretty good measure of actual data transfer. If it
works at 1000Mb/s for most things, but drops to 100Mb/s for a
particular one, suspect the particular device, not the general
one.

-dsr-

Re: ethernet cfg via kernel cmdline (was: Buster without systemd?)

[Andrei POPESCU]

On Mi, 25 mar 20, 18:52:25, Andrei POPESCU wrote:
> On Mi, 25 mar 20, 12:21:49, Felix Miata wrote:
> > Andrei POPESCU composed on 2020-03-25 17:45 (UTC+0200):
> > 
> > > $ cat /proc/cmdline
> > > ip=192.168.1.64::192.168.1.1::a64p:eth0:off root=LABEL=a64p rootwait rw 
> > > rootflags=noatime
> > 
> > > The interface is not even up after start and if I bring it up manually 
> > > with 'ip' it doesn't have any IPv4 address configured (only IPv6, which 
> > > is to be expected here).
> > 
> > eth0 isn't kernel native any more, is it?
> 
> It is on this device (PINE A64+).
> 
> > Maybe add net.ifnames=0 and/or change 192.168.1.64 to 192.168.1.64/24?
> 
> According to my understanding of the docs it must be an IP, the netmask 
> (if necessary) can be specified in the 4th field (already tried that).

Apparently I have been using an older version of the docs (kernel is 5.4 
from backports), the current one allows specifying also DNS and NTP 
servers. The updated command line looks like this:

$ cat /proc/cmdline
ip=192.168.1.64::192.168.1.1:255.255.255.0:a64p:eth0:off:192.168.1.1:: 
root=LABEL=a64p rootwait rw rootflags=noatime

It still won't work and there's nothing in the logs, even with 'debug' 
on the kernel command line.

As this was more of a curiosity than necessity I won't be pursuing it 
further, systemd-networkd is for me easier to configure.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: ethernet cfg via kernel cmdline (was: Buster without systemd?)

[Andrei POPESCU]

On Mi, 25 mar 20, 12:21:49, Felix Miata wrote:
> Andrei POPESCU composed on 2020-03-25 17:45 (UTC+0200):
> 
> > $ cat /proc/cmdline
> > ip=192.168.1.64::192.168.1.1::a64p:eth0:off root=LABEL=a64p rootwait rw 
> > rootflags=noatime
> 
> > The interface is not even up after start and if I bring it up manually 
> > with 'ip' it doesn't have any IPv4 address configured (only IPv6, which 
> > is to be expected here).
> 
> eth0 isn't kernel native any more, is it?

It is on this device (PINE A64+).

> Maybe add net.ifnames=0 and/or change 192.168.1.64 to 192.168.1.64/24?

According to my understanding of the docs it must be an IP, the netmask 
(if necessary) can be specified in the 4th field (already tried that).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: ethernet cfg via cmdline (was: Buster without systemd?)

[Felix Miata]

Andrei POPESCU composed on 2020-03-25 17:45 (UTC+0200):

> $ cat /proc/cmdline
> ip=192.168.1.64::192.168.1.1::a64p:eth0:off root=LABEL=a64p rootwait rw 
> rootflags=noatime

> The interface is not even up after start and if I bring it up manually 
> with 'ip' it doesn't have any IPv4 address configured (only IPv6, which 
> is to be expected here).

eth0 isn't kernel native any more, is it? Maybe add net.ifnames=0 and/or change
192.168.1.64 to 192.168.1.64/24?
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: "Ethernet trouble" thread

[David Wright]

On Tue 04 Feb 2020 at 13:20:35 (+0100), Tom H wrote:
> On Mon, Feb 3, 2020 at 2:54 PM Greg Wooledge  wrote:
> > On Sat, Feb 01, 2020 at 05:45:26PM +0100, Tom H wrote:
> >>
> >> You state that it's no longer udev that renames NICs. The following's
> >> from a sid VM using svsinit+sysvrc.
> > [...]
> >> udev is renaming "eth0".
> >>
> >> You can still use "/etc/udev/rules.d/" to rename NICs. Just like with
> >> "/etc/systemd/network/*.link", you gain simple names linked to a NIC's
> >> MAC address, but lose the predictable names' advantage that swapiing
> >> out a NIC preserves its name.
> >
> > Yes, it MIGHT still work. Or it might not. Support for it has
> > been officially removed. Whatever the 70-persistent-net.rules file
> > does on your system is unique to your system.
> >
> > https://wiki.debian.org/NewInBuster#Network_interface_name_migration
> >
> >  "The buster release notes warn that the
> >  /etc/udev/rules.d/70-persistent-net.rules method for assigning
> >  persistent network interface names is no longer supported."
> >
> > https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names
> >
> >  "If your system was upgraded from an earlier release, and still uses
> >  the old-style network interface names that were deprecated with stretch
> >  (such as eth0 or wlan0), you should be aware that the mechanism of
> >  defining their names via /etc/udev/rules.d/70-persistent-net.rules is
> >  officially not supported by udev in buster (while it may still work
> >  in some cases)."
> 
> Thanks. Even though this is the official policy/statement, I don't buy it.
> 
> The problem's that "70-persistent-net.rules" has been used to rename
> NICs within the kernel "ethX" namespace. Until udev upstream declares
> the "SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="mac_address",
> NAME="net0" syntax and mechanism deprecated/obsoleted, I'll assume
> that the Debian release notes and wiki are wrongly melding the fact
> that renaming a NIC to "ethX" is deprecated (and that it might not
> work in the future), with the fact that
> "/etc/udev/rules.d/.rule" can still be used to associate a
> NIC's MAC address with a name.

I assume that's why they wrote "while it may still work in some cases".
The trouble is that so many people seem overly attached to "eth0" as
the name of their interface, even though it's about the worst name
to choose under all the new regimes, and notwithstanding that there's
an almost infinite namespace now available.

But myunderstanding is that if you're going to use udev to change
the interface name, it's important to know that it has completed
before trying to bring up the interface. That can be tricky enough,
but is made doubly difficult when the name is the same at the end
as it was to start with. What do you wait on?

Cheers,
David.

Re: "Ethernet trouble" thread

[Tom H]

On Mon, Feb 3, 2020 at 2:54 PM Greg Wooledge  wrote:
> On Sat, Feb 01, 2020 at 05:45:26PM +0100, Tom H wrote:
>>
>> You state that it's no longer udev that renames NICs. The following's
>> from a sid VM using svsinit+sysvrc.
> [...]
>> udev is renaming "eth0".
>>
>> You can still use "/etc/udev/rules.d/" to rename NICs. Just like with
>> "/etc/systemd/network/*.link", you gain simple names linked to a NIC's
>> MAC address, but lose the predictable names' advantage that swapiing
>> out a NIC preserves its name.
>
> Yes, it MIGHT still work. Or it might not. Support for it has
> been officially removed. Whatever the 70-persistent-net.rules file
> does on your system is unique to your system.
>
> https://wiki.debian.org/NewInBuster#Network_interface_name_migration
>
>  "The buster release notes warn that the
>  /etc/udev/rules.d/70-persistent-net.rules method for assigning
>  persistent network interface names is no longer supported."
>
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names
>
>  "If your system was upgraded from an earlier release, and still uses
>  the old-style network interface names that were deprecated with stretch
>  (such as eth0 or wlan0), you should be aware that the mechanism of
>  defining their names via /etc/udev/rules.d/70-persistent-net.rules is
>  officially not supported by udev in buster (while it may still work
>  in some cases)."

Thanks. Even though this is the official policy/statement, I don't buy it.

The problem's that "70-persistent-net.rules" has been used to rename
NICs within the kernel "ethX" namespace. Until udev upstream declares
the "SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="mac_address",
NAME="net0" syntax and mechanism deprecated/obsoleted, I'll assume
that the Debian release notes and wiki are wrongly melding the fact
that renaming a NIC to "ethX" is deprecated (and that it might not
work in the future), with the fact that
"/etc/udev/rules.d/.rule" can still be used to associate a
NIC's MAC address with a name.

Re: "Ethernet trouble" thread

[Greg Wooledge]

On Sat, Feb 01, 2020 at 05:45:26PM +0100, Tom H wrote:
> You state that it's no longer udev that renames NICs. The following's
> from a sid VM using svsinit+sysvrc.
[...]
> udev is renaming "eth0".
> 
> You can still use "/etc/udev/rules.d/" to rename NICs. Just like with
> "/etc/systemd/network/*.link", you gain simple names linked to a NIC's
> MAC address, but lose the predictable names' advantage that swapiing
> out a NIC preserves its name.

Yes, it MIGHT still work.  Or it might not.  Support for it has
been officially removed.  Whatever the 70-persistent-net.rules file
does on your system is unique to your system.

https://wiki.debian.org/NewInBuster#Network_interface_name_migration

  "The buster release notes warn that the
  /etc/udev/rules.d/70-persistent-net.rules method for assigning
  persistent network interface names is no longer supported."

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

  "If your system was upgraded from an earlier release, and still uses
  the old-style network interface names that were deprecated with stretch
  (such as eth0 or wlan0), you should be aware that the mechanism of
  defining their names via /etc/udev/rules.d/70-persistent-net.rules is
  officially not supported by udev in buster (while it may still work
  in some cases)."

Re: Ethernet trouble

[tomas]

On Sat, Feb 01, 2020 at 09:25:06AM +0200, Andrei POPESCU wrote:
> On Vi, 31 ian 20, 23:42:52, to...@tuxteam.de wrote:
> > 
> > Exactly. I do prefer to be prepared for those corner cases and to
> > learn to deal with them. A 99.8% system is, in this context not
> > superior to a 92% system.
> 
> 89,24% of people quoting a statistic just invented it ;)

Except I wasn't quoting any statistic, but just making it up ;-P

Cheers
-- t


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Andrei POPESCU]

On Vi, 31 ian 20, 15:00:15, Bob Weber wrote:
> On 1/31/20 1:36 PM, Greg Wooledge wrote:
> > On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:
> > > First I created  /etc/systemd/network/10-eth0.link using the MAC address 
> > > and
> > > the name eth0.  If the MAC changes then there are other characteristics to
> > > add to the [Match] section to uniquely define the port (see above link).
> > > 
> > > ---
> > > 
> > > root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
> > > [Match]
> > > MACAddress=52:54:00:ea:e3:53
> > > 
> > > [Link]
> > > Name=eth0
> > > 
> > > Second I linked the default to /dev/null.
> > > 
> > > -
> > > 
> > > link -s /dev/null /etc/systemd/network/99-Default.link
> > I'm almost 100% sure that should be all lower-case, if you expect
> > it to do anything.  The file it's overriding is 99-default.link
> > (lower-case).
> > 
> > > Parsed configuration file /usr/lib/systemd/network/99-default.link
> > > Skipping empty file: /etc/systemd/network/99-Default.link
> > It's going to use the 99-default.link file because you didn't actually
> > override it.  But since you're mapping explicitly on the MAC address of
> > the interface, it doesn't really matter.

Which proves it's not actually needed ;)
 
> Sorry I missed this.  I used the lower case in all the machines on my
> network  ... m ymind thinks in upper/lower case ... too bad systemd can't.

Not sure what you mean here... filenames on *nix are usually lowercase 
(easier to type?).
 
Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ethernet trouble

[Andrei POPESCU]

On Vi, 31 ian 20, 23:42:52, to...@tuxteam.de wrote:
> 
> Exactly. I do prefer to be prepared for those corner cases and to
> learn to deal with them. A 99.8% system is, in this context not
> superior to a 92% system.

89,24% of people quoting a statistic just invented it ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ethernet trouble

[ghe]

On 1/31/20 2:42 PM, Reco wrote:

> As a programmer, you should be familiar with it :)

Very. And misconfigs too...

-- 
Glenn English

Re: Ethernet trouble

[David Wright]

On Fri 31 Jan 2020 at 14:31:56 (-0700), ghe wrote:
> On 1/31/20 11:31 AM, Bob Weber wrote:
> 
> > I just ran a test on a VM that I installed last week so it is pretty
> > much up to date.  I ran the command "ip a" which gave me the current
> > undesirable name "enp1s0" and MAC address.
> 
> Check.
> 
> > First I created  /etc/systemd/network/10-eth0.link using the MAC address
> > and the name eth0.  
> 
> Check. (changed the MAC in your cat of the link file and changed the
> name in the interfaces file)
> 
> Rebooted and:
> 
> Jan 31 12:37:56 sbox systemd[1]: Starting Raise network interfaces...
> Jan 31 12:37:56 sbox ifup[2147]: ifup: unknown interface enp7s0
> Jan 31 12:37:56 sbox systemd[1]: networking.service: Main process
> exited, code=exited, status=1/FAILURE
> Jan 31 12:37:56 sbox systemd[1]: networking.service: Failed with result
> 'exit-code'.
> Jan 31 12:37:56 sbox systemd[1]: Failed to start Raise network interfaces.
> 
> To the best of my knowledge, there is no enp7s0 anymore. Where does:
> 
> [2.445808] e1000e :07:00.0 enp7s0: renamed from eth0
> 
> happen? (dmesg | egrep enp)
> 
> Then there's another line:
> 
> [   12.130525] e1000e :07:00.0 eth0: renamed from enp7s0
> 
> That should have put eth0 back. Current guess is that sometime between
> 2.44 and 12.13, somebody tried to bring up the network interfaces and
> failed.
> 
> So in my current config, eth0 gets changed to enp7s0, ifup is called to
> bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
> interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
> I'm quite used to flaws in software, but lordie...

Assuming you followed Bob Weber, do you still have a symlink, ie,
link -s /dev/null /etc/systemd/network/99-Default.link
in place? What happens if you boot without it?

> And systemd is calling ifup? Which relies on the old interfaces file,
> and systemd relies on additional interface config file(s)?
> 
> After the boot, 'ifup eth0' by hand brings up the interface and ifconfig
> shows it active and with the right name and IP. (So does ip a -- I keep
> using ifconfig because that's what's in my scripts and it's what I'm
> used to.)

I really would avoid changing the interface name back to the one
the kernel chose, or any string that the kernel *might* choose;
ie, be original.

Cheers,
David.

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 12:19:19PM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> >On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:
> >>because they don't need to know that. This is an issue
> >>mostly for people who know a little bit, want to tinker, and become
> >>irrationally angry when they need to learn something new.)
> >
> >This is insulting. I'll try to explain.
> 
> Also, it's not insulting, it's descriptive. I'll explain.
> 
> >Once I understood it, my reaction was "meh".
> 
> And that's fine. In that case, the interface names *are not an
> issue*. They're just something that's there. If you don't like them,
> you change them. No big deal, not an issue, just a thing that can be
> configured to personal taste.

Kept from your previous post:

  "So does dismising everything new as broken because it fixes
   things you don't care about."

And this is exactly what I perceive as highly insulting: I don't
dismiss "everything new as broken...". It's a classical anti-pattern
in this discussion: "You're just resistant to change" =~ "you have
actually no sensible argument". That seems subtle, but it is
pretty condescendent.

That's not better than...

> But some people don't just say "meh",
> they get angry. They insult the software, they insult the
> developers [...]

And I find that unacceptable too. Especially insulting people.
I'm on record for coming forward and speaking up against that,
too.

I'd hope we could just get along and respect each other.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 12:05:34PM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

[...

> >See? I do care.
> 
> In context, Greg talked about the "common case" [...]

Yes, and I do appreciate highly that the "non-common case" is
still possible.

> >Once I understood it, my reaction was "meh".
> 
> You still seem to not fully understand it. (Specifically, the
> difference between "persistent" names and "predictable" names.

Oh, I sure do.
> One
> of the problems systemd was trying to solve was predictability in
> the absence of persistent storage at boot time, e.g., for initial
> installation, or for remote storage.)

I get that. As I already mentioned, I was confronted with that kind
of problem "back then", Debian 3.1 aka Sarge. "Meh" means... "it
doesn't really solve the problem -- so it's not worth the added
complexity" -- as always, to me.

[...]

> So does dismising everything new as broken because it fixes things
> you don't care about.

Keep that for the next post...

> The bottom line is that in most cases the predictable names "just
> work". In some corner cases something goes wrong, just like in some
> corner cases every preceding system went wrong.

Exactly. I do prefer to be prepared for those corner cases and to
learn to deal with them. A 99.8% system is, in this context not
superior to a 92% system.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Michael Stone]

On Sat, Feb 01, 2020 at 12:28:51AM +0300, Reco wrote:

Hi.

On Fri, Jan 31, 2020 at 03:57:44PM -0500, Michael Stone wrote:

FWIW, I would never force something to use "eth0" because it makes it
impossible to see at first glance that all of the default behavior has
been overridden.


If you see a network interface called eth0 in a "modern" Debian it can
mean three things only:

1) Said default behaviour is overridden already.
2) You're using that rare ARM SOC to which x86-centric udev rules just
do not apply, and yes, that particular NIC is not USB-attached.
3) You're in a container, there's no udev here.


Actually, eth0 is the default for most VMs. But the point is that 
"predictable names turned off" would be the likely suspicion, and 
"someone forced a particular interface to be named eth0 based on its mac 
address" would be much more unexpected.



I suspect it would also break horribly if you add another NIC that
initializes before the one you're trying to rename to eth0.


... Unless you do it the right way by using NamePolicy=kernel. Why
bother with renaming eth0 to eth0 if you can avoid renaming at all?


Because that's what someone wanted to do. I'm just saying I wouldn't do 
it.

Re: Ethernet trouble

[Reco]

On Fri, Jan 31, 2020 at 02:31:56PM -0700, ghe wrote:
> So in my current config, eth0 gets changed to enp7s0, ifup is called to
> bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
> interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
> I'm quite used to flaws in software, but lordie...

Using any software (and udev in particular) in a wrong way will give you
wrong results. As a programmer, you should be familiar with it :)

Try this link file:

[Match]
Driver=e1000e
[Link]
MACAddressPolicy=none
NamePolicy=kernel


Long story short, NIC double renaming is wrong, and matching a NIC by
its MAC alone is wrong too.


> And systemd is calling ifup? Which relies on the old interfaces file,
> and systemd relies on additional interface config file(s)?

The software merely does what it's told to do.

Reco

Re: Ethernet trouble

[ghe]

On 1/31/20 11:31 AM, Bob Weber wrote:

> I just ran a test on a VM that I installed last week so it is pretty
> much up to date.  I ran the command "ip a" which gave me the current
> undesirable name "enp1s0" and MAC address.

Check.

> First I created  /etc/systemd/network/10-eth0.link using the MAC address
> and the name eth0.  

Check. (changed the MAC in your cat of the link file and changed the
name in the interfaces file)

Rebooted and:

Jan 31 12:37:56 sbox systemd[1]: Starting Raise network interfaces...
Jan 31 12:37:56 sbox ifup[2147]: ifup: unknown interface enp7s0
Jan 31 12:37:56 sbox systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
Jan 31 12:37:56 sbox systemd[1]: networking.service: Failed with result
'exit-code'.
Jan 31 12:37:56 sbox systemd[1]: Failed to start Raise network interfaces.

To the best of my knowledge, there is no enp7s0 anymore. Where does:

[2.445808] e1000e :07:00.0 enp7s0: renamed from eth0

happen? (dmesg | egrep enp)

Then there's another line:

[   12.130525] e1000e :07:00.0 eth0: renamed from enp7s0

That should have put eth0 back. Current guess is that sometime between
2.44 and 12.13, somebody tried to bring up the network interfaces and
failed.

So in my current config, eth0 gets changed to enp7s0, ifup is called to
bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
I'm quite used to flaws in software, but lordie...

And systemd is calling ifup? Which relies on the old interfaces file,
and systemd relies on additional interface config file(s)?

After the boot, 'ifup eth0' by hand brings up the interface and ifconfig
shows it active and with the right name and IP. (So does ip a -- I keep
using ifconfig because that's what's in my scripts and it's what I'm
used to.)

-- 
Glenn English

Re: Ethernet trouble

[Reco]

Hi.

On Fri, Jan 31, 2020 at 03:57:44PM -0500, Michael Stone wrote:
> FWIW, I would never force something to use "eth0" because it makes it
> impossible to see at first glance that all of the default behavior has
> been overridden.

If you see a network interface called eth0 in a "modern" Debian it can
mean three things only:

1) Said default behaviour is overridden already.
2) You're using that rare ARM SOC to which x86-centric udev rules just
do not apply, and yes, that particular NIC is not USB-attached.
3) You're in a container, there's no udev here.


> I suspect it would also break horribly if you add another NIC that
> initializes before the one you're trying to rename to eth0.

... Unless you do it the right way by using NamePolicy=kernel. Why
bother with renaming eth0 to eth0 if you can avoid renaming at all?

But the real fun with binding an interface name to a MAC starts once one
discovers 802.1q and tries to use it :) 

Reco

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 03:29:44PM -0500, Bob Weber wrote:

On 1/31/20 1:41 PM, Michael Stone wrote:
   You went through more effort than you needed to. You can turn off
   predictable names by simply booting with net.ifnames=0 on the kernel
   command line (you can make that permanent by editing GRUB_CMDLINE_LINUX= in
   /etc/default/grub and running update-grub).


The net.ifnames=0 used to work on my 2 port machine but quit about a year ago. 
Messed up my firewall rules.  Not very nice to have the internet side connected
to LAN port!   That's when I went through the pain of understanding the systemd
way!


Yup, there's definitely a problem that needed to be solved. But when 
people keep asking for things to go back to the way they used to be 
because the new way is overly complicated, that's how to do it quickly 
and simply.


There's also no need to disable 99-default.link if you add a new .link 
with new rules that override the defaults.


FWIW, I would never force something to use "eth0" because it makes it 
impossible to see at first glance that all of the default behavior has 
been overridden. I suspect it would also break horribly if you add 
another NIC that initializes before the one you're trying to rename to 
eth0. Instead I'd give it a name like "internal0" or somesuch, so it's 
clear that there's manual naming, and as a bonus it's a name that 
includes a description of its intended use.

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 1:41 PM, Michael Stone wrote:

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to add
to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


You went through more effort than you needed to. You can turn off predictable 
names by simply booting with net.ifnames=0 on the kernel command line (you can 
make that permanent by editing GRUB_CMDLINE_LINUX= in /etc/default/grub and 
running update-grub).


The net.ifnames=0 used to work on my 2 port machine but quit about a year ago.  
Messed up my firewall rules.  Not very nice to have the internet side connected 
to LAN port!   That's when I went through the pain of understanding the systemd way!


--


*...Bob*

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 1:36 PM, Greg Wooledge wrote:

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created  /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to
add to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


Second I linked the default to /dev/null.

-

link -s /dev/null /etc/systemd/network/99-Default.link

I'm almost 100% sure that should be all lower-case, if you expect
it to do anything.  The file it's overriding is 99-default.link
(lower-case).


Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link

It's going to use the 99-default.link file because you didn't actually
override it.  But since you're mapping explicitly on the MAC address of
the interface, it doesn't really matter.

Sorry I missed this.  I used the lower case in all the machines on my network  
... m ymind thinks in upper/lower case ... too bad systemd can't.  I went back 
and renamed the file to lower case and got this output from the udevadm command.


-

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/eth0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Skipping overridden file '/usr/lib/systemd/network/99-default.link'.
Skipping empty file: /etc/systemd/network/99-default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
ID_NET_DRIVER=virtio_net
eth0: Config file /etc/systemd/network/10-eth0.link is applied
ethtool: autonegotiation is unset or enabled, the speed and duplex are not 
writable.
eth0: Device has name_assign_type=4
Using default interface naming scheme 'v243'.
eth0: Policies didn't yield a name, using specified Name=eth0.
ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link
ID_NET_NAME=eth0
Unload module index
Unloaded link configuration context.


New lines:

Skipping overridden file '/usr/lib/systemd/network/99-default.link'

Skipping empty file: /etc/systemd/network/99-default.link


That's more like it.


--


*...Bob*

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created  /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to add
to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


You went through more effort than you needed to. You can turn off 
predictable names by simply booting with net.ifnames=0 on the kernel 
command line (you can make that permanent by editing GRUB_CMDLINE_LINUX= 
in /etc/default/grub and running update-grub).

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:
> First I created  /etc/systemd/network/10-eth0.link using the MAC address and
> the name eth0.  If the MAC changes then there are other characteristics to
> add to the [Match] section to uniquely define the port (see above link).
> 
> ---
> 
> root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
> [Match]
> MACAddress=52:54:00:ea:e3:53
> 
> [Link]
> Name=eth0
> 
> 
> Second I linked the default to /dev/null.
> 
> -
> 
> link -s /dev/null /etc/systemd/network/99-Default.link

I'm almost 100% sure that should be all lower-case, if you expect
it to do anything.  The file it's overriding is 99-default.link
(lower-case).

> Parsed configuration file /usr/lib/systemd/network/99-default.link
> Skipping empty file: /etc/systemd/network/99-Default.link

It's going to use the 99-default.link file because you didn't actually
override it.  But since you're mapping explicitly on the MAC address of
the interface, it doesn't really matter.

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 2:05 AM, ghe wrote:



On Jan 30, 2020, at 04:48 PM, Bob Weber  wrote:
"Example 3. Debugging NamePolicy= assignments" near the bottom of the page at
"https://www.freedesktop.org/software/systemd/man/systemd.link.html";

Yeah. That's one I looked at. The one with the table of the Ethernet speeds and 
duplexity. And the list and descriptions of data that're sometimes needed in 
the file.

I'll look at this again tomorrow, Bob, but I'm really not impressed with the way systemd 
is setting up the Ethernet interfaces. Like I said before, "Counting Ethernet 
interfaces isn't rocket science." But it can be made so if you make things complex 
and spread the config over several dirs and several files, some of which are explained in 
the dox but turn out not to exist on my Buster disk.

Somehow, back in the eth days, the data in Debian's /etc/network/interfaces 
file was enough to get networking going. Then, on an Ethernet network, the 
Ethernet chips pretty well figured out the best speed and duplex all by 
themselves as soon as they connected to something.


This nameing configuration has worked on 5 Debian systems all running updated 
testing.

And counting interfaces has worked for me for a couple decades, on many systems 
and several OSs. But I'll find your earlier email and try systemd one more 
time. It'd be nice for the interface names to be, as systemd calls it, 
'consistent.'

And, FWIF, I appreciate your help and advice...

I just ran a test on a VM that I installed last week so it is pretty much up to 
date.  I ran the command "ip a" which gave me the current undesirable name 
"enp1s0" and MAC address.


First I created  /etc/systemd/network/10-eth0.link using the MAC address and the 
name eth0.  If the MAC changes then there are other characteristics to add to 
the [Match] section to uniquely define the port (see above link).


---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


Second I linked the default to /dev/null.

-

link -s /dev/null /etc/systemd/network/99-Default.link


Next I ran the test command from Example 3 at the above link to see what udevadm 
thinks.


-

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/enp1s0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
ID_NET_DRIVER=virtio_net
enp1s0: Config file /etc/systemd/network/10-eth0.link is applied
ethtool: autonegotiation is unset or enabled, the speed and duplex are not 
writable.
enp1s0: Device has name_assign_type=4
Using default interface naming scheme 'v243'.
enp1s0: Policies didn't yield a name, using specified Name=eth0.
ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link
ID_NET_NAME=eth0
Unload module index
Unloaded link configuration context.


Notice the ID_NET_NAME=eth0 is what I wanted.  Also option to the udevadm 
command /sys/class/net/enp1s0 contains the current undesirable name of the 
interface (enp1s0).


Now I rebooted the VM.  I ran the "ip a" command again.

-
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000

    link/ether 52:54:00:ea:e3:53 brd ff:ff:ff:ff:ff:ff
    inet 192.168.240.228/24 brd 192.168.240.255 scope global dynamic 
noprefixroute eth0

   valid_lft 3550sec preferred_lft 3550sec
    inet6 fe80::5054:ff:feea:e353/64 scope link noprefixroute
   valid_lft forever preferred_lft forever


Just what I wanted.


Now running the udevadm command from before with the old name fails:

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/enp1s0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link
Parsed configuration file /usr/lib/systemd/network

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:

because they don't need to know that. This is an issue
mostly for people who know a little bit, want to tinker, and become
irrationally angry when they need to learn something new.)


This is insulting. I'll try to explain.


Also, it's not insulting, it's descriptive. I'll explain.


Once I understood it, my reaction was "meh".


And that's fine. In that case, the interface names *are not an issue*. 
They're just something that's there. If you don't like them, you change 
them. No big deal, not an issue, just a thing that can be configured to 
personal taste. But some people don't just say "meh", they get angry. 
They insult the software, they insult the developers, they rant about 
how all the decisions were stupid. They may explain that there's a 
simple solution that should have been implemented if only the developers 
were smarter or not part of a *conspiracy* to make horrible software. 
Now, for no good reason, a trivial matter like an interface name has 
become "an issue". If that's not you--great!--there's no need to be 
insulted because it must not have been about you.


Even at their worst the debian lists are actually pretty good. But you 
might be surprised at the level of vitriol that developers can get over 
what are really unimportant matters in the grand scheme of things. If 
you aren't the kind to get angry about interface names you might be 
surprised that developers actually get death threats over such trivial 
nonsense. Anyway, that's how I define "an issue" vs "a configurable 
default".

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:

On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:
>The primary drawback of this method is that in the common case of a
>single-user home desktop system with a single NIC, the name "eth0" is
>expected to Just Work for whatever NIC happens to be in the system at
>the time.

It's also fundamentally unpredictable for the same reason that you
can't just rely on the kernel name in the first place [...]



to work around. (And really, in the single user/single nic desktop
case, the user doesn't even *care* if the installer configures eth0
or foo11


See? I do care.


In context, Greg talked about the "common case". In the common case, for 
the purpose of actually designing an OS, the user doesn't care. In your 
particular case, for aesthetic reasons or whatever, you care. That's not 
the common case, that's the you case. The common case is that the 
installer configures the network and then it never gets touched again. 
The common case is that the user probably doesn't even know what the 
interface name is, or thinks it's something like "my wireless card", 
because in the common case the user shouldn't have to know.



When the persistent schema came up, I took interest in it, since
I had hit the problem quite a few times and well, if someone
solved it, I'd like to know.

Once I understood it, my reaction was "meh".


You still seem to not fully understand it. (Specifically, the difference 
between "persistent" names and "predictable" names. One of the problems 
systemd was trying to solve was predictability in the absence of 
persistent storage at boot time, e.g., for initial installation, or for 
remote storage.)



but for me and my installations, it wasn't worth the more
complicated names. I still do "sudo ifup eth0" and don't really
want to do "sudo ifup &$#*@%#". I had seen those things before
(was it Solaris) and -- oh well.


Solaris did it for reasons. Eventually linux tried to fill roles which 
required the same sort of solution for the same sort of reasons. "I 
don't want to" isn't a rational argument that anyone can address. If you 
just don't want to do it, then ok, but why share that with everyone?



Now dismissing folks who don't share your opinion on some
shiny new thing as "just resistant to change" or "tinkerers"
is a horrible antipattern. Please don't do that. It leads
to ugly discussions and hurt feelings. Been there, done that.


So does dismising everything new as broken because it fixes things you 
don't care about.


The bottom line is that in most cases the predictable names "just work". 
In some corner cases something goes wrong, just like in some corner 
cases every preceding system went wrong. For the predictable scheme the 
most likely thing to go wrong is that you've got a system whose firmware 
is broken. Unfortunately that's really hard to fix. On the bright side 
there are workarounds and alternatives for those who need them or for 
particular use cases which aren't well suited to the defaults.


If you have some unusual requirement where you want the name to be one 
specific thing and you'll be unhappy if it's anything else, well, that 
can also be achieved! But it's certainly not something that needs to 
drive the common case defaults.

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 11:05:32AM -0500, Greg Wooledge wrote:
> On Fri, Jan 31, 2020 at 04:53:28PM +0100, to...@tuxteam.de wrote:
> > I see, thanks. I must admit that I don't know very much about how
> > systemd names network interfaces. In practice, what I get to see
> > roughly follows the known conventions (bus number, etc).
> > 
> > Udev is/was just a mechanism to implement those conventions. Or
> > different ones.
> 
> > Is it using something else than udev, these days?
> 
> Yes.
> 
> https://wiki.debian.org/NetworkInterfaceNames
> http://manpages.debian.org/systemd.link

Thanks.

Now I understand the confusion. What's being called "udev" here
was just that one MAC-based "70-persistent-rules" thingy. Nowadays
(Buster, no systemd but udev) Debian ships udev rules implementing
the "predictable" scheme (as it's called in the above wiki). Cf.
75-net-description.rules, for example.

And systemd relies on udev to actually implement its mechanism,
as can be guessed from the man page you link to above.

So -- strictly speaking, "udev" is just the mechanism, the
policy is defined by sets of udev rules (possibly disguised
as .link files whenever systemd is in control) -- and loosely
speaking, whenever folks say here "udev interface names", they
are talking about the now defunct MAC based [1] interface
names once-upon-a-time implemented by a sadly notorious
70-persistent-net.rules or something (the exact spelling
escapes me at the moment).

On my original post: I was talking about those (newer)
"predictable" interface names. I've no use for them.
Someone else might. YMMV. Etc.

Cheers

[1] This one bit me once in the ass. Remember that thing
   where a virtual machine used to roll dice on the mac
   address of its virtual interface?

-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 04:53:28PM +0100, to...@tuxteam.de wrote:
> I see, thanks. I must admit that I don't know very much about how
> systemd names network interfaces. In practice, what I get to see
> roughly follows the known conventions (bus number, etc).
> 
> Udev is/was just a mechanism to implement those conventions. Or
> different ones.

> Is it using something else than udev, these days?

Yes.

https://wiki.debian.org/NetworkInterfaceNames
http://manpages.debian.org/systemd.link

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 10:38:20AM -0500, Greg Wooledge wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> > When the persistent schema came up, I took interest in it, [...]
> 
> > but for me and my installations, it wasn't worth the more
> > complicated names. I still do "sudo ifup eth0" and don't really
> > want to do "sudo ifup &$#*@%#".
> 
> You are NOT talking about the udev persistent naming scheme.  You
> are talking about the systemd predictable naming scheme.
> 
> VERY different creatures.

I see, thanks. I must admit that I don't know very much about how
systemd names network interfaces. In practice, what I get to see
roughly follows the known conventions (bus number, etc).

Udev is/was just a mechanism to implement those conventions. Or
different ones.

> Under the systemd (current) scheme, you can choose whatever name
> you like for the interface.  If you want to call it "red", you can
> call it "red", and then plug a red cable in it.

Is it using something else than udev, these days?

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> When the persistent schema came up, I took interest in it, [...]

> but for me and my installations, it wasn't worth the more
> complicated names. I still do "sudo ifup eth0" and don't really
> want to do "sudo ifup &$#*@%#".

You are NOT talking about the udev persistent naming scheme.  You
are talking about the systemd predictable naming scheme.

VERY different creatures.

Under the systemd (current) scheme, you can choose whatever name
you like for the interface.  If you want to call it "red", you can
call it "red", and then plug a red cable in it.

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:
> >The primary drawback of this method is that in the common case of a
> >single-user home desktop system with a single NIC, the name "eth0" is
> >expected to Just Work for whatever NIC happens to be in the system at
> >the time.
> 
> It's also fundamentally unpredictable for the same reason that you
> can't just rely on the kernel name in the first place [...]

> to work around. (And really, in the single user/single nic desktop
> case, the user doesn't even *care* if the installer configures eth0
> or foo11

See? I do care.

> because they don't need to know that. This is an issue
> mostly for people who know a little bit, want to tinker, and become
> irrationally angry when they need to learn something new.)

This is insulting. I'll try to explain.

I, for one, knew about the inherent problem with the interface
names.

When the persistent schema came up, I took interest in it, since
I had hit the problem quite a few times and well, if someone
solved it, I'd like to know.

Once I understood it, my reaction was "meh".

Sure some progress for totally naive users (which were starting
to use Linux distros more and more, which is a Good Thing), so
it made (a bit of [1]) sense to

 (a) have it as default schema and
 (b) for us, the somewhat experienced folks to understand it,
 to be able to help newbies... 

but for me and my installations, it wasn't worth the more
complicated names. I still do "sudo ifup eth0" and don't really
want to do "sudo ifup &$#*@%#". I had seen those things before
(was it Solaris) and -- oh well.

Now dismissing folks who don't share your opinion on some
shiny new thing as "just resistant to change" or "tinkerers"
is a horrible antipattern. Please don't do that. It leads
to ugly discussions and hurt feelings. Been there, done that.

Cheers

[1] afaik the jury is still out on that, but let's concede
   it, for the sake of argument.

-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:

The primary drawback of this method is that in the common case of a
single-user home desktop system with a single NIC, the name "eth0" is
expected to Just Work for whatever NIC happens to be in the system at
the time.


It's also fundamentally unpredictable for the same reason that you can't 
just rely on the kernel name in the first place--even on the first 
install, if you have multiple NICs they will sometimes come up in 
a different order. For the single user/single nic desktop this isn't an 
issue, but if you're trying to on a large number of machines, and plug 
the LAN into (for example) the first on-board interface, it is a real 
PITA if sometime's that is eth0 and sometimes it's eth3 (or whatever) 
and that's a *much* harder problem to work around. (And really, in the 
single user/single nic desktop case, the user doesn't even *care* if the 
installer configures eth0 or foo11 because they don't need to know that. 
This is an issue mostly for people who know a little bit, want to 
tinker, and become irrationally angry when they need to learn something 
new.)

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 09:52:29AM -0500, rhkra...@gmail.com wrote:
> On Friday, January 31, 2020 09:39:37 AM Dan Ritter wrote:
> > All of this would be, I think, 99% better than what we have now.
> 
> +1 -- sounds good!

Yeah, but it isn't. As Michael points out, most solutions proposed
here have been tried and none is "always good". Mac addresses, for
example, aren't as "fixed" or "stable" as one would make them out
(and actually in some case they are forcibly changed, for privacy
reasons [1]).

Whoever has been admining or near-admining for a while (I've, for
nearly as long as Unix exists) can share a bunch of stories.

Dan, RH -- believe me, you're running in circles :-)

The best one can do is to offer the necessary building blocks to
fix the problem du jour (udev does, for the moment, at least).

Persistent device names, as we know them now, are just the last
(failed) attempt. Some folks like them, some dislike them, I'm
happy & thankful that there's a way to choose with a reasonable
amount of effort.

Cheers

[1] Mobile devices and their WiFi mac address.
-- t


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 09:39:37AM -0500, Dan Ritter wrote:
> Maybe we should ask the OS to actually help, instead of
> "helping" us.
> 
> For example, the OS knows when it is being installed. At install
> time, it could enumerate NICs and assign them permanent names
> based on the MAC addresses: eth0, eth1...
> 
> At any subsequent boot, the OS could then continue to assign the
> same names. If a device appears to be missing, the name is
> skipped. eth3 doesn't become eth2, eth2 just goes missing for
> that boot. This is immensely useful in discovering when a NIC
> has suffered hardware damage or is otherwise not present.

This is basically how the udev persistent-naming scheme worked.
Support for it was officially discontinued in buster.

The primary drawback of this method is that in the common case of a
single-user home desktop system with a single NIC, the name "eth0" is
expected to Just Work for whatever NIC happens to be in the system at
the time.

If the NIC failed and was replaced, the replacement NIC would become eth1,
rather than eth0, and this confused some people.

Prior to the udev thing, when the kernel dynamically assigned names
to interfaces in whatever order they happened to pop up during boot,
replacing a single NIC with a different single NIC would have kept
the name "eth0" the whole time.  This is what many people were expecting,
and what the udev persistent-naming scheme took away.

Now, this is all historic.  Both the pre-udev "whatever you have
gets called whatever I want to call it" scheme, and the udev
persistent-naming scheme, are unsupported.  If you choose to use
them, they may work for you, or they may not.

The currently supported approach is systemd.link(5).  If you want to
assign a name to an interface, you create a file that sets up the
mapping as you wish it to be made.  Usually from the MAC address.

This puts a slightly higher burden of knowledge on the sysadmin, but
I really don't see a better choice.  Anything that tries to magically
do the Right Thing is going to fail in at least one common scenario.
Editing a systemd.link file isn't any harder than editing the udev
persistent rules file, and if you replace a NIC and want to keep the
same name, you'll have to edit one of these files anyway.

Re: Ethernet trouble

[rhkramer]

On Friday, January 31, 2020 09:39:37 AM Dan Ritter wrote:
> All of this would be, I think, 99% better than what we have now.

+1 -- sounds good!

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 09:39:37AM -0500, Dan Ritter wrote:

Michael Stone wrote:

As a programmer you should be concerned with making sure that the packets go
in and out of the correct physical hardware. If the name doesn't relate to
the physical harder that's a harder problem to solve. You (and everyone
else) could reimplement that in software at a higher level, or accept that
this is something the OS should help with.


Maybe we should ask the OS to actually help, instead of
"helping" us.

For example, the OS knows when it is being installed. At install
time, it could enumerate NICs and assign them permanent names
based on the MAC addresses: eth0, eth1...


It's been tried, and has other problems. (As you trimmed from the 
original email.) 


When an unrecognized device is plugged in, whether during runtime or at
boot time, it gets the next sequential permanent name.


Which also has its own problems. (Is it "eth0" the old kernel version or 
"eth0" the renamed version? Don't worry, it's really easy to explain the 
difference to someone having problems on a mailing list.)



All of this would be, I think, 99% better than what we have now.


And yet, it wasn't. :) Maybe with the stuff you described that doesn't 
exist that you think should get written (by someone) it would be better, 
but we don't know since it hasn't been written. Even if it was written 
it wouldn't be reliably available for several kernel & OS releases 
because compatibility and upgrades. 

Really, if there was a simple solution that worked better than the 
existing solution for all cases, it would get used. Since it isn't, 
there may be reasons...

Re: Ethernet trouble

[Dan Ritter]

Michael Stone wrote: 
> As a programmer you should be concerned with making sure that the packets go
> in and out of the correct physical hardware. If the name doesn't relate to
> the physical harder that's a harder problem to solve. You (and everyone
> else) could reimplement that in software at a higher level, or accept that
> this is something the OS should help with.

Maybe we should ask the OS to actually help, instead of
"helping" us.

For example, the OS knows when it is being installed. At install
time, it could enumerate NICs and assign them permanent names
based on the MAC addresses: eth0, eth1...

At any subsequent boot, the OS could then continue to assign the
same names. If a device appears to be missing, the name is
skipped. eth3 doesn't become eth2, eth2 just goes missing for
that boot. This is immensely useful in discovering when a NIC
has suffered hardware damage or is otherwise not present.

When an unrecognized device is plugged in, whether during runtime or at
boot time, it gets the next sequential permanent name.

Finally, a simple lookup table of MAC to name should be exposed by the
kernel, and saved/loaded in the same way as firewall rules, so that people
who want to change interface name assignments can do so cleanly. The
one caveat is that a process which wants to change the MAC address of
the NIC will have to signal that specifically, rather than just
update the table. When the OS changes the MAC address, e.g. WiFi
MAC randomization, it just updates the table because it knows
what it is doing.

All of this would be, I think, 99% better than what we have now.

-dsr-

Re: Ethernet trouble

[David Wright]

On Thu 30 Jan 2020 at 11:58:47 (-0700), ghe wrote:
> On 1/29/20 7:06 PM, David Wright wrote:
> 
> > These boards, do their PCI addresses have the save bus number but
> > different slot/device numbers? dmesg or kern.log will give you
> > those: they look like NN:DD.F optionally preceded by :, where
> >  is the domain (typically ), NN is the bus, DD the device
> > of slot, F the function(s) provided by that card, eg
> > pci :00:0e.0: [10ec:8139] type 00 class 0x02
> 
> Well, I don't in any way consider myself a hardware guy, but in Java,
> Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
> same thing every time I type it.

?

> I looked at dmesg a bit. I greped it for 'enp' and there was a funny
> joke in the first 2 lines (of the grep output):
> 
> [2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
> [2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

And did you happen upon the boards' addresses?

> So something took the rational Ethernet interface names and,
> intentionally I assume, broke hundreds of lines of code.
> 
> Once I was installing a computer that had a single Ethernet port
> soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
> put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
> mobo, 1 was the card. And it was eth1 no matter which slot it was in.

Yes, but the kernel's choice of eth0 and eth1 may not necessarily be
fixed. My experience with linux in the past was that, with two NICs,
there was no way of ensuring the order in which they were assigned.
With something like a firewall, you could end up with your WAN and LAN
interfaces reversed.

> Or if I put in a sound-card.
> 
> They were named by function, not by bus and slot. As a programmer, I'm
> much more interested in *what* they are, not *where* they are. I
> especially don't need some broken piece of software to rename them.

And take disks. With the proliferation of buses in modern PCs, there's
no guarantee that the machine will boot up and have the system disk
on the usual /dev/sda. My PC in the attic appear to enumerate the legacy
PATA before the SATAs. This laptop enumerates USB sticks in an order
that appears stable, but I have no idea whether it's really a race.

I have read of a case analogous to yours, where booting up a laptop
with a USB stick inserted would demote the internal disk to /dev/sdb.
(I think the internal disk was an SSD.)

> I know I can put them back to the 'inconsistent' names in Grub, and I'll
> be doing that -- and editing the shell scripts.
> 
> > AIUI it's nothing to do with the OS as these decisions are made by
> > the firmware on the mobo. Juggling cards in a mobo can even outwit
> > the BIOS so that the POST won't succeed: I've had mobos where I've
> > had to empty the box, power-up and save the settings, add one card
> > and repeat, add the next and so on, all to get a box with the cards
> > I wanted, located where I wanted them.
> 
> With all the 'puters I've dealt with, I've never seen anything like
> that. If I got one that did that, I'd have sent it back to Amazon and
> bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
> competently written and tested BIOS.

Said attic PC is a Dell Optiplex.

> Besides, we've got UDEV. It allegedly looks at hardware and makes it
> make sense. To do that, it must, I suspect, ignore what the BIOS says
> and scan the bus(es) itself. If it does that, my Ethernet ports would
> have had the same labels, unless somebody renamed them. Would be the
> same too, if they'd just been left alone.

In your case, the sensible thing might be to use the MAC addresses,
assuming you don't change them. These Super Micro thingies could have
an IPMI built in, allowing you to change MACs to your heart's content.

> I'm not looking forward to systemd.emacs.

I got the impression there was an agenda polarising the debate. BTW,
you know who started all this renaming NICs business? Your friends at Dell.

Cheers,
David.

Re: Ethernet trouble

[Michael Stone]

On Thu, Jan 30, 2020 at 11:58:47AM -0700, ghe wrote:

I looked at dmesg a bit. I greped it for 'enp' and there was a funny
joke in the first 2 lines (of the grep output):

[2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
[2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

So something took the rational Ethernet interface names and,
intentionally I assume, broke hundreds of lines of code.


Because those "rational" ethernet names can be very unstable *in 
practice* on modern systems. (Devices are initialized in parallel, so 
when there are multiple interfaces present they may not always come up 
in the same order.)



Once I was installing a computer that had a single Ethernet port
soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
mobo, 1 was the card. And it was eth1 no matter which slot it was in.


See above. This worked reliably on old kernels, especially static 
kernels (pre-modules) with ISA/PCI devices and works much less reliably 
in a world of hotplug PCI, USB, and modular configurations with parallel 
intialization. There was a series of hacks on top of the "rational 
names" which mapped the name to a MAC address. In practice that *also* 
renamed the ethernet devices, except in a less transparent fashion, and 
caused its own headaches when NICs were replaced.



They were named by function, not by bus and slot. As a programmer, I'm
much more interested in *what* they are, not *where* they are.


As a programmer you should be concerned with making sure that the 
packets go in and out of the correct physical hardware. If the name 
doesn't relate to the physical harder that's a harder problem to solve. 
You (and everyone else) could reimplement that in software at a higher 
level, or accept that this is something the OS should help with.



AIUI it's nothing to do with the OS as these decisions are made by
the firmware on the mobo. Juggling cards in a mobo can even outwit
the BIOS so that the POST won't succeed: I've had mobos where I've
had to empty the box, power-up and save the settings, add one card
and repeat, add the next and so on, all to get a box with the cards
I wanted, located where I wanted them.


With all the 'puters 


really?


I've dealt with, I've never seen anything like
that. If I got one that did that, I'd have sent it back to Amazon and
bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
competently written and tested BIOS.


Again, many desktops have lousy firmware. Yours seems to be one of them. :-)


Besides, we've got UDEV. It allegedly looks at hardware and makes it
make sense. To do that, it must, I suspect, ignore what the BIOS says
and scan the bus(es) itself.


udev can't map a logical bus to a physical slot, only the firmware knows 
how to do that (and only if it's been properly configured by the 
vendor). udev can't even tell things like how many buses there are in 
the system, because the firmware may turn them on and off or create 
virtual buses and change those things between boots. As with most 
things, the systemd folks didn't just implement a solution looking for a 
problem, they tried to solve an actual problem that's a lot harder than 
people throwing rocks from the sidelines tend to understand.

Re: Ethernet trouble

[Stefan Monnier]

> And counting interfaces has worked for me for a couple decades, on many
> systems and several OSs.

FWIW, this whole mess exists for the simple reason that there isn't any
kind of "aliasing" available for network interfaces.  When stable names
were added to block devices, it didn't break anything because it was
introduced simply by adding the /dev/disk/by-*/* symlinks.

I wish stable interface names had been added via a similar mechanism
(which of course would have had to be added beforehand).


Stefan

Re: Ethernet trouble

[ghe]

> On Jan 30, 2020, at 04:48 PM, Bob Weber  wrote:

> "Example 3. Debugging NamePolicy= assignments" near the bottom of the page at
> "https://www.freedesktop.org/software/systemd/man/systemd.link.html";

Yeah. That's one I looked at. The one with the table of the Ethernet speeds and 
duplexity. And the list and descriptions of data that're sometimes needed in 
the file.

I'll look at this again tomorrow, Bob, but I'm really not impressed with the 
way systemd is setting up the Ethernet interfaces. Like I said before, 
"Counting Ethernet interfaces isn't rocket science." But it can be made so if 
you make things complex and spread the config over several dirs and several 
files, some of which are explained in the dox but turn out not to exist on my 
Buster disk. 

Somehow, back in the eth days, the data in Debian's /etc/network/interfaces 
file was enough to get networking going. Then, on an Ethernet network, the 
Ethernet chips pretty well figured out the best speed and duplex all by 
themselves as soon as they connected to something. 

> This nameing configuration has worked on 5 Debian systems all running updated 
> testing.

And counting interfaces has worked for me for a couple decades, on many systems 
and several OSs. But I'll find your earlier email and try systemd one more 
time. It'd be nice for the interface names to be, as systemd calls it, 
'consistent.'

And, FWIF, I appreciate your help and advice...

-- 
Glenn English

Re: Ethernet trouble

[Bob Weber]

On 1/30/20 6:17 PM, ghe wrote:

On 1/30/20 1:42 PM, Bob Weber wrote:


That's why I recommended you look into systemd link files.

I looked that up on the 'Net, and it seems pretty reasonable. I looked
around a bit and was told to edit

/usr/lib/systemd/network/99-default.link

(MAC addresses are back to hardware again, but easier to handle -- at
least they're the same whenever you look at them. And Debian puts config
files in /etc. Used to, anyway)

There's a line in 99-default.link about =persistent. The web
says that if I change that to 'none' I'll get the old names back.

I did, and I didn't.


Systemd has
the undesired effect of renaming interfaces.  You need to use the MAC
address to indicate which port should be eth0 , etc.

It looks like it'll take a lot more than changing a value in a config
file to have happen what I expect. I think I'll just leave things alone
for the time being. Now I know to expect systemd to break things, and
now I know to write around it. I was completely at a loss when those
numbers just changed for no apparent reason.

Counting Ethernet interfaces isn't rocket science.

Again, thanks list.

That's why I showed in theprevious email a file for eth0 and eth1 matching their 
MAC address.   The "99-default.link" file is taken out of the works by 
(symbolic) linking it to /dev/null.  This means whatever was in that file 
messing up the port names is gone.  The kernel command line option 
"net.ifnames=0" may or may not be needed ... try without at first.


After a reboot the names should be what you put in the  [Link] section of the 
files " /etc/systemd/network/10-eth0.link" and 
"/etc/systemd/network/20-eth0.link" assuming you put in the correct MAC address 
in the [Match] section.


If the names are are still not correct then there are some examples of a udevadm 
command like in the "Example 3. Debugging NamePolicy= assignments" near the 
bottom of the page at 
"https://www.freedesktop.org/software/systemd/man/systemd.link.html 
"


This nameing configuration has worked on 5 Debian systems all running updated 
testing.


Note: the /sys/class/net/hub0 mentioned in Example 3 should be replaced by the 
current port name found in /sys/class/net directory.


--


*...Bob*

Re: Ethernet trouble

[ghe]

On 1/30/20 1:42 PM, Bob Weber wrote:

> That's why I recommended you look into systemd link files. 

I looked that up on the 'Net, and it seems pretty reasonable. I looked
around a bit and was told to edit

/usr/lib/systemd/network/99-default.link

(MAC addresses are back to hardware again, but easier to handle -- at
least they're the same whenever you look at them. And Debian puts config
files in /etc. Used to, anyway)

There's a line in 99-default.link about =persistent. The web
says that if I change that to 'none' I'll get the old names back.

I did, and I didn't.

> Systemd has
> the undesired effect of renaming interfaces.  You need to use the MAC
> address to indicate which port should be eth0 , etc.  

It looks like it'll take a lot more than changing a value in a config
file to have happen what I expect. I think I'll just leave things alone
for the time being. Now I know to expect systemd to break things, and
now I know to write around it. I was completely at a loss when those
numbers just changed for no apparent reason.

Counting Ethernet interfaces isn't rocket science.

Again, thanks list.

-- 
Glenn English

Re: Ethernet trouble

[Stefan Monnier]

> For the rest of us, who didn't drink the OO kool-aid, overloading is
> just a nightmare.

Even outside of OO, most languages overload `+` to mean "integer
addition" when applied to integers and "double-precision float addition"
when applied to double-precision floats.

IOW while I agree that overloading is a nightmare, the absence of
overloading also tends to be a nightmare ;-)


Stefan "still not quite sure what `+` should do when applied to
Ethernet and even less so when applied to trouble"

Re: Ethernet trouble

[Bob Weber]

On 1/30/20 1:58 PM, ghe wrote:

On 1/29/20 7:06 PM, David Wright wrote:


These boards, do their PCI addresses have the save bus number but
different slot/device numbers? dmesg or kern.log will give you
those: they look like NN:DD.F optionally preceded by :, where
 is the domain (typically ), NN is the bus, DD the device
of slot, F the function(s) provided by that card, eg
pci :00:0e.0: [10ec:8139] type 00 class 0x02

Well, I don't in any way consider myself a hardware guy, but in Java,
Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
same thing every time I type it.

I looked at dmesg a bit. I greped it for 'enp' and there was a funny
joke in the first 2 lines (of the grep output):

[2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
[2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

So something took the rational Ethernet interface names and,
intentionally I assume, broke hundreds of lines of code.

That's why I recommended you look into systemd link files. Systemd has the 
undesired effect of renaming interfaces.  You need to use the MAC address to 
indicate which port should be eth0 , etc.  See my previous post.



...Bob

Re: Ethernet trouble

[Greg Wooledge]

On Thu, Jan 30, 2020 at 11:58:47AM -0700, ghe wrote:
> Well, I don't in any way consider myself a hardware guy, but in Java,
> Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
> same thing every time I type it.

In bash, += can be used to append to a string variable, to increment a
pseudo-integer variable, or to append new elements to an array.

If you restrict yourself to a raw + sign, it can be a simple string
constant that you're printing, or it can be part of an integer
addition expression, or it can be the special sentinel of a find -exec
command which terminates the -exec and requests xargs(1)-like behavior
(aggregation of many arguments into a single call).

The use of the same syntactic element with different meanings depending
on context is called "overloading".  In some programming languages,
like C++, this is considered a "feature".  You mentioned Java, which
probably does a bit of it as well.  I don't really know Java, thank gods.

For the rest of us, who didn't drink the OO kool-aid, overloading is
just a nightmare.

What this has to do with hardware, I have no idea.

Re: Ethernet trouble

[ghe]

On 1/29/20 7:06 PM, David Wright wrote:

> These boards, do their PCI addresses have the save bus number but
> different slot/device numbers? dmesg or kern.log will give you
> those: they look like NN:DD.F optionally preceded by :, where
>  is the domain (typically ), NN is the bus, DD the device
> of slot, F the function(s) provided by that card, eg
> pci :00:0e.0: [10ec:8139] type 00 class 0x02

Well, I don't in any way consider myself a hardware guy, but in Java,
Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
same thing every time I type it.

I looked at dmesg a bit. I greped it for 'enp' and there was a funny
joke in the first 2 lines (of the grep output):

[2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
[2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

So something took the rational Ethernet interface names and,
intentionally I assume, broke hundreds of lines of code.

Once I was installing a computer that had a single Ethernet port
soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
mobo, 1 was the card. And it was eth1 no matter which slot it was in.

Or if I put in a sound-card.

They were named by function, not by bus and slot. As a programmer, I'm
much more interested in *what* they are, not *where* they are. I
especially don't need some broken piece of software to rename them.

I know I can put them back to the 'inconsistent' names in Grub, and I'll
be doing that -- and editing the shell scripts.

> AIUI it's nothing to do with the OS as these decisions are made by
> the firmware on the mobo. Juggling cards in a mobo can even outwit
> the BIOS so that the POST won't succeed: I've had mobos where I've
> had to empty the box, power-up and save the settings, add one card
> and repeat, add the next and so on, all to get a box with the cards
> I wanted, located where I wanted them.

With all the 'puters I've dealt with, I've never seen anything like
that. If I got one that did that, I'd have sent it back to Amazon and
bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
competently written and tested BIOS.

Besides, we've got UDEV. It allegedly looks at hardware and makes it
make sense. To do that, it must, I suspect, ignore what the BIOS says
and scan the bus(es) itself. If it does that, my Ethernet ports would
have had the same labels, unless somebody renamed them. Would be the
same too, if they'd just been left alone.

I'm not looking forward to systemd.emacs.

-- 
Glenn English

Re: Ethernet trouble

[Andrei POPESCU]

On Mi, 29 ian 20, 12:33:32, Bob Weber wrote:
>  
> I have struggled with this for hours before.  The systemd naming convention
> is explained at:
> 
> https://www.freedesktop.org/software/systemd/man/systemd.link.html
> 
> 
> Pay attention to the Examples near the bottom of the page.  There are
> udevadm commands that you can help you check the configuration.   I ended up
> with the four following configurations:
> 
> 
> 1.  kernel command line option in grub add "net.ifnames=0"
> 
> 
> 2.  /etc/systemd/network/10-eth0.link:
> 
> [Match]
> MACAddress=00:xx:xx:xx:33:ce
> 
> [Link]
> Name=eth0
> 
> 
> 3.  /etc/systemd/network/10-eth0.link:
> 
> [Match]
> MACAddress=00:xx:xx:xx:33:d2
> 
> [Link]
> Name=eth1
> 
> 
> 4.  And finally:
> 
> /etc/systemd/network/99-default.link  linked to /dev/null
> 
> 
> 
> This is my main router machine so these names have to be the same on every
> boot so the firewall rules work as desired.  There also seems to be bugs in
> systemd (I use testing) so that these appear to not work.  I think the key
> was setting 99-default.link to /dev/null.

As an additional suggestion, if one takes the time to set up per 
interface .link files one might as well use intuitive names, like 
"internet", "lan", etc.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ethernet trouble

[David Wright]

On Wed 29 Jan 2020 at 16:52:19 (-0700), ghe wrote:
> 
> (Blush, blush)
> 
> I took those boards out, and the names went back to what I'd expected
> them to be.
> 
> I have no idea why. It doesn't make sense to me -- absolutely nothing
> changed that had anything to do with Ethernet interfaces. The OS and the
> BIOS didn't change either.
> 
> I put them back in, and the names changed.

These boards, do their PCI addresses have the save bus number but
different slot/device numbers? dmesg or kern.log will give you
those: they look like NN:DD.F optionally preceded by :, where
 is the domain (typically ), NN is the bus, DD the device
of slot, F the function(s) provided by that card, eg
pci :00:0e.0: [10ec:8139] type 00 class 0x02

If so, and if they're the only devices on that bus, then it seems
likely that when the bus is unpopulated, it doesn't get enumerated,
whereas when you insert a card, the bus has to be enumerated, and its
enumeration number is ≤ 6, pushing those ethernet buses up by one.

> When I originally installed the boards, the names didn't change.
> (Buster, IIRC, was Testing back then.)
> 
> I've written a lot of software, but my worst bugs never did anything
> like this. And I've been on Debian OSs for a long time, and I don't
> remember anything like this. That's what Sid and Testing are for, but
> Stable's for Internet servers and banks.

AIUI it's nothing to do with the OS as these decisions are made by
the firmware on the mobo. Juggling cards in a mobo can even outwit
the BIOS so that the POST won't succeed: I've had mobos where I've
had to empty the box, power-up and save the settings, add one card
and repeat, add the next and so on, all to get a box with the cards
I wanted, located where I wanted them.

People who set up servers and banks either know this stuff or get
their kit ready-built by the supplier.

Cheers,
David.

Re: Ethernet trouble

[ghe]

(Blush, blush)

I took those boards out, and the names went back to what I'd expected
them to be.

I have no idea why. It doesn't make sense to me -- absolutely nothing
changed that had anything to do with Ethernet interfaces. The OS and the
BIOS didn't change either.

I put them back in, and the names changed.

When I originally installed the boards, the names didn't change.
(Buster, IIRC, was Testing back then.)

I've written a lot of software, but my worst bugs never did anything
like this. And I've been on Debian OSs for a long time, and I don't
remember anything like this. That's what Sid and Testing are for, but
Stable's for Internet servers and banks.

I'm really sorry for bothering the list, but you did manage to point me
to the solution. Thanks.

I hear the scriptKiddies haven't fixed the FreeBSD kernel yet.

-- 
Glenn English

Re: Ethernet trouble

[Michael Stone]

On Wed, Jan 29, 2020 at 03:18:13PM -0700, ghe wrote:

But that had nothing to do with naming Ethernet interfaces. At least to
a human it didn't. They're still on the same PCI bus (0, and soldered to
the same places on MB, as I find I've said before).


some motherboards are better than others about enumerating things. the 
predictable interfaces names work great on server-class gear, but can 
get pretty wonky on consumer hardware. (the firmware is supposed to 
report the mapping between the logical pci bus to a physical slot.) if 
the reporting isn't reliable for whatever reason, you're probably a good 
candidate for changing the naming scheme. mac-based is probably the most 
reliable, but long, and you might be able to get away with the 
traditional linux ethX scheme...but if something is messing up 
initialization order that might also be unreliable.


https://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/ 
has a nice discussion of where the names come from. If you run 
  udevadm info -e | less
and search for net you can see various different naming conventions for 
each device. if you're really curious you can save a copy of the udevadm 
output and if the names change again you can see why.

Re: Ethernet trouble

[Greg Wooledge]

On Wed, Jan 29, 2020 at 03:18:13PM -0700, ghe wrote:
> Do you know something interesting about screwdrivers and UDEV?

You made this mistake earlier, and now once again.  It's not udev.

You *USED* to be able to use udev to work around this.  Not any more.

The new workaround is systemd.link(5).

Re: Ethernet trouble

[ghe]

On 1/29/20 8:14 AM, Curt wrote:

> You haven't been using a screwdriver lately by any chance?

Yes. I put a couple PCI cards back in. But the E'net ports had the same
names when they were in there earlier and when they were out. The change
happened when the were put back.

But that had nothing to do with naming Ethernet interfaces. At least to
a human it didn't. They're still on the same PCI bus (0, and soldered to
the same places on MB, as I find I've said before).

I'll take the UBS3 card and the RME sound-card back out and see what
happens.

Do you know something interesting about screwdrivers and UDEV?

-- 
Glenn English

Re: Ethernet trouble

[Curt]

On 2020-01-29, ghe  wrote:
> On 1/29/20 8:04 AM, Curt wrote:
>
>> 'p' indicates the PCI bus and 's' indicates the slot, was my
>> understanding of the naming scheme. 
>
> Yeah. That's what I was told too.
>
>> Would a BIOS/Firmware upgrade
>> modify the PCI bus and slot number of your Ethernet ports?
>
> I doubt it. SuperMicro's BIOS writers aren't that stupid. I certainly
> hope they aren't.
>
> Besides:
> 1) There was no change to the BIOS.
> 2) The interfaces weren't moved anywhere. They're still soldered to the MB.
>

I see. Has there been *any* hardware change before the glitch?

https://utcc.utoronto.ca/~cks/space/blog/linux/PCINamesNotStable

 
 The resulting reality is that your PCI based names are only stable if you
 change no hardware in the system. The moment you change any hardware all bets
 are off for all hardware. You may get lucky and have some devices keep their
 current PCI names but you may well not. And I don't think you're necessarily
 protected against perverse things like two equivalent devices swapping names
 (or at least one of them winding up with what was the other's old name).

I was unaware of these corner cases that live in rather large corners,
actually.

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Ethernet trouble

[Bob Weber]

On 1/29/20 12:05 PM, ghe wrote:

On 1/29/20 8:04 AM, Curt wrote:


'p' indicates the PCI bus and 's' indicates the slot, was my
understanding of the naming scheme.

Yeah. That's what I was told too.


Would a BIOS/Firmware upgrade
modify the PCI bus and slot number of your Ethernet ports?

I doubt it. SuperMicro's BIOS writers aren't that stupid. I certainly
hope they aren't.

Besides:
1) There was no change to the BIOS.
2) The interfaces weren't moved anywhere. They're still soldered to the MB.

I have struggled with this for hours before.  The systemd naming convention is 
explained at:


https://www.freedesktop.org/software/systemd/man/systemd.link.html 



Pay attention to the Examples near the bottom of the page.  There are udevadm 
commands that you can help you check the configuration.   I ended up with the 
four following configurations:



1.  kernel command line option in grub add "net.ifnames=0"


2.  /etc/systemd/network/10-eth0.link:

[Match]
MACAddress=00:xx:xx:xx:33:ce

[Link]
Name=eth0


3.  /etc/systemd/network/10-eth0.link:

[Match]
MACAddress=00:xx:xx:xx:33:d2

[Link]
Name=eth1


4.  And finally:

/etc/systemd/network/99-default.link  linked to /dev/null



This is my main router machine so these names have to be the same on every boot 
so the firewall rules work as desired.  There also seems to be bugs in systemd 
(I use testing) so that these appear to not work.  I think the key was setting 
99-default.link to /dev/null.


Hope this helps.
--


*...Bob*

Re: Ethernet trouble

[ghe]

On 1/29/20 8:04 AM, Curt wrote:

> 'p' indicates the PCI bus and 's' indicates the slot, was my
> understanding of the naming scheme. 

Yeah. That's what I was told too.

> Would a BIOS/Firmware upgrade
> modify the PCI bus and slot number of your Ethernet ports?

I doubt it. SuperMicro's BIOS writers aren't that stupid. I certainly
hope they aren't.

Besides:
1) There was no change to the BIOS.
2) The interfaces weren't moved anywhere. They're still soldered to the MB.

-- 
Glenn English

Re: Ethernet trouble

[ghe]

On 1/29/20 7:15 AM, Greg Wooledge wrote:

> If you can confirm that it was caused by (or at least, occurred after)
> a firmware upgrade, then at least you'll know that you need to be ready
> for another possible change the next time you upgrade firmware.

Nope. No change(s) in the firmware.

> The enp7s0 style naming is the new "Predictable Network Interface Names"
> scheme.  That is its official name.  It is not, however, an accurate
> description of how it works in reality.  As you've seen, the names
> are NOT predictable.

No, they certainly aren't. The scheme doesn't work. The interfaces are
soldered to the MB, and there were no new ones added, so there should be
no changes in the naming.

> The new workaround to replace udev involves setting up a "dot link"
> file for each interface.  You can do lots of different things, but the
> one that most people will actually care about is mapping a MAC address
> to a name of your choice.  E.g. you can decide to map MAC address
> 01:23:45:67:89:ab to interface name "dmz0", or whatever makes sense
> for your networks.

I've fought with UDEV before, several Debian releases ago. I didn't know
UDEV was responsible for all this. Thanks for the pointer -- I'll see
what I can find in UDEVs config.

-- 
Glenn English

Re: Ethernet trouble

[Curt]

On 2020-01-29, Greg Wooledge  wrote:
> On Wed, Jan 29, 2020 at 03:04:57PM -, Curt wrote:
>> On 2020-01-29, Greg Wooledge  wrote:
>> > Did you perform a BIOS/Firmware upgrade on your motherboard?  That's
>> > one of the things that can cause this.
>> 
>> 'p' indicates the PCI bus and 's' indicates the slot, was my
>> understanding of the naming scheme. Would a BIOS/Firmware upgrade
>> modify the PCI bus and slot number of your Ethernet ports?
>
> Yes.  Yes, it can.
>

Well, then, I guess it's either that or the Screwdriver Hypothesis.


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Ethernet trouble

[Greg Wooledge]

On Wed, Jan 29, 2020 at 03:04:57PM -, Curt wrote:
> On 2020-01-29, Greg Wooledge  wrote:
> > Did you perform a BIOS/Firmware upgrade on your motherboard?  That's
> > one of the things that can cause this.
> 
> 'p' indicates the PCI bus and 's' indicates the slot, was my
> understanding of the naming scheme. Would a BIOS/Firmware upgrade
> modify the PCI bus and slot number of your Ethernet ports?

Yes.  Yes, it can.

Re: Ethernet trouble

[Curt]

On 2020-01-28, ghe  wrote:
> Buster, SuperMicro box
>
> The labels for my Ethernet ports have changed.

You haven't been using a screwdriver lately by any chance?

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Ethernet trouble

[Curt]

On 2020-01-29, Greg Wooledge  wrote:
> On Tue, Jan 28, 2020 at 04:34:15PM -0700, ghe wrote:
>> Buster, SuperMicro box
>> 
>> The labels for my Ethernet ports have changed.
>> 
>> There are 2 ports on this box. They used to be called enp6s0 and enp7s0.
>> Now they're called enp7s0 and enp8s0 (6, 7, and 8).
>
> Did you perform a BIOS/Firmware upgrade on your motherboard?  That's
> one of the things that can cause this.
>

'p' indicates the PCI bus and 's' indicates the slot, was my
understanding of the naming scheme. Would a BIOS/Firmware upgrade
modify the PCI bus and slot number of your Ethernet ports?


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Ethernet trouble

[tomas]

On Wed, Jan 29, 2020 at 09:15:31AM -0500, Greg Wooledge wrote:

[...]

> The enp7s0 style naming is the new "Predictable Network Interface Names"
> scheme.  That is its official name.  It is not, however, an accurate
> description of how it works in reality.  As you've seen, the names
> are NOT predictable.

Yeah. Alas. It didn't work out as expected :-/

> Prior to buster, the "Predictable" scheme was optional [...]

> In buster, however, udev's 70-persistent-net.rules is no longer supported.
> It *might* work, or it might not.

I have, in buster,

  GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"

in /etc/default/grub. My interfaces are still eth0 and wlan0. As far
as I know it's some udev &$%*@#ggery renaming the interfaces -- the
kernel itself chooses the (also unpredictable, mind you) old style
names first.

Whatever.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Tue, Jan 28, 2020 at 04:34:15PM -0700, ghe wrote:
> Buster, SuperMicro box
> 
> The labels for my Ethernet ports have changed.
> 
> There are 2 ports on this box. They used to be called enp6s0 and enp7s0.
> Now they're called enp7s0 and enp8s0 (6, 7, and 8).

Did you perform a BIOS/Firmware upgrade on your motherboard?  That's
one of the things that can cause this.

> Everything seems to work as 7 and 8. But this morning, it was 6 and 7.
> My shell scripts are all broken now and I'm afraid that next week, after
> I change all my scripts, something will change things back. Or increment
> them again.

If you can confirm that it was caused by (or at least, occurred after)
a firmware upgrade, then at least you'll know that you need to be ready
for another possible change the next time you upgrade firmware.

The enp7s0 style naming is the new "Predictable Network Interface Names"
scheme.  That is its official name.  It is not, however, an accurate
description of how it works in reality.  As you've seen, the names
are NOT predictable.

Prior to buster, the "Predictable" scheme was optional.  You were allowed
to opt out of it by using the /etc/udev/rules.d/70-persistent-net.rules
configuration file.  If you had one of these from an earlier release,
and upgraded to stretch, it would continue to work, and you wouldn't
even notice any changes.

In buster, however, udev's 70-persistent-net.rules is no longer supported.
It *might* work, or it might not.

The new workaround to replace udev involves setting up a "dot link"
file for each interface.  You can do lots of different things, but the
one that most people will actually care about is mapping a MAC address
to a name of your choice.  E.g. you can decide to map MAC address
01:23:45:67:89:ab to interface name "dmz0", or whatever makes sense
for your networks.

Please see:

https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES
https://wiki.debian.org/NewInBuster#Network_interface_name_migration
https://manpages.debian.org/man/5/systemd.link

Re: Ethernet trouble

[Klaus Singvogel]

elvis wrote:
> It sounds like it is already using the consistent interface names.

It's even possible to name the devices after their MAC addresses.
Then it might be possible to identify them uniqly, on the other hand,
he will get long device names (enx78e7d1ea46da).

Didn't use this method by myself ever, no experience, so I'm pointing him
to this solution only.

Another way of naming is the troditional way: eth0.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Ethernet trouble

[elvis]

On 29/1/20 5:48 pm, Klaus Singvogel wrote:

ghe wrote:

Anybody have an explanation? Or somewhere I can start looking? Or know
how whatever labels Ethernet ports does it (or why they weren't called 0
and 1 in the first place)?

The keywords you want to search for:
udev, "consistent network device names", and debian



It sounds like it is already using the consistent interface names.




Best regards,
Klaus.


--
SURREAL now loaded. Continue? (F)ish (E)lbow (A)rtechoke F(R)apple

Re: Ethernet trouble

[Alex Mestiashvili]

My shell scripts are all broken now and I'm afraid that next week, after
I change all my scripts, something will change things back. Or increment
them again.

Anybody have an explanation? Or somewhere I can start looking? Or know
how whatever labels Ethernet ports does it (or why they weren't called 0
and 1 in the first place)?



This something is called udev.
Look in udev rules, try to unload and load kernel module for the network 
card and see what are udev actions.

Re: Ethernet trouble

[Klaus Singvogel]

ghe wrote:
> Anybody have an explanation? Or somewhere I can start looking? Or know
> how whatever labels Ethernet ports does it (or why they weren't called 0
> and 1 in the first place)?

The keywords you want to search for:
udev, "consistent network device names", and debian

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Ethernet Connection Dropped Again

[Dan Ritter]

On Wed, Feb 14, 2018 at 06:44:55PM -0500, Thomas George wrote:
> Starting last month the PC Ethernet connection is sometimes not made
> atbootup or is occasionally lost. When this happens the only way I havefound
> to re-establish the connection is to turn the TP-Link AC1750 router off and
> on again.
> 
> The system is Debian Stretch.
> 
> The connection was just dropped and I recorded the attached last 60 lines of
> dmesg and syslog
> 
> Can anyone tell me why this happens or point me to references I must study
> to learn how to fix this?
> 
> 
> 
> [8.573411] r8169 :03:00.0: firmware: failed to load 
> rtl_nic/rtl8168d-2.fw (-2)
> [8.573471] r8169 :03:00.0: Direct firmware load for 
> rtl_nic/rtl8168d-2.fw failed with error -2
> [8.573474] r8169 :03:00.0 enp3s0: unable to load firmware patch 
> rtl_nic/rtl8168d-2.fw (-2)
> [8.596929] r8169 :03:00.0 enp3s0: link down
> [8.596942] r8169 :03:00.0 enp3s0: link down
> [8.600278] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
> [   16.181809] r8169 :03:00.0 enp3s0: link up
> [   16.181825] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
> [   57.501798] r8169 :03:00.0 enp3s0: link down
> [   74.041344] r8169 :03:00.0 enp3s0: link up
> [   74.977952] r8169 :03:00.0 enp3s0: link down
> [   79.850298] r8169 :03:00.0 enp3s0: link up
> [  161.205363] r8169 :03:00.0 enp3s0: link down
> [  180.008520] r8169 :03:00.0 enp3s0: link up
> [  183.550534] r8169 :03:00.0 enp3s0: link down
> [  188.145323] r8169 :03:00.0 enp3s0: link up
> [  335.644775] r8169 :03:00.0 enp3s0: link down
> [  362.971011] r8169 :03:00.0 enp3s0: link up

These are the pertinent lines.

Likely causes:

- the cable is bad
- the router's switch module is bad, perhaps overheating
- the NIC is bad

I googled for "TP-Link AC1750 ethernet drop" and found lots of
hits, so I would guess that you should complain to TP-Link. 

-dsr-

Re: Ethernet Connection Dropped Again

[Brian]

On Wed 14 Feb 2018 at 18:44:55 -0500, Thomas George wrote:

> Starting last month the PC Ethernet connection is sometimes not made
> atbootup or is occasionally lost. When this happens the only way I havefound
> to re-establish the connection is to turn the TP-Link AC1750 router off and
> on again.
> 
> The system is Debian Stretch.
> 
> The connection was just dropped and I recorded the attached last 60 lines of
> dmesg and syslog
> 
> Can anyone tell me why this happens or point me to references I must study
> to learn how to fix this?

Firmware (lack of)? firmware-realtek is the package.

-- 
Brian.

Re: Ethernet is not started at boot

[Charlie Gibbs]

On 08/02/18 01:22 AM, Erik Christiansen wrote:


On 08.02.18 08:42, to...@tuxteam.de wrote:


On Thu, Feb 08, 2018 at 01:36:41PM +1100, Erik Christiansen wrote:

[...]


[...] Fastidious fusspotting on minor terminology matters [...]


Yikes :-)

May I steal this one when I need it badly?


It's escaped now, so please feel free. Here's hoping it's not badly
needed too often.


I'm still chuckling about "the entomological leviathan that is Windows."

--
cgi...@surfnaked.ca (Charlie Gibbs)

Re: Ethernet is not started at boot

[Richard Hector]

On 08/02/18 15:36, Erik Christiansen wrote:
>> Please don't use "class B" to mean /16. Firstly, it's decades out of
>> date, and secondly, that range was never in the class B section.
> I'm decades out of date too, so it's apt. The intended audience can
> probably discern the message that a broader common netmask doesn't weigh
> more than a precisely fitted one which might or might not work as
> expected. Fastidious fusspotting on minor terminology matters does not
> contribute anything to the meat of the matter, no matter how much it
> massages the author's ego.

The thing is, I don't consider this a minor terminology matter. It's
adding confusion to the subject by persisting with out of date concepts.
We'd all be better off forgetting about classes, but people keep
bringing them back up again ...

Richard




signature.asc
Description: OpenPGP digital signature