Hallo,
im Datenblatt des Realtek NIC steht, dass er Ethernet II und IEEE802.3
10Base5, 10Base2 und 10BaseT kann.
Wenn ich nun mein Webboard mit diesem Controller ganz normal zuhause
über RJ45 anstecke, welches Frameformat nutze ich dann?
Bezeichne ich das dann als Ethernet-Protokoll?
Sehe ich es richtig, dass ich dem RTL dann vorher initialisiere und ihm
meine MAC-Adresse mitteile und anschließend ihm IP-Packete übergebe bzw.
von ihm IP-Packete erhalte?
DANKE, Stefanie
Ob Ethernet II (üblich) oder IEEE802.3 (selten) ist dem Realtek völlig
schnuppe. Das ist nicht sein Job, darum kümmert sich die Software.
10base5 (via 15pol AUI-Stecker) und 10base2 (BNC) sind
Anschlusstechniken, die man nur noch im Museum findet.
Der Realtek interessiert sich nur für MAC-Frames. Ob darin TCP/IP oder
IPX steckt, ist ihm egal. Aus IP-Paketen MAC-Frames zu machen ist Sache
der Software.
@Stefanie
es gibt eine recht "plakative" Struktur, welche die verschiedenen
technischen und Bedeutungsebenen beschreibt: Das OSI 7-Schichten-Modell
jeder dieser Schichten ist soweit wie möglich von der vorherigenSchicht
unabhängig, und gegebenenfalls in verschiedenen Varianten Verfügbar.
Wenn man nun die Schichten von oben nach unten durchläuft, dann hast du
z.b:
Ebene_7: Applikation
Ebene_6: Presentation
Ebene_5: Session (Sitzung)
Aus der Anwendung heraus werden Datenströme (beliebiger Art) "Auf die
Reise" in darunter liegende Transportschichten vübergeben. Auf
Session-Ebene ist es "egal" (d.h. muß variabel und identisch sein) wie
Datenpakete ihr Ziel erreichen. Die weiter unten liegeneden
Transportmechanismen wissen auch nicht, was sie da transportieren (soll
denen ja auch egal sein)
Ebene_4: Transport
Auf der Transportebene finden die "Verkehrsregeln" statt, wie ein
Datenpaket von einem Punkt zu einem anderen Punkt zu gehen hat. Die
Verkehrsregeln sind eng gekoppelt mit dem eigentlichen Netzwerkprotokoll
der ebene_3, daher werden beide gerne in einem Stück benannt.
Gängige Transportprotokolle bei "TCP/IP" basierenden Netzen sind TCP
oder UDP. Die alten Novell-Netzwerke kannten dazu alternativ im
Protokollpaket "IPX/SPX" das Transportprotokoll IPX. Sogenannte Router
steuern die Verkehrsflüsse nach definierten Regeln. [analoges Bild im
Transportwesen: "rechts vor links" hat inm Straßenverkehr in
Deutschland = Transportprotokoll TCP eine andere Bedeutung wie links vor
rechts im Straßenverkehr in UK. Beide genutzten Netzwerkarten (Straße)
sind jedoch sehr ähnlich]
Ebene_3: Network
In der Netzwerkebene werden die logischen "Endknoten" der
Kommunikationsverbindung behandelt, die mit Hilfe der Verkehrsregeln der
ebene_4 sinnvoll durch das Netzwerk geleitet werden.
Gängige Netzwerkprotokolle bei "TCP/IP" basierenden Netzen sind IP
(genauer: IPV4) oder demnächst IPV6. Die alten Novell-Netzwerke kannten
dazu alternativ im Protokollpaket "IPX/SPX" das Transportprotokoll SPX
Eine definierte "IP-Adresse" ist. z.B. 172.30.1.1 (sind 4 dezimal
geschriebene Bytes), bei SPX sah eine Netzwerkadresse typisch aus wie
eine Hexadezimal-Adresse, z.B. 1F2B3CAA. [analoges Bild: Telefonnummern
geben auch Endknoten-Adressen an, um z.B. eine Kommunikationsverbindung
von 089-549876 nach 0221-658731 zu "schalten". Was über diese
geschaltete Verbindung transportiert wird (Telefonie, Fax, Bilder) ist
auf dieser Ebene irrelevant]
Ebene_2: DataLink
Her kommen die angefragten Frames zum Zuge. Von der nächst höheren
Ebene_3 empfangene Datenpakete (Egal ob es IPV4, IPV6 oder SPX Pakete
sind) werden "übersetzt" in die Medium-Adresse (MAC). Tpische
MAC-Adressen werden in Hexadezimaler Form geschrieben, gerne so:
3B:4C:00:01:8A:59
Ebene_1: Physikalischer Transport
Hier wird beschrieben, welche Strippen (bei Ethernet z.B: Dickes
Koaxialkabel=10Base5; dünnes Koaxialkabel=10Base2 gemäß Strippenstandard
RG58; Twisted Pair Kabel gemäß StrippenStandard KAT5 oder optische
Lichtleiter) und zugehörige Stecker zu verwenden sind. Auf dieser
Betrachtungsebene sind verwendete hüllende Frameformate vollkommen
unbekannt, d.h. jedes beliebige Frameformat kann sowohl durch eindickes
wie durch ein dünnes Koaxialkabel geschickt werden. Um es elektronisch
zu sagen: Auf dieser Ebene spielen hapuptsächlich Optkoppler und
Treibertransistoren eine Rolle. [Analoges Bild im Transportwesen:
Container könenn per Schiff, LKW oder Zug transportiert werden]
Fazit: Damit dein Webboard einigermaßen verständlich mit einer anderen
Ethernet Komponenten sprechen kann, muß es zumindest einen
"IP-Protokollstack" kennen (also Ebene_3 und Ebene_4 abdecken) und
nutzen wollen (in Ebene_5 und höher).
Darüber hinaus muß es mittels geeigneter Netzwerkchips (z.B. dem
REALtec) Frame-mäßig korrekt (Ebene_2) an ein passendes Netzwerk
angekoppelt sein (Ebene_1)
Vielen herzlichen Dank Wegstaben Verbuchsler Wegstaben Verbuchsler!
Durch dieses ganze Thema incl. Schichtenmodell habe ich mich auch gerade
durchgearbeitet!
Nur ist mir die genaue Aufgabe des Realtec-Bausteins noch nicht so ganz
klar. Mit Hilfe der Software auf dem Mikrocontroller werden IP-Packete
erzeugt.
Nun setzt meiner Meinung nach doch der Realtec das IP-Packet in einen
Ethernet II Frame und schickt es auf die Reise, oder?
Was genau macht denn überhaupt der RTL8019?
"Nun setzt meiner Meinung nach doch der Realtec das IP-Packet in einen
Ethernet II Frame und schickt es auf die Reise, oder?"
Nein. Einzig für die CRC sorgt er selber, ansonsten kriegt der Realtek
fertige MAC-Frames von der Software geliefert. Aus IP-Frames einen
Ethernet-II MAC-Frame herzustellen, ist Sache der Software.
Freilich kann es sein, dass das was du als "IP-Paket" bezeichnest,
bereits ein solcher MAC-Frame ist. Je nach verwendeter TCP/IP-Software.
OK, sorry wenn ich nochmal nerve, aber mit dem Datenblatt kann ich nicht
so recht was anfangen :-(
Die Präample und das SOF macht das der RTL9019AS?
Die Zieladresse hab ich ja vom ARP, die Quelladresse wird doch schon
fest im RTL gespeichert, oder?
Der Reset ist klar. Ach ja, was macht eigentlich der Übertrager genau?
Also mit dem RTL9019AS hatte ich nix zu tun,mir ist der CS8900A
vertrauter.Und der wollte komplette Ethernet-Frames (inklusive der Ziel-
und Quell-MACs) haben und hat lediglich die CRCs in die vollständigen
Frames eingefügt.Diese zu erzeugen ist Teil der Software,weshalb da ein
TCP/IP-Stack oder ein Betriebssystem das selbigen zur Verfügung
stellt,laufen muss.
Der Übertrager dient in 1. Linie nur zum Entkoppeln des Chips vom
Bus.Gerade bei längeren Netzwerkkabeln zum nächsten Hub ist ein
Übertrager unbedingt zu empfehlen.Andererfalls fängt man sich sehr
schwer zu lokalisierende EMV-Probleme im Layout ein.
"die Quelladresse wird doch schon fest im RTL gespeichert, oder?"
Nicht wirklich. Im am Controller angeschlossenen EEPROM ist eine
MAC-Adresse gespeichert, die vom PC-BIOS oder -Treiber ausgelesen und
als MAC-Adresse des Controllers verwendet wird. Ein Microcontrollern mag
das auch so halten, oder verwendet aus Bequemlichkeit eine
Phantasieadresse, oder das EEPROM existiert überhaupt nicht.
In der üblichen Betriebsart (*) überprüft der Controller alle
eingehenden Frames, ob sie ihn überhaupt etwas angehen. Dazu vergleicht
der die Zieladresse eigehender Frames mit (a) Broadcastadresse (b) der
eigenen MAC-Adressen. Das war's aber auch schon hinsichtlich Adressen.
Bei vergesendeten Frames steht das drin, was die Software in den Frame
reinschreibt.
Die in diesem Kontext eingesetzten Ethernet-Controller mögen sich im
Detail der Register unterscheiden, die grundlegende Arbeitsweise ist
jedoch bei allen dem ISA-Bus entstammenden Controllern ziemlich ähnlich.
Nur Controller mit integriertem TCP/IP-Stack, wie beispielsweise W3100,
weichen davon erheblich ab.
*: Es gibt Betriebsart ("promiscuous", die Übersetzung solltest du
lieber selber nachschlagen ;-) in dem er unabhängig von der Adresse alle
eingehenden Frames durchreicht.
