kein Netzwerk mit RTL8169 (ASUS)

[George Mason]

Hallo zusammen, ich habe Netzwerk-Probleme mit meinem neuen Rechner. Motherboard ist ein ASUS M4A87TD EVO mit Realtek-Chip RTL8111/8168B (s.u.). Die Zuweisung der IP-Adresse funktioniert nur manchmal, meistens jedoch nicht.

Mit DHCP:

dhclient eth0 -v

Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
No DHCPOFFERS received.
Trying recorded lease 192.168.10.70
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.

--- 192.168.10.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

No working leases in persistent database - sleeping.

Manuelle Zuweisung: ifconfig eth0 192.168.10.70 netmask 255.255.255.0 gateway 192.168.10.1

funktioniert auch nicht, es dauert ein paar Sekunden und dann heißt es:

gateway: Unbekannter Rechner

und syslog sagt:

r8169: eth0: link down
eth0: link is not ready

Netzwerkkarte: lspci -vv

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
Subsystem: ASUSTeK Computer Inc. Device 8432
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 28
Region 0: I/O ports at b800
Region 2: Memory at cdfff000 (64-bit, prefetchable)
Region 4: Memory at cdff8000 (64-bit, prefetchable)
Capabilities: (unwichtig)
Kernel driver in use: r8169

Netzwerksystem: /etc/network/interfaces

auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0

auto eth0

# DHCP
# iface eth0 inet dhcp

# Statische IP
# iface eth0 inet static
# address 192.168.10.70
# netmask 255.255.255.0
# gateway 192.168.10.1

Der Kernel: Linux 2.6.32-5-amd64 auf Debian Squeeze

lsmod | grep r8169

r8169 29229 0
mii 3210 1 r8169

1. Es liegt nicht am Netzwerk-Chip, denn DHCP funktioniert auf dem gleichen Rechner unter Windows einwandfrei und jedes Mal.
2. Es liegt nicht am Router, denn alle anderen Rechner im Netzwerk bekommen von diesem Router eine IP-Adresse
3. Auch ein Reset des Routers (trotz Punkt 2) hat nichts gebracht.
4. Die Installation des Pakets firmware-realtek hat nichts gebracht.

Die Suchfunktion fordert auch keine aktuelle Lösung zutage, ebenso Google. Was tun, sprach Zeus?
Bitte nur ernst gemeinte Anfragen

[rendegast]

Manuelle Zuweisung: ifconfig eth0 192.168.10.70 netmask 255.255.255.0 gateway 192.168.10.1
funktioniert auch nicht, es dauert ein paar Sekunden und dann heißt es:
gateway: Unbekannter Rechner

Code: Alles auswählen

ifconfig eth0 192.168.10.70 netmask 255.255.255.0 gw 192.168.10.1

# The primary network interface
allow-hotplug eth0

auto eth0

# DHCP
# iface eth0 inet dhcp

Code: Alles auswählen

# The primary network interface
#allow-hotplug eth0

auto eth0

# DHCP
iface eth0 inet dhcp

Entweder oder, siehe 'man interfaces'.

r8169: eth0: link down
eth0: link is not ready

firmware-realtek installiert?

4. Die Installation des Pakets firmware-realtek hat nichts gebracht.

würde es dennoch lassen:

Code: Alles auswählen

 * Realtek RTL8111D-1/RTL8168D-1 firmware (rtl_nic/rtl8168d-1.fw)
 * Realtek RTL8111D-2/RTL8168D-2 firmware (rtl_nic/rtl8168d-2.fw)

[George Mason]

Danke Dir, rendegast, vielleicht hat es daran (hotplug-Eintrag) ja schon gelegen. Super!

[mR. bluE]

Erinnert mich an mein problem damals http://debianforum.de/forum/viewtopic.p ... ilit=r8169, hatte allerdings RTL8111C und bin dann von dem Treiber RTL8169 zu RTL8168 gewechselt.
Da gabs auch immer seltsame Aussetzer und wie durch Geisterhand gings dann wieder von ganz alleine....
Auf Squeeze bin ich noch nicht gewechselt von daher kann ich dir nicht sagen ob der Treiber im Squeeze Kernel immer noch nicht mit dem Chip funktioniert.

[George Mason]

muss es heute wieder ausprobieren, dann werde ich berichten.

[George Mason]

Also, das Problem besteht nach wie vor, mit dem hotplug-Eintrag hatte es nichts zu tun. Anscheinend sitzt wohl immer noch der falsche Treiber im Kernel..

Edit, das ist vielleicht bescheuert, ich habe gerade unter Windows die Treiber von Hetzner bzw. Realtek auf die Platte gezogen und dann Linux gebootet, zwecks Installation - jetzt geht's mal wieder. Da ich auf der Arbeit bin, habe ich heute keine Zeit mehr, da groß rumzuprobieren. Beim nächsten Mal werde ich weitermachen.

[rendegast]

Nein, der Treiber geht:

# lspci -nnv -s 2:0
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02)
Subsystem: Biostar Microtech Int'l Corp Device [1565:2307]
Flags: bus master, fast devsel, latency 0, IRQ 40
I/O ports at d800
Memory at febff000 (64-bit, non-prefetchable)
Memory at f8ff0000 (64-bit, prefetchable)
Expansion ROM at febc0000 [disabled]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=2 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 27-00-00-00-68-4c-e0-00
Kernel driver in use: r8169

# lspci -nvv -s 2:0
02:00.0 0200: 10ec:8168 (rev 02)
Subsystem: 1565:2307
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 40
Region 0: I/O ports at d800
Region 2: Memory at febff000 (64-bit, non-prefetchable)
Region 4: Memory at f8ff0000 (64-bit, prefetchable)
...

32bit-Kernel 2.6.32-5 und 2.6.37-2, firmware-realtek.
(und vanillas: 2.6.33 - 2.6.37)

[George Mason]

Bei mir 'geht' der Treiber ja auch, manchmal, aber manchmal auch nicht.

Was verrückt ist: Ist der Netzwerkchip mit der Dose im Büro verbunden, funktioniert der Zugriff erst nicht, dann nach mehrmaligem Reboot (um zu gucken, ob es unter Windows klappt - klappt) doch, und dann auch dauerhaft, also auch nach Ein/ausschalten, über Tage. Steht der PC dann im Schulungsraum, klappt die Verbindung fast nie, aber manchmal eben doch. Beide Räume sind mit dem gleichen Router (speedport) verbunden.

An beiden Standorten funktioniert die Verbindung unter Windows einwandfrei, jedes Mal. Es muss doch am Treiber liegen (?).

Übrigens, bei mir läuft ein 64-Bit-Kernel, falls das wichtig ist. Der Treiber dürfte aber in jeden Fall der gleiche sein.

[orcape]

Hi,

auf den Verdacht hin das es überhaupt nichts damit zu tun hat........
Lies Dir das mal durch.

http://debianforum.de/forum/viewtopic.php?f=30&t=127852

Vielleicht funkt bei Dir auch der Network-Manager dazwischen.

Gruss orcape

[rendegast]

Wenn jetzt die manuelle Zuweisung jederzeit problemlos klappt
(mit dem korrigierten Gateway-Parameter)
spricht das für das Funktionieren des Treibers.

Dann gibt es vielleicht nur das Problem mit dhcp:

Listening on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
No DHCPOFFERS received.
Trying recorded lease 192.168.10.70
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.

(Du gast die MAC oben wegge-xxt? oder Treiber-Fehler?)
Vielleicht daran drehen, dhclient.conf ?
Vielleicht ein firmware-Upgrade des speedport?

Vielleicht funkt bei Dir auch der Network-Manager dazwischen.

Mit

Code: Alles auswählen

[allow-hotplug | auto] eth0
iface eth0 inet dhcp

sollte nm das Interface doch in Ruhe lassen.

Andere Idee, 'ipv6.disable=1' versuchen?

[George Mason]

Update: Ich habe den Kernel auf 2.6.38 aktualisiert. Das Problem besteht aber nach wie vor. Ich komme mal wieder nicht in mein Netzwerk rein.

Vielleicht funkt bei Dir auch der Network-Manager dazwischen.

Ein Network-Manager ist nicht installiert.

Wenn jetzt die manuelle Zuweisung jederzeit problemlos klappt
(mit dem korrigierten Gateway-Parameter)
spricht das für das Funktionieren des Treibers.

Nein, das tut es nicht. Wenn er mal wieder seine "Aussetzer" hat, klappt auch die manuelle Zuweisung nicht.

ifconfig eth0 192.168.10.70 netmask 255.255.255.0 gw 192.168.10.1

Es kommt diese Fehlermeldung:
gw: unbekannter Rechner

(Du hast die MAC oben wegge-xxt? oder Treiber-Fehler?)

Ja, habe die MAC selbst aus der Meldung rausgelöscht.

Vielleicht daran drehen, dhclient.conf?

Werde ich hier posten, sobald ich wieder Netz habe. Bin gerade mit dem Express-Gate des ASUS-Boards drin - auch hier funktioniert DHCP.

Vielleicht ein firmware-Upgrade des speedport?

Werde ich prüfen, sobald ich wieder Netz habe. Aber eigentlich tritt das Problem nur unter Linux auf, unter Windows und selbst mit dem ASUS Express-Gate komm ich ja rein. Deswegen jetzt den Router riskieren - da hängen noch ein paar Kollegen mit dran und die haben keine Probleme mit DHCP. Weder unter Mac noch unter Windows. Und ich will morgen in den Urlaub fahren... und jetzt ein Firmware-Upate riskieren...

Andere Idee, 'ipv6.disable=1' versuchen?

Ich habe stattdessen ipv6 mittels /etc/modprobe.d/aliases deaktiviert, ohne Erfolg. Wenn ich mich nicht irre, sollte ipv6 auch nichts mit dem Treiberproblem zu tun haben. Bei Problemen mit DNS oder schlechter Netzwerk-Performance schon eher.

Ich denke eher, dass es nichts mit DHCP zu tun hat - denn auch meine Versuche, die Karte manuell ins Netzwerk einzubinden, schlagen fehl. Ich kann der Karte manuell eine IP-Adresse zuweisen - ifconfig eth0 192.168.10.70 - kein Problem, ich kann anschließend die Karte mit ifconfig sehen, sie hat tatsächlich diese IP-Adresse bekommen - aber diese Zuweisung funktioniert nur scheinbar. Ich kann anschließend nämlich nicht einmal den Router anpingen

ping 192.168.10.1
den Rechner kennt er nicht.

Auch die Zuweisung des Routers als Gateway schlägt fehl:

gw: unbekannter Rechner oder
gateway: unbekannter Rechner

Wenn ich den Router nicht mit Ping erreiche, obwohl die Karte im gleichen Netz hängt (scheinbar), dann kann das Problem eigentlich nicht am DHCP-Client liegen. Ist doch logisch, wenn die Zuweisung manuell nicht klappt, KANN sie gar nicht mit DHCP klappen.

Und wenn der gleiche Rechner mit dem gleichen Netzwerk-Chip unter Windows, sowie diverse Client-Rechner mit Mac und Windows keinerlei Macken zeigen, dann kann es eigentlich auch nicht am Router liegen.

Gehe ich nun Recht in der Annahme, dass es definitiv am Treiber liegen muss?

[George Mason]

Update: ich habe diesen Treiber von der Realtek-Webseite heruntergeladen:

r8168-8.022.00

Dazu die Headers für meine laufenden Kernel installiert. So konnte ich den Treiber entpacken und mit Hilfe des mitgelieferten autorun.sh installieren.

Check old driver and unload it.
rmmod r8169
Build the module and install
[: 48: r8168: unexpected operator
Backup r8169.ko
rename r8169.ko to r8169.bak
Depending module. Please wait.
load module r8168
Completed.

Die Netzwerkkarte funktioniert sofort (ich weiß noch nicht, für wie lange, aber zumindest kann ich jetzt weiterarbeiten).

Damit es beim Booten immer funktioniert, musste ich noch den alten Treiber r8169 in die Datei /etc/modprobe.d/blacklist.conf eintragen um zu verhindern, dass der geladen wird. Anschließend den neuen Treiber r8168 in die /etc/initramfs-tools/modules eintragen und das Image neu erstellen mit

Code: Alles auswählen

update-initramfs -v -u -k `uname -r`

Und schon klappt es beim Booten. Auch mit DHCP Danke an alle, die mitgeholfen haben. Ich warte jetzt ein paar Wochen und markiere diesen Thread dann als 'gelöst', wenn ich sicher bin, dass der Fehler nicht wieder auftritt.

[rendegast]

musste ich noch den alten Treiber r8169 in die Datei /etc/modprobe.d/blacklist.conf eintragen um zu verhindern, dass der geladen wird.

Eigentlich nicht, da:

Backup r8169.ko
rename r8169.ko to r8169.bak
Depending module. Please wait.

Als "r8169.bak" wird es nicht mehr als Modul angesehen,
das "Depending" ('depmod -a') aktualisiert die alias-Tabelle und entfernt Verweise auf r8169.
Du kannst es nachprüfen mit

Code: Alles auswählen

modprobe -c | egrep -i "10ec.*8168|r8169"

(die PCI-Id des Netzwerk-Controllers wird nur noch über r8168 bedient, Verweise auf r8169 existieren nicht mehr)

Anschließend den neuen Treiber r8168 in die /etc/initramfs-tools/modules eintragen und das Image neu erstellen

auch nicht, da der Treiber wegen obigem zur rechten Zeit auch von udev geladen wird.

[George Mason]

Ich weiß nicht. Ohne diese Anpassungen wurde nach dem Neustart tatsächlich wieder das r8169 geladen. Aber schaden kann es nicht, oder?

[rendegast]

Dann hattest Du wohl r8169 in die initrd (initramfs-tools/modules) eingetragen,
so wie jetzt den r8168.
Diese Kopie wurde erst beim Neuerstellen der initrd entfernt.

Aber schaden kann es nicht, oder?

Dazu:

Ohne diese Anpassungen wurde nach dem Neustart tatsächlich wieder das r8169 geladen

Nur daran denken, daß dort dieser separate Treiber steckt.

[mR. bluE]

Also wenn es tatsächlich am Treiber liegt, wie kann man denn dann nen Bug Report schreiben, dass das mal gefixt wird?
Ich mein bei normalen Paketen ist das ja klar, da sehe ich ja die Maintainer über > http://packages.debian.org aber wie finde ich denn die Maintainer für ein Kernel Modul?

[daeron]

Wohin den Bug melden: Eine gute Frage. Ich würde das Paket firmware-realtek vorschlagen, aber es gibt da sogar schon einen möglicherweise passenden: Bug#611954

Ich war schon drauf und dran, den Treiber direkt von Realtek zu installieren, als ich noch auf diesen Thread gestoßen bin, der mir geholfen hat: Rechner stromlos machen, etwas warten (NIC verliert dadurch wohl seine "gemerkte" kaputte Einstellung), wieder anstöpseln. Ich hoffe das bleibt jetzt so...