eth0 und eth1 werden haeufig vertauscht

[gbrinkmann]

Hallo,

nachdem udev selber die Rolle von hotplug uebernommen hat (in debian/sid, was ich benutze), werden bei jedem Booten zufaellig die Interfaces eth0 und eth1 vergeben. Da pppoe so konfiguriert ist, dass das dsl-modem nur an eth1 gefunden wird, kommt man also nicht online, wenn das Modem ploetzlich an eth0 haengt.

Derzeit loese ich das Problem durch ein einfaches Neu-Booten. Ist zwar nervig, aber danach funktioniert es meist, weil die Interfaces wieder richtig vergeben wurden.

Frage: Wie lege ich sicher fest, welches Interface fuer welche Netzwerk-Buchse eingesetzt werden soll? Ich vermute, man muss es an die MAC-Adresse binden?

Gruss,

Gert

[KBDCALLS]

Trage die Module in der richtigen Reihenfolge in der

Code: Alles auswählen

/etc/modules 

ein.

[MartinL25]

Deine Vermutung ist richtig. Check mal "/usr/share/doc/ifupdown/examples". Da ist eine Datei "network-interfazes.gz", die verschiedene Beispielseinträge für "/etc/network/interfaces" enthält. U.a. auch wie man Interfaces nach MAC-Adressen benennt. Das benötigte Shell-Script "get-mac-address.sh" ist im selben Verzeichnis.

Gruß Martin

[gbrinkmann]

Danke fuer die Antworten.

@KBDCALLS
Das funktioniert aber nur, wenn man 2 Ethernet-Karten im Rechner hat, die unterschiedliche Module benoetigen. (Ok, waere bei mir wahrscheinlich der Fall, aber ich weiss auch gar nicht, welches Modul fuer welche Karte geladen wird. Ausserdem weiss ich nicht, ob nicht irgendwelche Parameter noetig sind, die der hotplug-Mechanismus selber ermittelt. Daher moechte ich an dieser Stelle nur ungern ansetzen.)

@MartinL25
Genau nach einer solchen Info hatte ich gesucht. Auf den ersten Blick ist zwar nicht exakt der Fall dabei, den ich gerne haette, aber vielleicht findet sich da ja noch etwas. (Ich moechte keine logischen Namen "lan" und "internet" einfuehren, weil ich sonst auch noch an der erstellten Datei von pppoeconf dran muss. Je mehr man manuell eingreift, desto fraglicher ist es, wie zukunftskompatibel das dann ist.)

Gruss,

Gert

[KBDCALLS]

Wenn man zei Unterschiedliche Netzwerkkarten hat wird das aber die einfachsteste Lösung sein. Obs zei unterschiedliche Netzwerkkarten sin kannst du mit lspci feststellen. Da kommt dann sowas aähnliches bei raus. Siehe hier

http://nopaste.debianforum.de/1493

Die mit der niedrigstens PCI Adresse wird von Hotplug zuerst geladen.

Ich hatte es schon mal versucht über die Mac Adresse der Karte (hwaddress) und auch die hwaddr die lspci ausgibt. Beides war jeweils ein Griff ins Klo. Die Manpage von Interfaces ist auch nicht gerade in dem Punkte so abegefasst das sie den Sachverhalt eindeutig erhellen könnte.

[MartinL25]

Kann ich prinzipiell verstehen. Man kann aber bei pppoeconf als Parameter den Devicenamen angeben, der benutzt werden soll. Ist in der Man-Page natürlich nicht angegeben, aber "pppoeconf dsl-lan" (falls Du beispielsweise dsl-lan als logisches Netzwerkdevice verwendest) sollte klappen. Nützt natürlich nur was, falls man pppoeconf selber in der Shell aufruft, nicht wenn pppoeconf von irgendeinem Skript aufgerufen wird. Ansonsten mußt Du einen Shell-Scripter darauf ansetzen, pppoeconf so umzuschreiben, daß es nicht nur nach physischen Devices guckt, sondern auf Anwenderwunsch auch einen beliebigen Devicenamen akzeptiert. Ich schätze, ein entsprechender Patch hätte Chancen akzeptiert zu werden, immer mehr Leute haben immerhin Mainboards mit zwei On-Board-Netzwerkkarten. Kann sogar sein, daß ein entsprechender Wishlist-Bug ausreicht und die Maintainer das machen.

Gruß Martin

[KBDCALLS]

Das ganze ifup/ifdown zeugs dürfte warscheinlich einer generellen Überarbeitung.

[MartinL25]

lustig, auf einmal komm ich nicht mehr ins Internet. Stellt sich raus, daß beim dist-upgrade heute morgen irgendetwas geändert wurde, so daß meine Netzwerkkarte auf einmal als eth1 bezeichnet wurde und (ich glaube) mein Firewireanschluß als eth0. Hab ich beim Reboot rausgefunden. Naja, pppoe schnell auf eth1 umgestellt und es läuft wieder. Lustig wird so was erst, wenn man einen ferngewarteten Server betreut Und ich sach noch, sach ich noch: Auf Servern nur Stable !!!

Gruß Martin

[gms]

Die sicherste und einfachste Methode dieses Problem zu beheben:
in die /etc/modprobe.d/aliases folgendes eintragen:

Code: Alles auswählen

alias eth0 <modul 1>
alias eth1 <modul 2>

sollten beide netzwerkkarten das gleiche Modul benötigen, kann über "options" auch dieses Problem gelöst werden

<modul 1> und <modul 2> gehört natürlich durch die entsprechenden Modulnamen ersetzt.

Gruß
gms

[KBDCALLS]

Oder mittles Hotplug verhindern das das Modul eth1394 geladen wird.

[gbrinkmann]

@KBDCALLS
Warum meinst Du, dass das Modul eth1394 damit etwas zu tun hat? Das kenne ich nur im Zusammenhang mit nicht funktionierendem dvgrab (bei geladenem Modul kommen keine DV-Daten von dem Camcorder zum Rechner)

Aber zurueck zum Problem:
Ich weiss jetzt, wie man dies, zumindest theoretisch (habe es noch nicht
ausprobiert) sauber in den Griff bekommt. Ich bin nur
enttaeuscht, dass dies ueberhaupt noetig ist. Ausserdem ist die Frage,
warum das ohne udev nicht schon frueher alles vertauscht wurde. Erst
durch udev ist es ja ueberhaupt moeglich, die Dev-Bezeichnungen exakt
zuzuweisen.

siehe:
file:///usr/share/doc/udev/writing_udev_rules/index.html

und speziell:
file:///usr/share/doc/udev/writing_udev_rules/index.html#example-iface

Gruss,

Gert

[KBDCALLS]

Wie man unschwer an den ersten drei Buchstaben des Modunamemens eth1394 unschwer erkennen kann ist dieses Modul für Neztwerk zuständig. Jetzt ist Firewire aber meistens on Board. Das heißt zuerst wird Firewire geladen und dann die Module für die Netzwerkkarte die im PCI Slot steckt. Die Netzwerkarte die als ersten aktiv wird wird halt eth0 . Was allerdings das eth1394 mit der Camera zu tun ist mir nicht so ganz klar.

[gbrinkmann]

zuerst wird Firewire geladen und dann die Module für die Netzwerkkarte die im PCI Slot steckt. Die Netzwerkarte die als ersten aktiv wird wird halt eth0

Ah ok, ich sehe jetzt den Zusammenhang.

Was allerdings das eth1394 mit der Camera zu tun ist mir nicht so ganz klar.

Wie man unscher erkennen kann... Ok, lassen wir das

Ist das eth1394 Modul, das von hotplug automatisch mit hochgezogen wird, wenn eine Firewire-Schnittstelle im System ist, da es ja sein koennte, dass man darueber ein Netzwerk aufbauen wollte, dann stoert dieses die Datenuebertragung von Videomaterial aus dem Camcorder. Der ueber Firewire angeschlossene Camcorder wird zwar angesteuert (start, stop, etc.), aber die DV-Daten kommen nicht an. Entfernt man eth1394, dann funktioniert es. Ob das immer so ist oder nur in bestimmten Faellen, weiss ich aber nicht. Bei mir war es jedenfalls der Fall.

Gruss,

Gert

[gbrinkmann]

Hier noch mal abschliessend, wie ich die udev-Regeln erstellt habe. Es scheint wirklich zu funktionieren:

In "/etc/udev/rules.d" habe ich die Datei "000_gert.rules" erstellt.

Darin steht:

Code: Alles auswählen

KERNEL="eth*", SYSFS{address}="00:0a:e6:ac:f4:a7", NAME="eth0"
KERNEL="eth*", SYSFS{address}="00:00:1c:09:cc:af", NAME="eth1"

Die "address" ermittelt man wie folgt:

Code: Alles auswählen

udevinfo -a -p /sys/class/net/eth0/ | grep address

(Entsprechend fuer eth1)

Gruss,

Gert

[steff aka sid]

Die sicherste und einfachste Methode dieses Problem zu beheben:
in die /etc/modprobe.d/aliases folgendes eintragen:

Code: Alles auswählen

alias eth0 <modul 1>
alias eth1 <modul 2>

sollten beide netzwerkkarten das gleiche Modul benötigen, kann über "options" auch dieses Problem gelöst werden

<modul 1> und <modul 2> gehört natürlich durch die entsprechenden Modulnamen ersetzt.

Gruß
gms

Das hilft nichts. Hatte ein ähnliches Problem und dachte mir oh schreibst du halt die aliases. Danach bestand das Problem aber trotzdem weiter als wenn er diese Einträge ignoieren würde. Hab das Problem dann dadurch gelöst das ich mir nen script geschrieben hab dass das modul was nicht auf eth1 liegen sollte einfach mit modprobe -r geunloaded habe und dann das modul was eigentlich eth1 sein sollte mit modprobe neu geladen und schon hatte ich was ich wollte. Muss aber dazu sagen dass dieses vertauschen bei mir relativ selten war.

Gruß Steff

[gbrinkmann]

Die alias-Loesung hat bei mir auch nicht funktioniert. Auch das Eintragen in der richtigen Reihenfolge in der /etc/modules brachte nichts. (Wobei mein Problem auch ist, dass ich nicht weiss, welche der ganzen modules* Dateien ueberhaupt noch unter Kernel 2.6.x aktuell sind und nicht durch modprobe* Dateien abgeloest wurden)

Noch ein Hinweis zu den udev-rules: Nach Erstellen der rules-Datei muss man noch "udevstart" ausfuehren (siehe das oben verlinkte Howto des udev-Packets)

[KBDCALLS]

Poste mal die Ausgaben . Von

lspci -v , ifconfig -a, lsmod , uname -a

Vor update-pciids machen. Bei aktiver Internetverbindung.

Am besten hier http://nopaste.debianforum.de/

Ist Discover installiert? Hotplug installiert ? . Welche Version von Udev ?

[gms]

Die alias-Loesung hat bei mir auch nicht funktioniert. Auch das Eintragen in der richtigen Reihenfolge in der /etc/modules brachte nichts.

Tut mir leid, bei mir funktioniert diese Lösung.
Ich habe sie jetzt auch noch auf einem anderen Rechner erfolgreich getestet. Dabei hatte ich nur kurz das Problem, daß das /etc/modprobe.d Verzeichnis nicht verwendet wird, wenn die /etc/modules.conf existiert.
Auf meinem Laptop, wo ich diese Methode normalerweise benutze, wurden die Interfaces allerdings auch noch nie ungewollt vertauscht. Dort verwende ich diese Methode eigentlich nur aus ästhetischen/historischen Gründen.
Diese Lösung funktioniert allerdings nur, und insofern hat "steff aka sid" absolut recht, wenn die Module nicht direct (/etc/modules, hotplug, modul ist fix im kernel) geladen werden, sondern indirekt über das Starten des Interfaces.

Gruß
gms

[edit]
DIeses Problem sollte eigentlich einfach zu lösen sein, indem man folgende Zeilen am Anfang der /etc/modules einfügt

Code: Alles auswählen

eth0
eth1

Spaßeshabler möchte ich heute abend auch noch testen, ob modprobe mit so einem Konstrukt zurande kommt:

Code: Alles auswählen

alias eth0 <modul1>
alias <modul1> eth0
alias eth1 <modul2>
alias <modul2> eth1

Könnte aber auch passieren, daß dies zu einer Endlosschleife führt


/edit]

[KBDCALLS]

In der modprobe.conf muß als erstes drinnestehen

Code: Alles auswählen

include /etc/modprobe.d

Wird man beim Booten auch drauf gestoßen wenn nicht vorhanden.

[gms]

Habe jetzt obige Tests auf meinem alten Laptop durchgeführt:
Die Methode mit den zwei Aliases

Code: Alles auswählen

alias eth0 <modul1>
alias eth1 <modul2>

definiert in einer Datei /etc/modprobe.d/local, und den beiden Einträgen am Anfang der
/etc/modules

Code: Alles auswählen

eth0
eth1

war stabil. Ich habe sogar nachher das Netwerk gestoppt, die Module entladen und über ihren eigentlichen Namen und in falscher Reihenfolge neu geladen und konnte beide Interfaces wieder korrekt hochfahren.
Bei diesen Tests hatte ich auch diese Module in /etc/hotplug/blacklist.d/local eingetragen, das sollte aber unter dieser Vorraussetzung gar nicht notwendig sein.

Der zweite Test mit diesen Aliases:

Code: Alles auswählen

alias eth0 <modul1> 
alias <modul1> eth0 
alias eth1 <modul2> 
alias <modul2> eth1

hat zwar zuerst ganz gut ausgeschaut. Der zusätzliche Alias verhindert auch das Laden über den Modulnamen:

Code: Alles auswählen

root@gms1:~# lsmod | grep b44
root@gms1:~# modprobe b44
FATAL: Module eth1 not found.
root@gms1:~# modprobe eth1
root@gms1:~# lsmod | grep b44
b44                    22788  0
mii                     5632  1 b44

Dieser Test wurde aber nach einigen modprobe/rmmod und ifup/ifdown Kombinationen instabil.

Ich hoffe das hilft Euch

Grüsse
gms

[Gert Brinkmann]

Warum bekomme ich eigentlich keine Mails mehr, wenn in dem Thread noch Postings dazu kommen? Ich habe die Option bewusst angehakt gelassen...

Ok, aber erstmal Danke fuer die weiteren Bemuehungen um mein Problem an Euch. Ich bin gespannt, was ich noch alles Neues erfahren werde.

@gms

Dabei hatte ich nur kurz das Problem, daß das /etc/modprobe.d Verzeichnis nicht verwendet wird, wenn die /etc/modules.conf existiert.

Darf/Sollte es die nicht mehr geben unter Kernel 2.6.x? Bei mir gibt es die naemlich noch!? Oder meinst Du die modprobe.conf? Die gibt es naemlich hier nicht.

@KBDCALLS

Poste mal die Ausgaben . Von
lspci -v , ifconfig -a, lsmod , uname -a
Vor update-pciids machen.

Ok, habe ich alles gemacht. Die Ausgaben finden sich hier:
http://nopaste.debianforum.de/1689
(Coole Einrichtung, kannte ich noch gar nicht.)
Bin ja mal gespannt, was Du aus dem Kaffeesatz alles lesen kannst. ;)

Ist Discover installiert? Hotplug installiert ? . Welche Version von Udev ?

hotplug ist nach Installation von udev vor relativ kurzem deinstalliert worden. Ich habe es danach auch noch, wie empfohlen, purged.

discover ist noch installiert:

Code: Alles auswählen

ii  discover       2.0.7-2.1
ii  discover-data  2.2005.02.13-1
ii  libdiscover2   2.0.7-2.1

udev:
Installed: 0.074-3

Gruss,

Gert

[KBDCALLS]

Discover kann runter. Hotplug wird ja von Udev bereitgestellt.
Du hast zei Netzwerkkarten was ja klar ist Eine Interne

Code: Alles auswählen

sis900

und eine PCI Karte Realtek8029
Module . sis900 und ne2k_pci

Also müssen die beiden Module in der Richtigen Reihenfolge in die

Code: Alles auswählen

/etc/modules

eingetragen werden.

[Gert Brinkmann]

Das hatte ich so schon versucht.

sis900
ne2k_pci

muss die Reihenfolge lauten, da an dem internen sis900 Device alias eth0 das dsl-modem haengt. Ich hatte diese zwei Zeilen also in die modules.conf eingetragen und dann neu gebootet (um einen ganz sauberen Testfall zu haben) und kam nicht online, da doch wieder eine Vertauschung vorlag. (Das kann man immer ganz gut testen, indem man pppoeconf startet, das dann naemlich das dsl-Modem ploetzlich an eth1 vorfand.)

Mit den udev-rules dagegen funktioniert es bisher jedesmall korrekt.

Kann discover wirklich runter? Es wird ja von xorg empfohlen.

[KBDCALLS]

Ich hab discover runtergeschmissen. , und habe auch xorg laufen. Und wenn hotplug und discover gleichzeitig laufen darf man zwei Configs rumschrauben wenn man bestimmte Module vom Laden ausschließen will.

[KBDCALLS]

Hier noch mal abschliessend, wie ich die udev-Regeln erstellt habe. Es scheint wirklich zu funktionieren:

In "/etc/udev/rules.d" habe ich die Datei "000_gert.rules" erstellt.

Darin steht:

Code: Alles auswählen

KERNEL="eth*", SYSFS{address}="00:0a:e6:ac:f4:a7", NAME="eth0"
KERNEL="eth*", SYSFS{address}="00:00:1c:09:cc:af", NAME="eth1"

Die "address" ermittelt man wie folgt:

Code: Alles auswählen

udevinfo -a -p /sys/class/net/eth0/ | grep address

(Entsprechend fuer eth1)

Gruss,

Gert

Das hab ich mal getstet. Scheint ihn nicht zu kratzen. Habs allerdings mit 3 Karten getestet. Eine 3com, Realtek und Firewire.