Netzwerkkarte ist plötzlich eth1 - eth0 existiert nicht...

Hoi Leutz

Hatte jemand schon mal das Erlebnis , daß die Netzwerkkarte von heut auf morgen nicht mehr eth0 , sondern eth1 ist ?

eth0 existiert nicht .

an  2 13:20:06 hjslfs-1 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Jan  2 13:20:06 hjslfs-1 kernel: TCP cubic registered
Jan  2 13:20:06 hjslfs-1 kernel: NET: Registered protocol family 1
Jan  2 13:20:06 hjslfs-1 kernel: NET: Registered protocol family 17
Jan  2 13:20:06 hjslfs-1 kernel: Using IPI Shortcut mode
Jan  2 13:20:06 hjslfs-1 kernel: input: ImExPS/2 Generic Explorer Mouse as /class/input/input3
Jan  2 13:20:06 hjslfs-1 kernel: VFS: Mounted root (ext2 filesystem) readonly.
Jan  2 13:20:06 hjslfs-1 kernel: Freeing unused kernel memory: 332k freed
Jan  2 13:20:06 hjslfs-1 kernel: sis900.c: v1.08.10 Apr. 2 2006
Jan  2 13:20:06 hjslfs-1 kernel: PCI: Enabling device 0000:00:04.0 (0004 -> 0007)
Jan  2 13:20:06 hjslfs-1 kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
Jan  2 13:20:06 hjslfs-1 kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
Jan  2 13:20:06 hjslfs-1 kernel: 0000:00:04.0: Realtek RTL8201 PHY transceiver found at address 1.
Jan  2 13:20:06 hjslfs-1 kernel: 0000:00:04.0: Using transceiver found at address 1 as default
Jan  2 13:20:06 hjslfs-1 kernel: eth0: SiS 900 PCI Fast Ethernet at 0x9800, IRQ 10, 00:e0:18:a5:3f:ee.
Jan  2 13:20:06 hjslfs-1 kernel: libata version 2.20 loaded.
Jan  2 13:20:06 hjslfs-1 kernel: Linux agpgart interface v0.102 (c) Dave Jones
Jan  2 13:20:06 hjslfs-1 kernel: agpgart: Detected SiS 648 chipset
Jan  2 13:20:06 hjslfs-1 kernel: agpgart: AGP aperture is 64M @ 0xe8000000
Jan  2 13:20:06 hjslfs-1 kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Jan  2 13:20:06 hjslfs-1 kernel: PCI: Unable to reserve mem region #2:8000000@f0000000 for device 0000:01:00.0
Jan  2 13:20:06 hjslfs-1 kernel: nvidiafb: cannot request PCI regions
Jan  2 13:20:06 hjslfs-1 kernel: Netfilter messages via NETLINK v0.30.
Jan  2 13:20:06 hjslfs-1 kernel: nf_conntrack version 0.5.0 (4095 buckets, 32760 max)
Jan  2 13:20:08 hjslfs-1 kernel: eth1: Media Link On 100mbps full-duplex 
Jan  2 13:20:17 hjslfs-1 kernel: fp=OUTPUT:99 a=DROP IN= OUT=eth1 SRC=192.168.0.121 DST=192.168.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=63197 DF PROTO=UDP SPT=32768 DPT=53 LEN=32 
Jan  2 13:20:17 hjslfs-1 kernel: fp=OUTPUT:99 a=DROP IN= OUT=eth1 SRC=192.168.0.121 DST=192.168.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=63199 DF PROTO=UDP SPT=32768 DPT=53 LEN=32 
Jan  2 13:20:17 hjslfs-1 kernel: fp=OUTPUT:99 a=DROP IN= OUT=eth1 SRC=192.168.0.121 DST=192.168.0.1 LEN=57 TOS=0x00 PREC=0x00 TTL=64 ID=63201 DF PROTO=UDP SPT=32768 DPT=53 LEN=37 
Jan  2 13:20:17 hjslfs-1 kernel: fp=OUTPUT:99 a=DROP IN= OUT=eth1 SRC=192.168.0.121 DST=192.168.0.1 LEN=57 TOS=0x00 PREC=0x00 TTL=64 ID=63203 DF PROTO=UDP SPT=32768 DPT=53 LEN=37

Laut log wird aber ja eth0 gefunden - allerdings zeigt /sys/class/net dann eth1 - kein eth0

Der unerfreuliche Block am Ende des Logs liegt wohl an der Firewall - ein iptables clear gestattet Zugriff aufs Netz .

Aber aus welchem Grund wird eth0 plötzlich eth1 ?

HJS

Quote

Original von berndl
Hi,
ich hatte mal so was aehnliches, da hatte ich im BIOS eine 1394/FireWire enabled, danach war aus eth0 auch eth1 geworden. Hast du im BIOS rumgespielt?

Gruss,
berndl

Hab im Bios rumgespielt ... Aber erst danach - 1394 an oder aus macht leider keinen Unterschied

HJS

Quote

Original von heinbloed
Hi,

oder durch eine neue MAC Adresse der Karte eine neue UDEV Rule bekommen ?
Schau dir doch mal das /etc/udev/rules.d/ Verzeichnis an, z.B. z25_persistent-net.rules

Viel Erfolg,
Marc

Warum sollte ne Karte von jetzt auf gleich ne neue MAC Addy bekommen ?

Aber udev war der richtige Ansatz :

# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.


# PCI device 0x8086:0x1019 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:f1:ae:fa:52", NAME="eth0"


# PCI device 0x1039:0x0900 (sis900)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:e0:18:a5:3f:ee", NAME="eth1"

Was unerklärlich bleibt : Die Intelkarte steckt schon seit nem Jahr nicht mehr in der Kiste .
Hab für meine HostCD mit mehreren Karten experimentiert .
Wieso kam die Änderung nicht , als ich die Karte ausgebaut hab ?

HJS

Quote

Original von Andi011

Wäre auch mein Tipp. Siehe u. a. hier.

Gruß

Andi

Display More

Bei mir isses die 70-persistant-net-rules - hab noch ne ältere Version von udev unter lfs rennen

HJS

Quote

Original von pixelpeter
Hallo HJS,

Ich denke auch, dass es eine udev Regel ist, welche die eth0 in eth1 umbenennt.
Hatte mal ein ähnliches Problem unter Debian.

Peter

Display More

Jo - ist mittlerweile erwiesen , daß die grundlegende Ursache in udev liegt .

Mittlerweile ist die Karte wieder eth0 .

Allerdings bleibt schleierhaft , wieso diese Änderung jetzt erfolgt ist .

Zwar kann ich an Datum/Zeit der rules-Datei erkennen , daß sie offensichtlich heute morgen geändert wurde , aber warum find ich nicht raus .

Die erstellenden Scripte schreiten nur zur Tat , wenn eine Änderung da war - sprich neue Karte erkannt .
Das ne Karte ihre MAC Addy ändert , wäre mir neu und die letzte physische Änderung ist n Jahr her ...

HJS

Quote

Original von Lou
hjs: ist das OS Ubuntu?

Nö - LFS mit udev-105

Quote

Fällt mir immer wieder negativ auf bei Hardy/Ibex -> falls du nen Weg wüsstest die udev Regel für immer zu deaktivieren wär ich dankbar. Ich weiss selber wie man das Problem durch editieren der 70-persistent-net.rules behebt, aber sobald du den Disk mal auf anderer HW/MAC bootest fängt der Ärger wieder von vorne an. Unter ETCH zB existiert die Regel so nicht. Wie wird man sie los?

Wie dir die 70-persistent-net.rules im Kopf verraten sollte , ist das erstellende Script die /lib/udev/write_net_rules .
Wenn du die mit nem schlichten "exit 0" versiehst , sollte das Thema erledigt sein .

Eleganter ist es natürlich , den Namen des Zielfiles in dieser /lib/udev/write_net_rules von

RULES_FILE='/etc/udev/rules.d/70-persistent-net.rules'

in beispielsweise

RULES_FILE='/etc/udev/rules.d/70-persistent-net.rules.new'

zu ändern und ne kurze Message auszugeben , wenn etwas geschrieben wurde .

Dann wirste darauf hingewiesen , wenn udev meint , da wäre ne Änderung erforderlich ...

HJS

Quote

Original von Andi011

Genau das scheint aber durchaus möglich zu sein. Ich weiß zwar nicht wie / warum, aber die onboard-NIC meines serves hat dies nach jedem reboot getan. Jedesmal war dadurch ein anderes ethX-device vorhanden...

Ich weiß zwar , daß es möglich ist , die Addy zu ändern - gerne eingesetzt um ins nur durch MAC/WEP gesicherte WLAN einzusteigen , aber warum sollte die Karte das von sich aus erledigen ?

Ist allerdings auch ne Onboard SIS900 Realtek based .

Damit in deinem Fall immer ein eth0 erscheint , mußte nur in /lib/udev/write_net_rules ein rm /etc/udev/rules.d/70-persistent-net.rules einbauen

HJS