Hinweis: Das Forum wird geschlossen! Neue Registrierungen sind nicht mehr möglich!

 Zurück zu Pro-Linux   Foren-Übersicht   FAQ     Suchen    Mitgliederliste
Realtek-Netzwerkkarte, GBit-LAN und 100MBit-Switch

 
Neuen Beitrag schreiben   Auf Beitrag antworten    Pro-Linux Foren-Übersicht -> Netzwerk
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
ronin



Anmeldungsdatum: 30.08.2006
Beiträge: 7

BeitragVerfasst am: 30. Aug 2006 21:30   Titel: Realtek-Netzwerkkarte, GBit-LAN und 100MBit-Switch

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
 
Benutzer-Profile anzeigen Private Nachricht senden

Janka



Anmeldungsdatum: 11.02.2006
Beiträge: 3569

BeitragVerfasst am: 30. Aug 2006 22:37   Titel:

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.
 
Benutzer-Profile anzeigen Private Nachricht senden

ronin



Anmeldungsdatum: 30.08.2006
Beiträge: 7

BeitragVerfasst am: 31. Aug 2006 18:32   Titel:

Hallo und danke für die Antwort.

Janka hat folgendes geschrieben::
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.

Zitat:
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.

Zitat:
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
 
Benutzer-Profile anzeigen Private Nachricht senden

Marco Gerber



Anmeldungsdatum: 26.08.2006
Beiträge: 38
Wohnort: Zürich

BeitragVerfasst am: 31. Aug 2006 19:59   Titel:

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:

ethtool <devicename>
bsp: 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
 
Benutzer-Profile anzeigen Private Nachricht senden

Janka



Anmeldungsdatum: 11.02.2006
Beiträge: 3569

BeitragVerfasst am: 31. Aug 2006 20:45   Titel:

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.
 
Benutzer-Profile anzeigen Private Nachricht senden

ronin



Anmeldungsdatum: 30.08.2006
Beiträge: 7

BeitragVerfasst am: 01. Sep 2006 9:06   Titel:

Hallo,

@Marco Gerber:

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

Hier die Ausgabe von ethtool eth0:

Code:

Rigel:~ # ethtool eth0
Settings for eth0:
   Supported ports: [ TP ]
   Supported link modes:   10baseT/Half 10baseT/Full
               100baseT/Half 100bastT/Full
               1000baseT/Half 1000bastT/Full
   Supports auto-negotiation: Yes
   Advertised link modes:   10baseT/Half 10baseT/Full
               100baseT/Half 100bastT/Full
               1000baseT/Half 1000bastT/Full
   Supports auto-negotiation: Yes
   Speed: 100MBit/s
   Duplex: Full
   Port: Twisted Pair
   PHYAD: 0
   Transceiver: internal
   Auto-negotiation: on
   Supports Wake-on: pumbg
   Wake-on: g
   Current message level: 0x00000033 (51)
   Link detected: 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:
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:
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:

                         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:
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.
 
Benutzer-Profile anzeigen Private Nachricht senden

Janka



Anmeldungsdatum: 11.02.2006
Beiträge: 3569

BeitragVerfasst am: 01. Sep 2006 10:28   Titel:

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:

# 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.
 
Benutzer-Profile anzeigen Private Nachricht senden

ronin



Anmeldungsdatum: 30.08.2006
Beiträge: 7

BeitragVerfasst am: 01. Sep 2006 10:59   Titel:

Hallo,

Janka hat folgendes geschrieben::

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.

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

Code:

# 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:
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:
--- 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
 
Benutzer-Profile anzeigen Private Nachricht senden

ronin



Anmeldungsdatum: 30.08.2006
Beiträge: 7

BeitragVerfasst am: 01. Sep 2006 13:23   Titel:

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.
 
Benutzer-Profile anzeigen Private Nachricht senden

Marco Gerber



Anmeldungsdatum: 26.08.2006
Beiträge: 38
Wohnort: Zürich

BeitragVerfasst am: 01. Sep 2006 13:46   Titel:

ronin hat folgendes geschrieben::

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 hat folgendes geschrieben::

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:

1100: static struct ethtool_ops rtl8169_ethtool_ops = {
...
}


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
 
Benutzer-Profile anzeigen Private Nachricht senden

petameta
prolinux-forum-admin


Anmeldungsdatum: 14.02.2003
Beiträge: 1294

BeitragVerfasst am: 01. Sep 2006 17:28   Titel:

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.
 
Benutzer-Profile anzeigen Private Nachricht senden

Janka



Anmeldungsdatum: 11.02.2006
Beiträge: 3569

BeitragVerfasst am: 01. Sep 2006 20:33   Titel:

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.
 
Benutzer-Profile anzeigen Private Nachricht senden

ronin



Anmeldungsdatum: 30.08.2006
Beiträge: 7

BeitragVerfasst am: 03. Sep 2006 18:34   Titel:

Janka hat folgendes geschrieben::
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
 
Benutzer-Profile anzeigen Private Nachricht senden

Beiträge vom vorherigen Thema anzeigen:   
     Pro-Linux Foren-Übersicht -> Netzwerk Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehen Sie zu:  

Powered by phpBB © phpBB Group
pro_linux Theme © 2004 by Mandaxy