Realtek-Netzwerkkarte, GBit-LAN und 100MBit-Switch

Post Reply
Message
Author
ronin
Posts: 7
Joined: 30. Aug 2006 20:59

Realtek-Netzwerkkarte, GBit-LAN und 100MBit-Switch

#1 Post by ronin »

Hallo zusammen,

ich habe mir letzte Woche ein Mainboard von DFI, Typ 915GM, gekauft. Es hat den gleichnamigen Chipsatz von Intel, onboard-Grafik, -Sound und GBit-LAN (der LAN-Chip ist ein Realtek RTL-8169). Auf dem Board sitzt ein Celeron-M 360. Das System ist aufs Strom sparen ausgelegt und soll als Server für ein kleines Heim-LAN dienen. Das Betriebssystem ist SuSE 10.1 (das Problem äußert sich aber auch unter Knoppix 3.8 ).

An dem Rechner hängt ein kleiner 5-Port-Switch von Sharkoon. Im Netzwerk sind außer dem Server 3 Rechner (Windows XP / Linux gemischt), die alle GBit-LAN-Netzwerkkarten haben. Leider kann der Switch maximal 100MBit / Full-Duplex. Das ist nicht das Problem; die Geschwindigkeit reicht für meine Zwecke aus und die Netzwerkkarten passen ihren Durchsatz auch alle automatisch an.

Jetzt aber das Problem und die seltsamen Begleiterscheinungen:
- Der Server bekommt zu keinem der Clients eine TCP/IP-Verbindung, die Clients alle untereinander aber schon. Das schließt aus, dass der Switch defekt ist.
- Klemme ich den Switch ab und ersetze ihn nurch ein Cross-Over-Kabel zwischen dem Server und einem der Clients, bekommt der Server eine Verbindung zu diesem Client. Das schließt aus, dass es ein Konfigurationsproblem auf dem Server gibt (Routing oder so).
- Starte ich Windows XP auf dem Server, so klappt die Kommunikation sowohl über Crossover-Kabel als auch über den Switch. Das schließt aus, dass die Onboard-Netzwerkkarte defekt ist oder sich mit dem Switch nicht verträgt.

Meiner Ansicht nach kann es höchstens sein, dass der Betrieb am Switch unter Linux irgendwelche speziellen Einstellungen erfordert, die unter Windows vom Treiber automatisch gesetzt werden.

Hat jemand eine Idee dazu? Falls ja: Danke im Voraus.

Grüße

ronin

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#2 Post by Janka »

Die Auto-Negiogation 10/100/1000MBit versagt bei deinem Server wohl den Dienst. Versuch mal, ob du dir mit ethtool bzw. mii-tool helfen kannst. Ansonsten anderen Switch/andere Netzwerkkarte nehmen.

Evtl. ist auch einfach das eingesetzte Kabel defekt.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

ronin
Posts: 7
Joined: 30. Aug 2006 20:59

#3 Post by ronin »

Hallo und danke für die Antwort.
Janka wrote:Die Auto-Negiogation 10/100/1000MBit versagt bei deinem Server wohl den Dienst. Versuch mal, ob du dir mit ethtool bzw. mii-tool helfen kannst.
mii-tool antwortet mir nur "operation not supported", egal mit welcher Option.

ethtool sagt mir, dass die Bitrate auf 100MBit/s und Vollduplex eingestellt ist - die Auto-Negotiation funktioniert also offenbar.
Ansonsten anderen Switch/andere Netzwerkkarte nehmen.
Die Tatsache, dass es unter Windows funktioniert, sagt mir, dass weder der Switch noch die Netzwerkkarte physisch defekt sind. Deshalb möchte ich kein Geld für neues Equipment ausgeben, bevor alle anderen Möglichkeiten ausgeschöpft sind.
Dazu kommt noch, dass die Netzwerkkarte, um die es geht, onboard ist, d.h. ich werde sie auch nicht einzeln los.
Evtl. ist auch einfach das eingesetzte Kabel defekt.
Wenn das so ist, warum funktioniert es dann unter Windows?
Natürlich habe ich auch andere Kabel probiert, ebenso habe ich dasselbe Kabel an anderen Rechnern ausprobiert. Das es am Kabel liegt, kann ich also mit ziemlicher Sicherheit ausschließen.

Grüße

ronin

Marco Gerber
Posts: 38
Joined: 26. Aug 2006 13:07
Location: Zürich

#4 Post by Marco Gerber »

Guten Tag

ethtool ist Teil des Kernels (net/core/ethtool.c). Es stellt eine Abstraktionsschicht zu den Daten des Treibers von Netzwerkkarten dar. Das Programm (also nicht die erwaehnte Abstraktionsschicht !) "ethtool" arbeitet mittels ioctl mit dem Kernel, um Daten zu lesen und zu schreiben.
Je nachdem, welche Operationen dein NIC Treiber implementiert hat, bekommst du mehr oder weniger Informationen ueber den Zustand deiner Karte.

ethtool kann den link der NIC ermitteln, ebenfalls die Art des Links. Diese Operation sollte in allen verfuegbaren Treibern implementiert sein.

Diese Informationen bekommst du folgendermassen:

Code: Select all

ethtool <devicename>
bsp&#58; ethtool eth0
Diese Informationen postest du hier, damit wir sie analysieren koennen.

Um einen Switch zu benutzen, braucht man keinen speziellen Treiber. Diese Instanzen sind voneinander getrennt. Die NIC muss lediglich die vom Switch angebotenen Betriebsmodi unterstuetzen. Der Treiber seinerseits muss diese Modi dann "betreiben" koennen.


hth

Marco

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#5 Post by Janka »

Unter Windows kann es z.B. deshalb funktionieren, weil dort durch den Treiber Autonegiogation sowie Fullduplex *aus*geschaltet ist, weil dessen Entwickler wissen, dass es mit der unreifen Hardware noch nicht zuverlässig funktioniert.

Bist du sicher, dass du ein gerade durchverbundenes Kabel benutzt, wenn du den Rechner an den Switch anschließt? Manche Switches reagieren etwas allergisch auf Crossover-Kabel.

Letztlich könnte es auch helfen, nach dem Dranstecken des Rechners den Switch einmal aus- und wieder einzuschalten. Das hat schon so manches seltsame Netzwerkproblem behoben.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

ronin
Posts: 7
Joined: 30. Aug 2006 20:59

#6 Post by ronin »

Hallo,

@Marco Gerber:

Du erzählst mir nichts neues, trotzdem danke für die Info.

Hier die Ausgabe von ethtool eth0:

Code: Select all

Rigel&#58;~ # ethtool eth0
Settings for eth0&#58;
	Supported ports&#58; &#91; TP &#93;
	Supported link modes&#58;	10baseT/Half 10baseT/Full
					100baseT/Half 100bastT/Full
					1000baseT/Half 1000bastT/Full
	Supports auto-negotiation&#58; Yes
	Advertised link modes&#58;	10baseT/Half 10baseT/Full
					100baseT/Half 100bastT/Full
					1000baseT/Half 1000bastT/Full
	Supports auto-negotiation&#58; Yes
	Speed&#58; 100MBit/s
	Duplex&#58; Full
	Port&#58; Twisted Pair
	PHYAD&#58; 0
	Transceiver&#58; internal
	Auto-negotiation&#58; on
	Supports Wake-on&#58; pumbg
	Wake-on&#58; g
	Current message level&#58; 0x00000033 &#40;51&#41;
	Link detected&#58; Yes
@Janka:

Deine Theorie zu dem Windows-Treiber könnte stimmen. Allerdings wurde dort in den Eigenschaften der Netzwerkkarte im Grätenmanager bei "Auto-Negotiation" der Wert "enabled" angezeigt. Ich denke, das entspricht auch der Wahrheit, denn wenn ich den Server und einen Client mit einem Gigabit-fähigen Crossover-Kabel verbunden habe, erschien neben dem Tray-Icon der Text "Verbindung hergestellt, 1GBit/s", waren beide aber über den nur 100MBit-fähigen Switch verbunden, stand da "Verbindung hergestellt, 100MBit/s". Also hat die Auto-Negotiation unter Windows wohl funktioniert. Es kann höchstens sein, dass sie hardwaremäßig nicht funktioniert und deshalb vom Windows-Treiber per Software emuliert wird. Ich weiß aber nicht, ob das geht; ist nur eine Vermutung.

Zum Thema Kabel habe ich gestern noch etwas getestet. Der Aufbau dazu war folgender:
  • 1 Switch, 5 Port (davon einer uplink), max. 100MBit/s
  • 1 PC, Hostname Polaris, OS: SuSE 10.1, IP-Adresse 192.168.0.192 (nur zum testen, normalerweise soll er sich die per DHCP vom Server holen), Netzwerkkarte: NVidia CK8S, onboard, GBit-fähig.
  • 1 Notebook, Hostname Deneb, OS: WinXP Pro mit SP 2, IP 192.168.0.2 (zum testen fix, sonst DHCP), NIC: Broadcom NeXtreme Gigabit Ethernet, onboard.
  • 1 Server, Hostname Rigel, OS: SuSE 10.1, IP-Adresse 192.168.0.192 (immer fix), Netzwerkkarte: Realtek RTL-8169, onboard, GBit-fähig.
  • 1x Patch-Kabel CAT5e UTP
  • 2x Patch-Kabel CAT5 STP
  • 1x Patch-Kabel CAT5 UTP
  • 1x Crossover-Kabel ohne Beschriftung
  • 1x Crossover-Kabel CAT5 UTP
Der Versuchsaufbau war nun so:

Code: Select all

Polaris -- Kabel 1 -- SWITCH -- Kabel 2 -- Deneb
Für Kabel 1 und 2 habe ich die oben genannten alle durchprobiert, also jedes mit jedem getestet. Die Crossover-Kabel habe ich dabei jeweils an den Uplink-Port angeschlossen.
Ergebnis: Es funktioniert mit jeder möglichen Kabelkombination, d.h. Polaris und Deneb können sich gegenseitig per ICMP, SSH, SMB, FTP usw. usf. erreichen.

Dann trenne ich Polaris vom Netzwerk und hänge Rigel an das freiwerdende Kabel, alles andere bleibt gleich:

Code: Select all

Rigel -- Kabel 1 -- SWITCH -- Kabel 2 -- Deneb
Merke: Rigel und Polaris haben die gleiche IP, d.h. aus der Sicht von Deneb ändert sich nichts.
Ergebnis:
ping 192.168.0.192 auf Deneb ergibt: "Zeitüberschreitung der Anforderung."
ping 192.168.0.2 auf Rigel ergibt: "Destination host unreachable."

2. Versuchsanordnung:

Code: Select all

                         Rigel 
                         |
                         Kabel 1
                         |
Polaris -- Kabel 2 -- SWITCH -- Kabel 3 -- Deneb
(Soll heißen: Alle 3 hängen am Switch; Polaris kriegt natürlich eine andere IP, also 192.168.0.3)

Ergebnis: Polaris und Deneb "sehen" sich gegenseitig; Rigel sieht keinen von beiden und die beiden sehen jeweils auch Rigel nicht.

Dann habe ich eine andere Versuchsanordnung probiert:

Code: Select all

Rigel -- Crossover-Kabel -- Deneb
Ergebnis: Es funktioniert! Deneb und Rigel "sehen" sich gegenseitig. Warum funktioniert das nicht auch mit dem Switch in der Mitte?

Grüße

ronin

PS: Was mir noch aufgefallen ist: Bei Windows wird ja im Tray ein kleines Icon mit 2 verbundenen Rechnern angezeigt, wenn eine Netzwerk-Verbindung besteht. Bei Traffic leuchtet einer der beiden Rechner in dem Icon hellblau auf.
Wenn ich nun von Rigel aus Deneb anpinge, leuchtet das Traffic-Licht, aber Deneb antwortet nicht auf ping.

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#7 Post by Janka »

Mhm, anscheinend bringt der Switch einiges durcheinander. Switches leiten ja die Pakete nicht einfach an alle Ports weiter (das wäre ein Hub). Ein Switch merkt sich für jeden Port, welche *Ethernet*adresse ihm von dort aus schon mal Pakete geschickt hat. Zielpakete für diese Ethernetadresse werden danach nur noch an diesen Port ausgegeben.

Wenn man umsteckt, sollte man den Switch jedes mal resetten, sonst kommt er durcheinander und man sucht Phantom-Fehler.

Evtl. ist auch die Benutzung des Uplink-Ports eine Problemquelle. Bei manchen Switches sollte an diesem Port ausschließlich ein weiterer Switch angeschlossen werden, kein Rechner, da dieser Port grundsätzlich *alle* Pakete erhält.

Ich tippe aber immer noch auf Probleme mit der Autonegiogation. Stell das probeweise mal mit

Code: Select all

# ethtool -s eth0 autoneg off speed 100
ab. Danach Reset des Switches!

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

ronin
Posts: 7
Joined: 30. Aug 2006 20:59

#8 Post by ronin »

Hallo,
Janka wrote: Evtl. ist auch die Benutzung des Uplink-Ports eine Problemquelle. Bei manchen Switches sollte an diesem Port ausschließlich ein weiterer Switch angeschlossen werden, kein Rechner, da dieser Port grundsätzlich *alle* Pakete erhält.
Den Uplink-Port habe ich ja auch nur bei den Crossover-Kabeln verwendet; die anderen habe ich jeweils an die normalen Ports angeschlossen. Konfigurationen, bei denen kein Uplink-Port verwendet wurde, habe ich also auch getestet; Ergebnis: Es funktioniert nur, solange einer der beiden verbundenen Rechner nicht Rigel ist.
Ich tippe aber immer noch auf Probleme mit der Autonegiogation. Stell das probeweise mal mit

Code: Select all

# ethtool -s eth0 autoneg off speed 100
ab. Danach Reset des Switches!
Den Switch kann man nicht resetten, man kann nur den Stecker ziehen (war ein billiges Teil, hat aber bisher immer einwandfrei funktioniert; wie gesagt: Es geht nur bei Rigel nicht, und auch da nur unter Linux nicht.)

Ich habe es jedenfalls ausprobiert (ethtool so wie von Dir angegeben, dann Switch vom Strom getrennt und wieder angeschlossen).

Ergebnis:

Code: Select all

From 192.168.0.192 icmp_seq=10 Destination Host Unreachable
Interessant ist aber folgende Meldnung nach dem Abbruch von "ping 192.168.0.2":

Code: Select all

--- 192.168.0.2 ping statistics ---
317 packets transmitted, 1 received, +205 errors, 99% packet loss, time 316085ms
rtt min/avg/max/mdev = 1001.327/1001.327/1001.327/0.00 ms, pipe 3
Von 317 Paketen kam also offenbar eines durch. Wie ist das nun wieder möglich?

Grüße

ronin

ronin
Posts: 7
Joined: 30. Aug 2006 20:59

#9 Post by ronin »

Hallo nochmal,

ein Update zu diesem Problem:

Gerade habe ich folgende Seite gefunden:

http://myy.helia.fi/~karte/realtek_8139.html

Dort heißt es, dass die Realtek RTL8139 mit zu vielen Switches inkompatibel ist. Der Autor meint, es helfe manchmal, einen anderen Switch zu nehmen oder einen Hub dazwischen zu schalten.
Unter Linux müsse man entweder per mii-tool oder per Modulparameter media=0x01 die Karte in den 10MBit/Halbduplex-Modus schalten.

Ich habe zwar keine RTL8139, sondern eine RTL8169, habe es aber trotzdem mal ausprobiert und tatsächlich funktioniert es. Es scheint also tatsächlich ein Treiber-Problem zu sein.

Allerdings kann das für mich keine Lösung sein; mit 100MBit hätte ich mich noch zufrieden gegeben, aber wenn 3 Clients ihre Backups im Schneckentempo von 10MBit/Halbduplex durchs Kabel schieben, macht das Ganze keinen Spaß.

Grüße

ronin

PS: Übrigens meinte c't-Redakteur Ernst Ahlers, als ich vorhin über die c't-Hotline mit ihm telefonierte, dass ethtool nur für Intel-NICs gedacht sei und bei meiner Realtek-Karte möglicherweise falsche Daten anzeigt.

Marco Gerber
Posts: 38
Joined: 26. Aug 2006 13:07
Location: Zürich

#10 Post by Marco Gerber »

ronin wrote: Hallo,

@Marco Gerber:

Du erzählst mir nichts neues, trotzdem danke für die Info.
Ja, ich erzaehle es ja auch nicht nur dir, denn sonst wuerden wir per PM kommunizieren.
Ich bin der Ansicht, dass OpenSource Software auch fuer solche Dinge genutzt werden sollte.

ronin wrote: PS: Übrigens meinte c't-Redakteur Ernst Ahlers, als ich vorhin über die c't-Hotline mit ihm telefonierte, dass ethtool nur für Intel-NICs gedacht sei und bei meiner Realtek-Karte möglicherweise falsche Daten anzeigt.
Das ist Bloedsinn. Der Treiber implementiert die Struktur (Version r8169.c: A RealTek RTL-8169 Gigabit Ethernet driver for Linux kernel 2.4.x.) (welcher auch im aktuellen Kernelrelease zu finden ist)

Code: Select all

1100&#58; static struct ethtool_ops rtl8169_ethtool_ops = &#123;
...
&#125;
Damit ist diese Aussage widerlegt.

Zum Rest:
Wenn du programmieren kannst, kannst du dich ja an die Arbeit machen, dieses Problem zu beheben, oder versuchst eben, um diese Parameter herum zu experimentieren und deine Erkenntnisse dann zu veroeffentlichen.


Marco

petameta
prolinux-forum-admin
Posts: 1294
Joined: 14. Feb 2003 13:19

#11 Post by petameta »

Evtl. wäre es das einfachste eine PCI-Netzwerkkarte einzubauen - dann könntest Du nämlich gleich eine mit einem vernünftigen Chipsatz nehmen, dir RTL-Dinger sind Billigware. Auch wenn sie funktionieren erzeigen sie eine relativ hohe CPU-Auslastung.

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#12 Post by Janka »

Hm. Ich hatte dieses Problem noch *nie*, und ich habe schon viele Realtek-Karten etliche verschiedene Switches verbaut. Was ist denn das für ein Ding?

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

ronin
Posts: 7
Joined: 30. Aug 2006 20:59

#13 Post by ronin »

Janka wrote:Hm. Ich hatte dieses Problem noch *nie*, und ich habe schon viele Realtek-Karten etliche verschiedene Switches verbaut. Was ist denn das für ein Ding?
Der Switch ist ein "Luminous Switch" von Sharkoon.
Ein Artikel darüber findet sich hier (aus dem Jahr 2003, etwa zu dieser Zeit habe ich ihn auch gekauft):

http://www.golem.de/0310/28221.html

Ich habe ihn hauptsächlich deshalb gekauft, weil er die Stromversorgung wahlweise über ein Steckernetzteil oder einen USB-Anschluss (nur Strom, keine Daten) beziehen kann (spart ggf. eine Steckdose). Bei meinen ganzen Experimenten zu diesem Thema habe ich ihn aber immer über das Netzteil betrieben.

Das Teil wird anscheinend nicht mehr verkauft, zumindest ist es von der Sharkoon-Webseite verschwunden.

Grüße

ronin

Post Reply