Gelöst Woher/Wohin all diese eth[0....x]?

[wbwb]

Ich muss auf einem dieser Laptops (unter Leap 15.4) arbeiten, die LAN nur noch über USB C bekommen. Es hat bei mir (wie üblich) erst mal gedauert, bis ich bemerkt habe, dass mir anscheinend für jede neue Docking-Station, für jeden neuen USBC-Dongle und für was auch immer 'Neues', das ich in den USBC Port stecke um darüber LAN zu beziehen, der Laptop nett und freundlich eine neue eth Nummer gibt ...weil? ... weil neuer USB Device?? ... weil keine Ahnung. Könnt ihr zu dieser 'wundersamen Vermehrung' der eth-s etwas sagen? Ist das 'normal'? Hat eine:r von Euch auch so ein Verhalten?

Inzwischen bin ich jedenfalls bei eth4 angekommen. /etc/udev/rules.d/70-persistent-net.rules zeigt diese eth0 - eth4 auch alle an. Dr. Google sagt einem man könne letztere Datei einfach mal löschen und sie würde dann nach dem Reboot automatisch wieder erzeugt. Hat eine:r von Euch so etwas schon mal gemacht? Und wenn ja, hat das funktioniert und fing man dann wieder mit eth0 an?

 

[susejunky]

Hallo @wbwb ,

... anscheinend für jede neue Docking-Station, für jeden neuen USBC-Dongle und für was auch immer 'Neues', das ich in den USBC Port stecke um darüber LAN zu beziehen, mir der Laptop nett und freundlich eine neue eth Nummer gibt

Wenn jedes dieser "neuen Geräte" eine eigene (individuelle) MAC-Adresse hat, dann ist es durchaus sinnvoll und gerechtfertigt, dass für jedes dieser Geräte auch eine neue Schnittstellenbezeichnung (eth0, eth1, ...) erzeugt und genutzt wird. Schließlich könntest Du mehrere dieser Geräte (USB-Dongle) gleichzeitig an Deinem PC betreiben (vorausgesetzt Dein PC verfügt über ausreichend USB-Ports) und dann müsstest Du jedes dieser Geräte gezielt ansprechen können.

Ansonsten rate ich Dir davon ab, die Datei /etc/udev/rules.d/70-persistent-net.rules zu löschen. Es sei denn, Du bist Dir sicher die eventuelle daraus entstehenden Probleme auch wieder beseitigen zu können.

Viele Grüße

susejunky

 

[wbwb]

Hallo @susejunky

Wenn jedes dieser "neuen Geräte" eine eigene (individuelle) MAC-Adresse hat, dann ist es durchaus sinnvoll

das macht im Prinzip Sinn, aber so richtig verstehen tue die Sache nicht: Im WWW liest man, dass es so etwas wie "MAC passthrough" auf diesen nur-noch-USB-C-Dingern gibt ... und ohne dass ich das wusste und vorher überhaupt gesehen hatte ... ist dieses MAC passthrough im BIOS/UEFI meines DELL(Klapperkasten) ab Werk eingeschaltet.

Nun verstehe ich nur noch Bahnhof. Heißt das jetzt, dass mein Laptop im Netz immer dieselbe MAC hat, dass ich aber wegen der unterschiedlichen MACs der Docking Stations auf dem Laptop selbst lauter neue Schnittstellen-Namen bekomme? Hast Du dazu eine Meinung?

(Ich werde mal einen arp scan mit dem Laptop an unterschiedlich Docks machen.)

 

[josef-wien]

Das über USB angeschlossene Gerät ist eine Netzwerkkarte. Logischerweise hat jedes derartige Gerät eine eigene MAC-Adresse. Wenn Du immer eth0 haben willst, braucht Du eine eigene udev-Regel, Wenn die bestehende Datei eine normale Zuweisung [=] vornimmt, muß die Datei später zum Zug kommen, also eine höhere Nummer aufweisen (z. B. 99-local.rules). Bei einer endgültigen Zuweisung [:=] muß die Datei früher zum Zug kommen und selbst eine endgültige Zuweisung vornehmen.

MAC passthrough

Was soll der Laptop durchreichen?

 

[marce]

wenn's sauber funktioniert reicht der Laptop seine eigene MAC an das Dock durch und ist darüber sichbar. Bedingt aber passende Hardware + passendes BIOS + passende Firmware auf dem Dock.

 

[susejunky]

Hallo @wbwb ,

Hast Du dazu eine Meinung?

meine Meinung spielt da wohl weniger eine Rolle.

Keines meiner Geräte verfügt über "MAC passthrough" daher beschränkt sich mein Wissen auf das, was die Firma Dell zu diesem Thema sagt.

Wenn ich das richtig verstehe, dann müssen die beteiligten Komponenten (Laptop, Docks, USB-Dongles, ...) aufeinander abgestimmt sein, damit "MAC passthrough" funktioniert.

Vielleicht kann der Inhalt von /etc/udev/rules.d/70-persistent-net.rules dazu mehr informationen liefern. Zeige bitte das Ergebnis von

cat /etc/udev/rules.d/70-persistent-net.rules

Viele Grüße

susejunky

 

[wbwb]

Logischerweise hat jedes derartige Gerät eine eigene MAC-Adresse.

Ich bin halt ein einfaches Gemüt und "dachte" da wäre noch ein bisschen Netzwerkkarte inkl. MAC in solchen Laptops drin, die einfach nur über USB-C statt über RJ nach außen geht aber jetzt bin ich viiiel schlauer!

wenn's sauber funktioniert ... Bedingt aber passende Hardware + passendes BIOS + passende Firmware auf dem Dock.

Ja, laut DELL Infos ist das die Theorie. In der Praxis scheint das Wörtchen "passend" wohl wichtig zu sein. Anyway. Ich habe einfach mal bei ein paar (=3) der Docks und Hubs mit einem anderen Rechner einen Arp-Scan auf dem Subnetz gemacht an dem der Laptop hängt und da "pass-te gar nix through" außer der MAC, die jeweils in ip a und in der /etc/udev/rules.d/70-persistent-net.rules für den jeweils ein-gestöpselten Dock/Hub auch schon zu sehen war.

D.h. meine anfängliche Frage ist damit für mich irgendwie geklärt. Danke. Wenn ich bei eth123 angekommen bin frage ich nochmal nach, wie ich die nicht mehr benützen wieder loswerde.

 

[josef-wien]

Du kannst jederzeit einige oder auch alle Zeilen aus 70-persistent-net.rules entfernen. 75-persistent-net-generator.rules (wo immer die bei openSUSE gespeichert ist) sorgt schon dafür, daß für die jeweilige MAC-Adresse eine Eintragung in 70-persistent-net.rules vorhanden ist.

 

[susejunky]

75-persistent-net-generator.rules (wo immer die bei openSUSE gespeichert ist)

Ja, das ist die spannende Frage!

 

[tomm.fa]

75-persistent-net-generator.rules (wo immer die bei openSUSE gespeichert ist)

Ja, das ist die spannende Frage!

/usr/lib/udev/rules.d/75-persistent-net-generator.rules

Jedenfalls bei openSUSE Leap 15.4, bei Tumbleweed anscheinend nicht vorhanden.

 

[susejunky]

/usr/lib/udev/rules.d/75-persistent-net-generator.rules

Hmmm, ...

# ls -la /usr/lib/udev/rules.d/7*.rules
-rw-r--r-- 1 root root   281 30. Jan 09:29 /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- 1 root root   306 31. Aug 15:27 /usr/lib/udev/rules.d/70-infrared.rules
-rw-r--r-- 1 root root   432 30. Jan 09:29 /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- 1 root root   184 30. Jan 09:29 /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- 1 root root   734 30. Jan 09:29 /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- 1 root root  1988  2. Feb 19:54 /usr/lib/udev/rules.d/70-nvmf-autoconnect.rules
-rw-r--r-- 1 root root   576 30. Jan 09:29 /usr/lib/udev/rules.d/70-power-switch.rules
-rw-r--r-- 1 root root   473 30. Jan 09:29 /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- 1 root root  3311  2. Feb 21:00 /usr/lib/udev/rules.d/70-uaccess.rules
-rw-r--r-- 1 root root   276  2. Feb 19:54 /usr/lib/udev/rules.d/71-nvmf-iopolicy-netapp.rules
-rw-r--r-- 1 root root  3818  2. Feb 21:00 /usr/lib/udev/rules.d/71-seat.rules
-rw-r--r-- 1 root root   643  2. Feb 21:00 /usr/lib/udev/rules.d/73-seat-late.rules
-rw-r--r-- 1 root root   452 30. Jan 09:29 /usr/lib/udev/rules.d/75-net-description.rules
-rw-r--r-- 1 root root   174 30. Jan 09:29 /usr/lib/udev/rules.d/75-probe_mtd.rules
-rw-r--r-- 1 root root   936 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-broadmobi-port-types.rules
-rw-r--r-- 1 root root  3763 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-cinterion-port-types.rules
-rw-r--r-- 1 root root  1767 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-dell-port-types.rules
-rw-r--r-- 1 root root   866 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-dlink-port-types.rules
-rw-r--r-- 1 root root  8084 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-ericsson-mbm.rules
-rw-r--r-- 1 root root  3095 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-fibocom-port-types.rules
-rw-r--r-- 1 root root  1603 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-foxconn-port-types.rules
-rw-r--r-- 1 root root   907 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-gosuncn-port-types.rules
-rw-r--r-- 1 root root   525 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-haier-port-types.rules
-rw-r--r-- 1 root root  2596 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-huawei-net-port-types.rules
-rw-r--r-- 1 root root   697 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-linktop-port-types.rules
-rw-r--r-- 1 root root 14434 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-longcheer-port-types.rules
-rw-r--r-- 1 root root  3282 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-mtk-port-types.rules
-rw-r--r-- 1 root root  2176 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-nokia-port-types.rules
-rw-r--r-- 1 root root  1619 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-qcom-soc.rules
-rw-r--r-- 1 root root  4404 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-quectel-port-types.rules
-rw-r--r-- 1 root root  1856 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-sierra.rules
-rw-r--r-- 1 root root  3876 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-simtech-port-types.rules
-rw-r--r-- 1 root root 11598 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-telit-port-types.rules
-rw-r--r-- 1 root root   739 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-tplink-port-types.rules
-rw-r--r-- 1 root root  4215 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-ublox-port-types.rules
-rw-r--r-- 1 root root  4602 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-x22x-port-types.rules
-rw-r--r-- 1 root root 17179 12. Okt 18:48 /usr/lib/udev/rules.d/77-mm-zte-port-types.rules
-rw-r--r-- 1 root root  4816 30. Jan 09:29 /usr/lib/udev/rules.d/78-sound-card.rules
#

Sollte ich da etwas übersehen haben?

Mein System:

Betriebssystem: openSUSE Tumbleweed 20230214
KDE-Plasma-Version: 5.27.0
KDE-Frameworks-Version: 5.103.0
Qt-Version: 5.15.8
Kernel-Version: 6.1.10-1-default (64-bit)
Grafik-Plattform: X11
Grafikprozessor: Mesa Intel® HD Graphics 630

Viele Grüße

susejunky

 

[tomm.fa]

Ich hatte meinen Beitrag, nachdem ich den Rechner gewechselt habe, kurz vor deiner Veröffentlichung ergänzt.

Tumbleweed:

find /usr | grep -Ei "net-generator"
/usr/lib/dracut/modules.d/90livenet/livenet-generator.sh

und unter /lib/ überhaupt nichts.

 

[wbwb]

Hatte nicht bemerkt, dass die Sache evtl. irgendwie doch noch nicht 'gelöst' zu sein scheint:
Ja @susejunky hatte mögliche Probleme bei einer Löschung /etc/udev/rules.d/70-persistent-net.rules angemahnt

rate ich Dir davon ab, die Datei /etc/udev/rules.d/70-persistent-net.rules zu löschen. ...

Aber in meiner /etc/udev/rules.d/70-persistent-net.rules steht

# This file was automatically generated by the /usr/lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.

D.h., was meine Systeme (openSUSE Leap 15.X, X=1-4) angeht, träfe danach die Aussage von @josef-wien zu und i.d. Tat läßt sich seine diesbezügliche 'Frage'

... (wo immer die bei openSUSE gespeichert ist) sorgt schon dafür ...

für meine Systeme auch einfach beantworten

~>locate persistent-net-generator.rules
/usr/lib/udev/rules.d/75-persistent-net-generator.rules

und die Datei gibt es auch wirklich (und das System 'macht irgendwas' damit - siehe time stamp)

~>ls -al /usr/lib/udev/rules.d/75-persistent-net-generator.rules
-rw-r--r-- 1 root root 5593 19. Jan 09:28 /usr/lib/udev/rules.d/75-persistent-net-generator.rules

Vielleicht ist es ja ein Tumbleweed issue(?) Trotzdem würde ich mich nicht ohne Eure geschätzte Hilfe trauen mal-auf-die-Schnelle aus /etc/udev/rules.d/70-persistent-net.rules ein paar Sachen zu löschen - deshalb lieber erst ab eth123

 

[susejunky]

Hallo @wbwb ,

Vielleicht ist es ja ein Tumbleweed issue(?)

openSUSE Tumbleweed verwendet eine andere Vorgehensweise als openSUSE Leap.

Wenn Du gerne mehr zu der Benennung von Netzwerkschnittstellen unter Linux erfahren möchtest, dann kannst Du Dir folgenden Beitrag und die darin enthaltenen Verweise auf weitere Informationsquellen durchlesen.

Noch mehr Informationen kannst Du möglicherweise finden, wenn Du mit der Suchmaschine Deines Vertrauens nach "consistent network interface device naming" oder "predictable network interface device names" suchst.

Viele Grüße

susejunky

 

[josef-wien]

Benennung von Netzwerkschnittstellen unter Linux

Du meinst "systemd", der Kernel hat mit dieser Vorgangsweise nichts zu tun. Und es wird wohl gute Gründe geben, wenn das der Enterprise-Version nahestehende Leap bei dieser Mode nicht mitmacht.

nicht ohne Eure geschätzte Hilfe trauen

Du kannst nichts kaputt machen. Falls versehentlich Fragmente von Regeln übrigbleiben, wirst Du Fehlermeldungen im Log finden, aber daß das Netzwerk nicht startet, wirst Du mit dieser Datei nicht schaffen.

 

[susejunky]

Hallo @josef-wien ,

der Kernel hat mit dieser Vorgangsweise nichts zu tun.

... we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname's (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:

1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
5. Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence.
Come again, what good does this do?

With this new scheme you now get:

• Stable interface names across reboots
• Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place (to the level the firmware permits this)
• Stable interface names when kernels or drivers are updated/changed
• Stable interface names even if you have to replace broken ethernet cards by new ones
• The names are automatically determined without user configuration, they just work
• The interface names are fully predictable, i.e. just by looking at lspci you can figure out what the interface is going to be called
• Fully stateless operation, changing the hardware configuration will not result in changes in /etc
• Compatibility with read-only root
• The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in /dev via symlinks
• Applicability to both x86 and non-x86 machines
• The same on all distributions that adopted systemd/udev
• It's easy to opt out of the scheme (see below)

Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before they can invoke commands on it where previously they had a good chance that "eth0" was the right name.
I don't like this, how do I disable this?

You basically have three options:

1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: ln -s /dev/null /etc/systemd/network/99-default.link
2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See systemd.link(5) for more information.
3. You pass the net.ifnames=0 on the kernel command line

Viele Grüße

susejunky

 

[josef-wien]

Dein ausführliches Zitat bestätigt meine Aussage. Alle Veränderungen passieren durch systemd bzw. dessen udev (die gnädigerweise erlauben, daß der seit Äonen gültige Punkt 5 auch gewählt werden kann).

P. S. Die im zweiten Punkt 3. genannte Boot-Option net.ifnames=0 ist keine Anweisung an den Kernel, sondern an systemd bzw. dessen udev.

 

[susejunky]

Hallo @josef-wien ,

Dein ausführliches Zitat bestätigt meine Aussage.

wenn Du das sagst ...

... systemd bzw. dessen (?) udev

udev - initial release November 2003
systemd - initial release March 2010

Viele Grüße

susejunky

 

[josef-wien]

systemd bzw. dessen udev

Meine Formulierung darf durchaus mißfallen. Mit Version 183 wurden die beiden Dinge zusammengelegt. udev ohne systemd mag zwar formal immer noch möglich sein (da habe ich nicht nachgeforscht), praktikabel ist "require the *build* of the systemd tree" aber nicht. Ein fork wie eudev wurde ja ins Leben gerufen (und blüht und gedeiht), um unter anderem diesen unnötigen Ballast zu vermeiden. Vielleicht werde ich in Zukunft den Begriff systemd-udev heranziehen, der kommt ja wie auch systemd-udevd für den Dämon im changelog wiederholt vor, vielleicht aber auch nicht.