eth0 und eth1 werden haeufig vertauscht

[Gert Brinkmann]

Scheint ihn nicht zu kratzen.

Aarg. Ich befürchte, Du hast Recht. Bei mir ist es auch noch einmal vorgekommen, dass die devices vertauscht waren, nachdem ich die Rules eingesetzt habe. Allerdings ist es vor der Existenz der Rules andauernd passiert, danach erst einmal, waehrend es ein gutes Dutzend mal funktioniert hat. Vielleicht bringen Sie ja in manchen race-condition-Faellen doch noch etwas?

Gruss,

Gert

[DAS-ICH]

Hi

hatte dasgleiche Prob nur mit drei Netzwerkkarten.
Es lies sich wie oben beschrieben lösen, mit ner kleinen Korrektur

anstatt

KERNEL="eth*"

habe ich

KERNEL=="eth*"

eingegeben. Mir fiel das auf beim vergleichen der anderen rules, da ist das genauso geschrieben, könnte sein das udev deshalb bei manchen diese Sachen ignoriert.

MfG

[KBDCALLS]

Auf einem Rechner läuft bei mir noch zusätzlich eine Sarge mit einigen Backports., Und Kernel 2.6.14 unter anderem. Da hatte ich auch das Problem mir zwei Normalen Netwerkkarten und Firewire. Da hat dann nur noch geholfen alle 4 Module in die Blacklist einzutragen. Das ist sogar von Kernel zu Kernel Unterschiedlich das Verhalten des Hotplugs was die Netzwerkkarten anbetrifft, bei ansonsten gleicher Konfiguration.

[DAS-ICH]

Hi

ich nehm es auch wieder zurück, musste gerade mein System neustarten und oohhh welch überaschung Netzwerkkarten mal wieder falsche reihenfolge, genauso wie meine Soundkarten.

Habe diese zwar in der /etc/modules so eingetragen wie sie geladen werden sollen, klappt mal so mal so.

Diese Probleme fingen bei mir an, als hotplug kommplet von udev abgelöst wurde. Ich muss sagen im Mom ist dieses udev einfach nur Sch...
Denke aber das die Developer das schon noch hinkriegen.

MfG

[gbrinkmann]

Denke aber das die Developer das schon noch hinkriegen.

Ich hatte bei debian den Bug reported. Er wurde geschlossen mit dem Vermerk, dass dies kein Bug sei. Ich sollte die rules erstellen, dafuer sei ja udev da. Ok, man koennte jetzt noch reporten, dass die rules nicht funktionieren.

Vielleicht darf man keine devices mit dem Namen eth0 und eth1 erzeugen, sondern wie in der README ein "lan" und sonstwas. Das habe ich nicht versucht.

[KBDCALLS]

Also es kann noch nicht Sinn machen das man an mehreren Stellen rumschrauben muß. Dann ist irgendwann mal der Punkt erreicht, das es sinnvoller ist sich einen eigenen Kernel zu kompilieren.

Code: Alles auswählen

 Er wurde geschlossen mit dem Vermerk, dass dies kein Bug sei.

Als Begrüngung ist das dürftig.

[gbrinkmann]

sinnvoller ist sich einen eigenen Kernel zu kompilieren

Wuerde das was aendern? Oder meinst Du "einen eigenen Kernel zu schreiben"?

Als Begrüngung ist das dürftig.

Die war schon etwas genauer. Mal schauen, ob ich den Report finde....
Wenn jetzt niemand mein Englisch korrigiert, dann Bitteschoen http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339951

Bin mal gespannt, wann das System an dieser Stelle fuer einen normalen Benutzer wieder handhabbar wird.

[rudra]

Hallo zusammen,

da ich das selbe Problem hatte habe ich mich mal ein wenig dahinter geklemmt. Habe jetzt auch eine Lösung für das Problem zusammengeglaubt. System ist testing.
Also die Regel wie sie von gbrinkmann gepostet wurde habe ich in die schon vorhandene Datei: udev.rules eingetragen. Ich habe nur den Namen geändert, welchen Namen das Interface danach erhalten/hören soll. Da es hierbei Probleme gibt, wenn die Standards "eth0-9" benutzt werden, einfach einen Namen der wahl benutzen. Noch eben die interface-Datei geändert und neu gebootet.
Leider funktioniert es aber immer noch nicht..........habe doch die Adresse richtig eingetragen........aha, siehe da, wenn meine prism54-Karte im iwconfig als noch nicht ready eingetragen ist, besitzt diese eine andere MAC-Adresse als wenn die Firmware geladen ist!? Also in der Regel die MAC-Adresse ohne Firmware eingetragen und nochmal neu gebootet - Schluss endlich wird die Karte mit dem Namen wlan immer, wirklich immer korrekt in das System eingebunden.
Ist ja schon ein Ding, das mit der MAC!? aber naja, jetzt läuft es bei mir
Viel Spaß noch.

[StevenSch]

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="LAN_INT"
KERNEL="eth*", SYSFS{address}=="00:00:1c:09:cc:af", NAME="LAN_EXT"

Die "address" ermittelt man wie folgt:

Code: Alles auswählen

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

(Entsprechend fuer eth1)

Gruss,

Gert

Hatte die gleichen Probleme und das ganze mal auf die schnelle probiert.
Dabei ist mir aufgefallen:
Bei mir funktioniert das nur ohne Fehler mit EINEM = zwischen KERNEL und "eth*".
Der "NAME" darf NICHT eth0, eth1 etc sein und maximal 9 Zeichen lang.
In der Interfaces-Datei muss man dann noch eth0 und eth1 durch die hier in diesem Beispiel vergebenen "LAN_INT" und "LAN_EXT" ersetzen.
Auch iptables-Regeln müssen entsprechend angepasst werden, da im obigen Beispiel LAN_INT komplett eth0 ersetzt.

Ich hab das ganze mit bis zu 4 PCI-LAN-Karten gestestet und es funktionierte stehts einwandfrei.

Grüsse Steven
Edit: Syntax-Fehler im Zitat von Gert berichtigt, ich hoffe das ist i.O.

[gbrinkmann]

Edit: Syntax-Fehler im Zitat von Gert berichtigt, ich hoffe das ist i.O.

Klar ist das in Ordnung. Ich habe da nur eine Frage zu. Du hast ja das

SYSFS{address}="00:...

duch

SYSFS{address}=="00:...

mit Doppelgleichheitszeichen ersetzt. Das habe ich beides hier und da mal gesehen (in diversen Rules), konnte aber nicht finden, welche Bedeutung was davon hat. Wenn das einfache "=" falsch ist, dann ist das Howto "writing_udev_rules" in /usr/share/doc/udev des udev-Packetes inkorrekt.

[gbrinkmann]

Also bei mir funktioniert es auch mit nur einem "=":

Code: Alles auswählen

KERNEL="eth*", SYSFS{address}="00:0a:e6:dd:ee:a7", NAME="ethdsl"
KERNEL="eth*", SYSFS{address}="00:00:1c:09:dd:ee", NAME="ethlan"

Desweiteren muessen alle eth0 Angaben in /etc/network/interfaces durch (in meinem Fall) ethdsl ersetzt werden und eth1 durch ethlan. Dann nur noch in /etc/ppp/peers/dsl-provider in der Zeile
"plugin rp-pppoe.so ethdsl" das entsprechende Interface eintragen.

Danach musste ich in der Firewall noch das device von eth1 auf ethlan umstellen (Benutze "firestarter", wo ich einfach in den Prefs das Interface auswaehlen musste).

(Die Benamsung "eth*" habe ich gewaehlt, um leichter nach "eth" durchs /etc Verzeichnis greppen zu koennen, so dass man alles, was mit Ethernet Interfaces zusammenhaengt, finden zu koennen.)

[miw8el]

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

Genau das wollte ich auch tun, doch dann habe ich das hier in /etc/modprobe.d/aliases reingeschrieben:

Code: Alles auswählen

alias eth0 e100
alias eth1 3c59x
install 3c59x /sbin/modprobe e100; /sbin/modprobe --ignore-install 3c59x

(s. man modprobe.conf)

Nun gehts erst mal. Allein die Reihenfolge in /etc/modules und die alias Definitionen in /etc/modprobe.d/alias anzugeben half nicht, da die Module zu diesem Zeitpunkt wohl bereits geladen sind, ohne die aliases auszuwerten.

Ich hoffe nun, dass es das wirklich war, denn vielleicht ist die Reihenfolge diesmal ja wieder nur zufällig richtig...

gruß,
mi

[KBDCALLS]

Wenn die Angabe der Reihenfolge in der

Code: Alles auswählen

/etc/modules

nicht hilft, dann müßte man sich mal die Initrd ansehen.

[meti]

Warum eigentlich so kompliziert?

Es gibt doch die Möglichkeit das per udev regeln zu lassen indem einfach der PCI-Bus bzw. der Steckplatz als Grundlage verwendet wird.

Beispiel: in der /etc/udev/rules.d/z25-persistent-net-rules
SUBSYSTEM=="net", DRIVERS=="?*", ID=="0000:01:01.1", NAME="eth0"
SUBSYSTEM=="net", DRIVERS=="?*", ID=="0000:02:03.1", NAME="eth1"

Das klappt sogar auf einer Sun Ultra5 mit 2 Sun Happy Meal Netzwerkkarten, die systembedingt die gleiche MAC-Adresse haben.

[gms]

Warum eigentlich so kompliziert?

weil deine Lösung ca 1 Jahr zu spät kommt

Gruß
gms

[meti]

Warum eigentlich so kompliziert?

weil deine Lösung ca 1 Jahr zu spät kommt

Gruß
gms

Ups ... hab ich gar nicht gesehen ...

[altzheimer]

@meti
Danke für den "späten" Tip ! Ich hatte mit meiner Sun Netra und ihren Eigenheiten bei den Netzwerkkarten / Mac-Adressen ewig gekämpft und schon fast aufgegeben.

Gruß
Stephan