moings…
Nur in soweit als dass es Tatsache ist, dass Linux dem
Ethernetdatenpaket ein Paritätsbit voranstellt. Laut
Datenkapselungsregel sollte (nicht muss) - sodenn es gebraucht
wird - dieses bit hinten angehängt werden.
Zu welchem Zwecke sollte ein Ethernetpaket denn mit einem Paritätsbit
versehen werden???
Zur Validierung hab ich doch schon den CRC-32 drin…
Gehts verloren ist es an sich nicht schlimm, da es auf beiden
seiten weg ist.
Hmm, wenns dann auch noch egal ist, wenn ichs unterwegs verliere,
wozu sollte ich es dann vorher extra anfügen???
Du nimmst 8 Oszilloskope die mittels Induktionszangen je eine
Ader des Netzwerkkabels (Kupfer nicht LWL) abtasten und du
wirst sehen, dass ein Byte 9 bit hat! Nach ner Datenkollision
aber nur mehr 8.
Hmm, kann ich die 8 Oszilloskope auch durch meinen Agilent 1683AD
Logic-Analyzer ersetzen???
Aber so macht der Versuch eh keinen Sinn, der Einfachheit halber
wollen wir uns mal Ethernet 100Base-TX anschauen:
Es werden von unserem Kabel [4-Adernpaare] nur 2 Adernpaare verwendet,
1 Adernpaar zum Senden, das andere zum Empfangen, es genuegt also
völlig, wenn wir uns das Paar zum Senden anschauen, und dabei genuegt
es, wenn wir uns nur eine Ader anschauen. Insofern können wir uns
also mit einem einzigen Oszilloskop begnuegen, aber es muss schon ein
recht fixes sein, nachdem die Daten da mit einer Frequenz von 125 MHz
rumsausen…
Soweit so gut, nun muss ich mir erstmal darüber im Klaren sein, was
ich überhaupt auf der Leitung erwarte. Es wäre illusorisch anzunehmen,
ich könnte auf der Leitung das Datenpaket direkt sehen. Wie man weiß,
oder in einem beliebigen Standardwerk über Ethernet [z.B. Fast Ethernet
von Rich Seifert, oder auch Gigabit Ethernet (ISBN: 0201185539 Buch anschauen) von
Rich Seifert] nachlesen kann, wird bei 100Base-TX das Datenpaket auf
der Leitung mittels der 4B/5B-Codierung codiert; das heißt jedes
Nibble [4-Bit] wird in 5-Bit umgewandelt. Das heißt jedes Byte besteht
aus zwei 5-Bit-Blöcken. Davon rührt auch der 125 MHz Takt auf der
Leitung her. Soweit zur Messung…
Wenn ich jetzt also wissen will, was das gemessene Bitmuster bedeutet
muss ich also zuerst die 5-Bit-Blöcke wieder in 4-Bit-Blöcke umcodieren.
Und dann kann ich mir da mein Ethernetpaket draus zusammenbauen, und
die ersten 7 Byte stellen die Präambel dar, das ist eine „10“ Bitfolge,
danach kommt der Start-of-Frame-Delimiter mit dem Bitmuster „10101011“
was davor ist, ist dem Ethernetcontroller so ziemlich egal.
Und am Ende kommt dann noch die CRC-32-Prüfsumme, nach dieser bricht
der Controller wieder ab, bzw. wartet auf einen neuen SFD…
Soviel mal zum Ethernet…
Warum bei einer Kollision allerdings ein Bit verloren gehen soll, ist
mir dann doch ein Rätsel, andererseits ist das eh egal, weil nach
einer Kollision wird der entsprechende Ethernetframe nicht weiter
bearbeitet und nochmals übertragen. Eine Kollison kann also nichts
mit irgendeiner Datenänderung zu tun haben.
So nu is aber genuch damit. Die Sache ist off Topic.
Mitnichten, das Brett heißt schliesslich „Netzwerke“…
Servutz
Stephan
