Hallo Community
Ich bin gerade dabei, etwas mit FPGAs und Ethernet herumzuspielen, da
ich mit beidem noch nichts Grosses gemacht habe.
Ich verwende den MAC+PHY-Chip ENC424J600 über SPI, in der Hoffnung
schneller zu Resultaten zu kommen. Später soll dann die
MAC-Funktionalität ins FPGA integriert werden.
Wie auch immer, ich möchte nun die ein- und ausgehenden Ethernet-Packets
genauer auf deren Inhalt untersuchen. Nach dem ersten Packet musste ich
leider feststellen, dass mein Oszi zu wenig Punkte aufzeichnet, um alle
Daten zu sehen (sehe genau die Präambel).
Auf dem PC (Windows 10) mit Wireshark empfange ich leider keine Packets
(auch im promiskuitiven Modus nicht), wahrscheinlich weil MAC-Adresse
oder CRC nicht stimmt.
Hat jemand einen Tipp für mich, wie ich an die Packete komme?
Freundliche Grüsse,
Markus
Moin,
Ja, die CRC uebers Ethernetpaket muss auf jeden Fall stimmen, wenn das
von einer "normalen" Netzwerkkarte empfangen werden soll.
Stimmt die nicht, taucht das Paket nicht bei Wireshark auf.
Mindestlaenge des Pakets ist auch wichtig, sonst geht's auch schnell
irgendwo verschuett'.
Wenn die Pakete vom FPGA erzeugt werden musst du zwingend irgendwo eine
CRC Berechnung durchfuehren. Am besten eben direkt mit einem
entsprechend verschalteten Haufen XOR Gatter etc.
Beim Empfang der Pakete im FPGA ist's auch nicht verkehrt ebenso zu
verfahren: Mindestlaenge und CRC - sonst ist's kein Paket.
Beim Takteinlauf hab' ich schon Chips gesehen, die's nicht so ganz
streng nehmen, da koennen dann schon mal ein paar Byte fehlen; der SFD
muss halt da sein; danach gehts dann los - aber schoen ist das nicht.
Gruss
WK
Edit: Achja, die MAC Adresse darf auch nicht jeden beliebigen Quatsch
enthalten; also fuer'n Anfang vielleicht mit Broadcast:
ff:ff:ff:ff:ff:ff arbeiten - oder mit einer, von der man sicher weiss,
dass sie gueltig ist.
Danke Euch für die Antworten.
yesitsme schrieb:> Hast du eventuell einen Switch in der Verkabelung, der die Pakete nicht> weiterleitet?
Aktuell habe ich keinen Switch dazwischen. Nur PC <-> FPGA.
Dergute W. schrieb:> Ja, die CRC uebers Ethernetpaket muss auf jeden Fall stimmen, wenn das> von einer "normalen" Netzwerkkarte empfangen werden soll.> Stimmt die nicht, taucht das Paket nicht bei Wireshark auf.> Mindestlaenge des Pakets ist auch wichtig, sonst geht's auch schnell> irgendwo verschuett'.
Na gut, dann muss ich mich, etwas blindlings, zuerst mit dem
beschäftigen.
Wäre vielleicht ein Logic Analyzer mit genug Speicher eine Anschaffung
wert?
Dergute W. schrieb:> Edit: Achja, die MAC Adresse darf auch nicht jeden beliebigen Quatsch> enthalten; also fuer'n Anfang vielleicht mit Broadcast:> ff:ff:ff:ff:ff:ff arbeiten - oder mit einer, von der man sicher weiss,> dass sie gueltig ist.
Werde ich versuchen, danke.
Als nächstes muss ich mir zuerst überlegen, wie ich das in VHDL genau
strukturieren soll, bin da noch etwas ungeübt.
Freundliche Grüsse,
Markus
Moin,
Markus schrieb:> Aktuell habe ich keinen Switch dazwischen. Nur PC <-> FPGA.
Vernuenftig. Wuerd' ich solange beibehalten, bis die Pakete so aussehen,
wie sie sollen.
Markus schrieb:> Wäre vielleicht ein Logic Analyzer mit genug Speicher eine Anschaffung> wert?
Hm. Naja. Also das kriegt man auch so hin. Du kannst dir ja im Wireshark
von "guten" Paketen die Pruefsummen angucken und dann genauso ein Paket
versuchen zu erzeugen. Oder ein komplettes Paket in ein ROM (aus
Blockram) in VHDL schreiben und das dann ausgeben.
Ein ARP Paket ist fuer sowas z.B. eine gute Idee - nicht zu lange
(obacht, muss "gepadded" werden) um die Hexdaten von Hand einzutippern
und der PC versteht's auch noch und antwortet, wenn man alle richtig
gemacht hat.
Markus schrieb:> Als nächstes muss ich mir zuerst überlegen, wie ich das in VHDL genau> strukturieren soll, bin da noch etwas ungeübt.
Zum Senden halt z.B. eine simple Statemaschin', die hintereinander weg
folgendes macht:
Takteinlauf/SFD/Ethernetpaket/CRC/Interpacketgap/Idle...
Gruss
WK
Markus schrieb:> Auf dem PC (Windows 10) mit Wireshark empfange ich leider keine Packets> (auch im promiskuitiven Modus nicht), wahrscheinlich weil MAC-Adresse> oder CRC nicht stimmt.
Schau dir mal die Treibereinstellungen der Netzwerkkarte am PC genau an
und schaltet alle Automatiken, Offloadingfunktionen und ähnliches aus.
Zumindest unter Win 7 konnte man je nach Karte sehr viel einstellen.
Schreib dir aber genau auf was du verstellst, du willst das später
rückgängig machen können da das teilweise viel Performanz im normalen
Betrieb kostet.
Ergänzung: der Chip scheint kein Crossover zu können. Daher
Auto-crossover am PC nicht abstellen und da ich nicht sicher bin ob
beide Seiten das unterstützen müssen zusätzlich mal mit Crossoverkabel
statt Patchkabel testen.
Vielleicht hilft Dir so ein kleiner 8-Kanal LA?
Gibt es eine Beschreibung Deines Projekts? Bin sehr interessiert an Dem
Konzept. Will auch Ethernet Shield an FPGA hängen.
Dergute W. schrieb:> Ja, die CRC uebers Ethernetpaket muss auf jeden Fall stimmen, wenn das> von einer "normalen" Netzwerkkarte empfangen werden soll.> Stimmt die nicht, taucht das Paket nicht bei Wireshark auf.
Wireshark kann durchaus mit FCS' umgehen, auch falschen, wenn es sie
bekommt. Wenn die Netzwerkarte oder deren Treiber Frames mit falscher
FCS weg wirft dann hat Wireshark nichts womit es arbeiten kann.
Beim dem ein oder anderen Betriebssystem, Taps, Switches usw. geht es,
aber Windows ist bekannt dafür, das Frames mit defekter FCS weggeworfen
werden, egal in welchem Mode man captured.
Markus schrieb:> Dergute W. schrieb:>> Ja, die CRC uebers Ethernetpaket muss auf jeden Fall stimmen, wenn das>> von einer "normalen" Netzwerkkarte empfangen werden soll.>> Stimmt die nicht, taucht das Paket nicht bei Wireshark auf.>> Mindestlaenge des Pakets ist auch wichtig, sonst geht's auch schnell>> irgendwo verschuett'.>> Na gut, dann muss ich mich, etwas blindlings, zuerst mit dem> beschäftigen.
Simulier deinen VHDL code, bevor du ihn in den FPGA drückst.
Dann ist das nicht so ein Blindflug.
Einige Ethernet Chipsätze lassen sich in durch einen manuellen Eintrag
in der Windows Registry im "Monitor Mode" betreiben. Dabei werden alle
Checks abgeschaltet und selbst komplett fehlerhafte Pakete sind in
Wireshark sichtbar.
Einfach Mal für deinen Chipsatz googeln.
Warum nicht gleich den SPI-Overhead vermeiden und den ganzen MAC in die
simulation stecken?
Es gibt recht gut designte opensource MAC, wie den von pkerling@github.
Mit Logic Analyzer rumzufrickeln macht hier kaum Sinn ggü dem Vorschlag
Wireshark.
Danke nochmals für die Rückmeldungen.
Blechbieger schrieb:> Schau dir mal die Treibereinstellungen der Netzwerkkarte am PC genau an> und schaltet alle Automatiken, Offloadingfunktionen und ähnliches aus.> Zumindest unter Win 7 konnte man je nach Karte sehr viel einstellen.
Werde ich mal testen.
Blechbieger schrieb:> Ergänzung: der Chip scheint kein Crossover zu können. Daher> Auto-crossover am PC nicht abstellen und da ich nicht sicher bin ob> beide Seiten das unterstützen müssen zusätzlich mal mit Crossoverkabel> statt Patchkabel testen.
Wertvoller Hinweis. Daran habe ich auch kurz gedacht, mich aber nicht
weiter damit beschäftigt, weil ich aus irgendeinem Grund davon
ausgegangen bin, dass der Chip das könne.
Andreas R. schrieb:> Gibt es eine Beschreibung Deines Projekts? Bin sehr interessiert an Dem> Konzept. Will auch Ethernet Shield an FPGA hängen.
Bis jetzt noch nicht. Ist vorerst ein sehr "experimenteller" Aufbau.
Sollte es am Schluss funktionieren, schreibe ich noch einen Bericht
(dann kann ich auch wieder nachschauen, wenn ich mal eine Anwendung
dafür habe).
Christoph Z. schrieb:> Simulier deinen VHDL code, bevor du ihn in den FPGA drückst.>> Dann ist das nicht so ein Blindflug.
Das wäre wahrscheinlich die professionelle Variante. Habe mich da als
Anfänger noch etwas vorm Simulieren gedrückt, aber da sollte ich
vermutlich mal dahinter.
Freundliche Grüsse,
Markus
Danke für die Antworten.
Malle schrieb:> Einige Ethernet Chipsätze lassen sich in durch einen manuellen Eintrag> in der Windows Registry im "Monitor Mode" betreiben. Dabei werden alle> Checks abgeschaltet und selbst komplett fehlerhafte Pakete sind in> Wireshark sichtbar.>> Einfach Mal für deinen Chipsatz googeln.
Es handelt sich um einen USB-Ethernet-Adapter (den billigsten den ich
finden konnte, da nur für diesen Zweck gekauft). Intern werkelt da ein
ASX88772b. Dazu konnte ich leider nichts bezüglich "Monitor mode"
finden.
Strubi schrieb:> Warum nicht gleich den SPI-Overhead vermeiden und den ganzen MAC in die> simulation stecken?
Dass die Verwendung eines Ethernet-Controllers über SPI einen
Flaschenhals darstellt, ist mir klar.
Meine Überlegung war, dass mir der Ethernet-Controller die ganze
MAC-Funktionalität abnimmt und ich so einige Fehlerquellen (Überlegungs-
oder Verständnisfehler der Funktionsweise) ausmerzen kann und ich so
schneller zu einer funktionierenden Lösung komme. Wenn die Übertragung
von Packets läuft, kann ich die MAC-Funktionalität dann ins FPGA
"kopieren".
Wenn ich es gar nicht zum laufen bringen sollte, bleibt aber die
Möglichkeit der kompletten FPGA-Implementierung und somit der Simulation
offen.
Strubi schrieb:> Es gibt recht gut designte opensource MAC, wie den von pkerling@github.> Mit Logic Analyzer rumzufrickeln macht hier kaum Sinn ggü dem Vorschlag> Wireshark.
Danke, werde ich mir ansehen.
Freundliche Grüsse,
Markus
Kurzes Update,
ich kann nun die Packete auf Wireshark empfangen. Ich habe zuvor
fälschlicherweise "LAN-Verbindung" ausgewählt, die aber natürlich gar
nicht besteht. Ich musste zusätzlich diese Library
http://www.win10pcap.org/download/ herunterladen, dass mir die
Schnittstelle "Ethernet" im Wireshark angezeigt wird. Da sehe ich nun
auch alle ein- und ausgehenden Packets.
CRC wird aktuell vom MAC+PHY-Chip erledigt.
Danke für die Unterstützung.
Liebe Grüsse,
Markus.
Hannes J. schrieb:> Wireshark kann durchaus mit FCS' umgehen, auch falschen, wenn es sie> bekommt. Wenn die Netzwerkarte oder deren Treiber Frames mit falscher> FCS weg wirft dann hat Wireshark nichts womit es arbeiten kann.
Das ist das Problem. Am Besten mal geht mit einem Logic Analyzer ran und
scanned was der PHY empfängt und sendet.
Ich habe erst einmal alles simuliert, und mir dabei auch die
CRC-Berechnung angeschaut.
Erst nachdem die Simulation die richtigen Bits anzeigte, bin ich auf die
Leitung gegangen. Dann konnte Wirshark auch das Paket anzeigen.
Simulationen machen kein Spass, man möchte ja gerne etwas live sehen.
Doch interaktives Debuggen, wie beim Prozessor, geht beim FPGA nicht.
Das muß man seine Vorgehensweise ändern. Das mußte ich auch erst lernen.
Markus schrieb:> Christoph Z. schrieb:>> Simulier deinen VHDL code, bevor du ihn in den FPGA drückst.>>>> Dann ist das nicht so ein Blindflug.>> Das wäre wahrscheinlich die professionelle Variante. Habe mich da als> Anfänger noch etwas vorm Simulieren gedrückt, aber da sollte ich> vermutlich mal dahinter.PittyJ schrieb:> Ich habe erst einmal alles simuliert, und mir dabei auch die> CRC-Berechnung angeschaut.> Erst nachdem die Simulation die richtigen Bits anzeigte, bin ich auf die> Leitung gegangen. Dann konnte Wirshark auch das Paket anzeigen.>> Simulationen machen kein Spass, man möchte ja gerne etwas live sehen.> Doch interaktives Debuggen, wie beim Prozessor, geht beim FPGA nicht.> Das muß man seine Vorgehensweise ändern. Das mußte ich auch erst lernen
Eine Simulation nützt hier nix, da der Ethernet MAC/PHY in einem
externen Chip läuft und nicht im VHDL-Code (und wahrscheinlich kein
Simulationsmodell dafür vorhanden ist). Meiner Erfahrung nach sind
Schnittstellen nach extern etwas, was oft viel Zeit beim Debugging
frisst, wenn/weil man es nicht vollständig simulieren kann oder die
Erstellung eines Simulationsmodells recht aufwändig sein kann und auch
wieder fehleranfällig.
VHDL hotline schrieb im Beitrag #5584024:
> die> Erstellung eines Simulationsmodells recht aufwändig sein kann und auch> wieder fehleranfällig.
Da wirst dich damit abfinden müssen, daß Du in bestimmten Situationen um
diesen Aufwand nicht rumkommst.
Wer glaubt, sich das (zumindest bei komplexeren Themen) sparen zu
können, wird ziemlich schnell feststellen, daß dafür u.U. ein mehrfacher
Aufwand in die anschließende Fehlersuche fließt.
VHDL hotline schrieb im Beitrag #5584024:
> Eine Simulation nützt hier nix, da der Ethernet MAC/PHY in einem> externen Chip läuft und nicht im VHDL-Code (und wahrscheinlich kein> Simulationsmodell dafür vorhanden ist). Meiner Erfahrung nach sind> Schnittstellen nach extern etwas, was oft viel Zeit beim Debugging> frisst, wenn/weil man es nicht vollständig simulieren kann oder die> Erstellung eines Simulationsmodells recht aufwändig sein kann und auch> wieder fehleranfällig.
Die Simulation nützt immer was!
Wenn man nicht weiss, wo der Fehler liegt, kann man wenigstens die
einzelnen Schnittstellen verifizieren.
Man muss ja nicht das komplette Simulationsmodell des Chips am Start
haben, meist tut's auch eine einfache verifizierte "working reference"
von der fmf.org-Halde, die man sich auf seine Zwecke anpasst.
Aber um die Unbekannten zu vermeiden, würde ich eben empfehlen, den
ganzen MAC in die Simulation zu stecken. Wenn ARP/ICMP/UDP ausreicht,
hat man da schnell was zusammen und ist nicht durch "Wiznet-Performance"
ausgebremst.
Martin S. schrieb:> Die Simulation nützt immer was!> ...> meist tut's auch eine einfache verifizierte "working reference"
In dem vorliegenden Fall nützt dir die Simulation soviel, dass du deine
SPI-Schnittstelle verifizieren kannst. Da du aber kein Modell des Chips
hast, weißt du nicht, wo es mit den Ethernetpaketen hakt. Eine working
reference im Sinne eines einfachen SPI-Slaves + ETH MAC nützt dir hier
konkret meiner Meinung nach wenig bis nichts.
Um noch etwas zum Thema beizutragen: Als ich Ähnliches gemacht habe,
habe ich als Ergänzung zu Wireshark (packet monitoring) das Programm
Ostinato (packet generation) ganz nützlich empfunden.
https://ostinato.org/
Meiner Meinung nach verkompliziert der externe MAC+PHY eher alles.
Das MII mit einem FPGA einzulesen ist nun wirklich sehr simpel.
Zudem gibt es PHY wie den DPS83640, der nichtmal über MIO konfigurert
werden muss.
Jumüer für 10/100MBit setzen und gut ist.
Ein SPI Protokoll einhalten mit vielen if/else ist nichts für FPGAs.
Das MII Interface gibt dir bei 100MBit mit einem Takt von 25MHz 4 Bit
Nibbles aus. Sowie ein DataValid Signal.
Ist DataValid aktiv, dann darfste die Nibbles einlesen und zu Bytes
zusammenpacken.
Preambel und SFD wegwerfen, danach kommen die interessanten Dinge.
Das MII ist so simpel, dass es auch in der Testbench nachbaubar ist.
Das kann man von dem MAC+PHY jetzt nicht so behapten.
So hab ich in einer Gruppe in der Uni ein "Man In The Middle Attack"
Gerät gebaut.
Das hat sogar in Hardware selbst alle Header bis zum TCP/UDP Header
runter durchsucht und die Matches dann als Busmaster in den RAM des
Softcores gehustet.
Im Anhang mal das "Konzept" nachdem wir die Module aufgeteilt haben zum
VHDl Coden.
Entschuldige, falls ich es überlesen hab, aber welches FPGA Board
verwendest Du nochmal?
Ich sammle gerade FPGA Resourcen, und wollte diesen Thread hinzufügen,
und dort schreibe ich auch dazu, welche FPGA Boards unterstützt werden.
Vielen Dank Euch allen für Eure Anregungen.
Auch ein besonderes Dankeschön für das Hardwarekonzept, das schaue ich
mir sicher an!
Ich werde mich nun in den nächsten Tagen/Wochen mich mit den genannten
Themen (Simulation, Weglassen des MAC-Chips etc.) auseinandersetzen und
mich ggf. nochmals melden, wenn es Neuigkeiten gibt.
Andreas Rückert schrieb:> Entschuldige, falls ich es überlesen hab, aber welches FPGA Board> verwendest Du nochmal?
Ich habe ein DE0-Nano-Board.
Freundliche Grüsse,
Markus
Es hilft ja auch eine CPU draufzusetzen, bzw. kommt man kaum sinnvoll
drumrum, wenn man mindestens einen vernünftigen UDP-Stack implementieren
und den Phy abfragen oder explizit initialisieren will. Was den Phy
angeht: habe auf meinem 'intelligenten PLC' z.B. einen Micrel KSZ8081
drauf, der keine Init. braucht. Bei GigE wird's dann eher knifflig, da
muss man auch bisschen drauf achten, was man sich mit RGMII/GMII an
Layout-Hindernissen einbrockt.
Bei den üblichen Verdächtigen lm32/ublaze/nios2 hat man halt schnell mal
ein Memory-Problem an der Backe, wenn Code und die DMA-Buffer (wenn man
schnell Daten verschicken will) das RAM auffressen. Da greift man
vielleicht besser zur 'lahmen', aber kompakten ZPU, da kriegt man ein
Basis-OS inkl. UDP-Stack+DMA Buffer gut in 40kB rein und verstopft sich
nicht die restliche Logik.
Und was Simulation angeht: Ich habe mir da einfach für den
Referenz-Opensource MAC einen Loopback in der Testbench angelegt, so
liest man das ein, was man gerade verschickt hat. Wenn das mal tut, kann
man sich relativ leicht mit ghdlex/ghdl auch einen virtuellen Peer
basteln und per tun/tap seinen Linux-Client mit der Simulation reden
lassen.
Joar, meine Lösung war dann auch ne ZPU Implementierung, wo es aber noch
an der SDRam Ansteuerung klemmt. Ich wollte nur nen Bootloader ins
Rom(Blockram) tun, und danach das Meiste von SD-Card nachladen.
Der Kollege, der mit mir bastelst, hat eine eigene Risc-CPU
implementiert, welche recht gut aussieht. Das wird auch was werden.
Ich brauch dann ja noch Login am Server usw. Das lässt sich als
Schaltung schlecht kompakt realisieren.
Mit der SD-Lösung kann man den Code auch schön flexibel modifizieren,
ohne dass man am FPGA Projekt was ändern muss. Der SPI Code dafür fehlt
leider noch in unserem Projekt, obwohl ich den schonmal für ein anderes
Projekt geschrieben hatte.
