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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.