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
Hast du eventuell einen Switch in der Verkabelung, der die Pakete nicht weiterleitet?
Benutze ein funktionierendes Gerät zum Aufbau deiner Testumgebung. Am besten du Besorgst dir einen switch mit monitoring-port..
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.
:
Bearbeitet durch User
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.
Ein Howto zu Deinem Projekt wär echt cool! Hab ein de0 Nano hier und nen w5500 Wizard, mit dem ich ähnliches vorhab....
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
Danke für die Information! Hab ich ja auch hier, und würde gerne mitbasteln. Hier unsere kleine Linksammlung: http://vps1001.fra10-vnodes.webhod.de/display_csv.php?file=fpga_links.csv
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.
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.