Hallo zusammen, ich habe ein FPGA Board von Trenz Elektronik (TE0720 mit TE0701 Basisboard) mit einem XILINX Zynq und möchte mir eine Art Ethernet Hub bauen. Mein Ziel ist es im ersten Schritt, mich zwischen zwei Teilnehmer zu hängen und die Daten einfach nur weiter zu reichen. In weiteren Schritten sollen dann noch Loggen der Frames und Manipulation des Datenstroms möglich sein. Ich habe bereits etwas recherchiert und diverse Netzwerk-Sniffer gefunden, die meines Wissens nach aber alle erst auf Schicht 3 (Vermittlung), also auf IP Ebene loggen. Ich möchte aber auch beispielsweise die Check-Summe der Ethernet Frames mitloggen. Soweit ich alles richtig verstanden habe, wird vom MAC jedoch das Ethernet Frame "ausgepackt" und nur der Payload an die folgenden Instanzen weiter gegeben, ist das richtig? Wenn ich also Ethernet (Schicht 1+2) mitloggen möchte, muss ich noch vor dem MAC angreifen. Für die physikalische Anbindung ans Ethernet (PHY) habe ich mir zwei LAN8720 ETH Boards mit RMII Schnittstelle herausgesucht. Wie in der Grafik zu sehen, möchte ich den Datenverkehr durch das FPGA durchschleifen. Meine Frage wäre, wie ich am besten den Controller (siehe Bild) realisieren kann. In diesem Beitrag (Beitrag "Ethernet PHY ansteuern mit FPGA") habe ich gelesen, dass es zwar möglich ist, die Daten einfach wieder über Kreuz an die andere PHY weiterzureichen, es wohl aber eine sehr langsame Verbindung sein soll: "Ich habe gestern für einen Test mal die beiden MII über Kreuz miteinander verbunden. Also TXD an RXD, RX_DV an TX_EN und umgekehrt. Das hat funktioniert, ich konnte mit meinem Laptop anschliessend über dieses Konstrukt ins Netzwerk, aber die Verbindung war ziemlich langsam." Woran könnte das liegen? Die PHYs benutzen ihre eigene Clock, die auch über die RMII Schnittstelle in das FPGA geroutet werden kann. Brauche ich dann für den Controller in der über Kreuz Variante nur einen Synchronizer (wie hier beschrieben http://www.fpga4fun.com/CrossClockDomain1.html) oder muss der Controller komplexer aufgebaut sein, um richtig zu funktionieren? Ich dachte mir, dass man eventuell auch ein Ethernet MAC, welches in VHDL realisiert wurde, benutzen könnte und mir den Teil für die RMII Schnittstelle heraus nehmen. Jedoch finde ich dazu nur Beispiele (z.B. https://github.com/pkerling/ethernet_mac), die mit einer MII Schnittstelle arbeiten. Außerdem werde ich als Anfänger von der Komplexität des Codes erschlagen. Das muss doch auch irgendwie einfacher gehen? Ich möchte einen MAC im Datenstrom-Teil vermeiden, denn er soll im Netzwerk nicht zu erkennen sein (keine MAC-Adresse haben). Nach meinem Verständnis werden die Ethernet Pakete ja an MACs adressiert und mein "MAC-in-the-middle" würde ja dann alle Pakete verwerfen, weil die Pakete ja schließlich nicht an den Logger adressiert werden, ist das richtig? Ich habe da noch einen IP Core gefunden, der in etwa realisiert, wie ich mir das Ganze ungefähr vorstelle: http://www.port.de/fileadmin/user_upload/Dateien_IST_fuer_Migration/Produktbilder/ethernet_hub_e.pdf Was mich wundert ist, dass ich nach langer suche, keinen richtigen Ethernet Sniffer zu Kaufen gefunden habe, der auf der Schicht 2 angreift. Warum gibt es so etwas noch nicht? Ich hoffe, jemand kann mir eine oder alle Fragen beantworten oder eventuell einen besseren Lösungsweg vorschlagen. Gruß woqoman
Angehängte Dateien:
-
Konzept.png
25 KB
Ich habe vor einigen Jahren was mit Ethernet und FPGA gemacht. Der Aufwand war sehr hoch, ich habe 6 Monate gebraucht um von 0 auf einfache Ethernet Pakete zu kommen. Dann wurde ein IP-Core von Altera dazu gekauft, der die viele Arbeit abnahm. Der war allerdings nicht billig. Davon wurden 2 Instanzen erzeugt, mit einem Fifo dazwischen. usw... Es kommt jetzt auf deine VHDL-Kenntnisse an. Bis du erfahren, dann kannst du das ähnlich versuchen. Wird allerdings länger dauern. Bist du ein Anfänger würde ich dir davon abraten. Ich selber würde heute versuchen, dass alles über eine Prozessor abzubilden, weil das einfacher ist. Für eine Paketanalyse benutze ich lieber ein Wireshark auf einem 3ten Rechner der an einen zwischen geschalteten Hub hängt. Da hat man ein GUI mit interaktiver Anzeige.
PittyJ schrieb: > Ich habe vor einigen Jahren was mit Ethernet und FPGA gemacht. Gibt es dazu Sourcen? Würde mir gerne mal ein funktionierendes Projekt anschauen aus diesem Bereich. PittyJ schrieb: > Der Aufwand war sehr hoch, ich habe 6 Monate gebraucht um von 0 auf > einfache Ethernet Pakete zu kommen. Meine Hoffnung ist, dass der Aufwand dadurch geringer wird, dass ich nicht senden und empfangen möchte, sondern lediglich nur weiterleiten und dann im zweiten Schritt loggen. Ich will also keine eigenen Frames erzeugen oder Ähnliches. PittyJ schrieb: > Für eine Paketanalyse benutze ich lieber ein Wireshark auf einem 3ten > Rechner der an einen zwischen geschalteten Hub hängt. Da hat man ein GUI > mit interaktiver Anzeige. Wie zu Anfang beschrieben, reicht mir Wireshark nicht aus, weil ich auf Schicht 2 mitloggen möchte (vor dem MAC).
woqoman schrieb: > Meine Hoffnung ist, dass der Aufwand dadurch geringer wird, dass ich > nicht senden und empfangen möchte, sondern lediglich nur weiterleiten Spaßvogel :-) In dem Moment, wo Du zwei MACs dranhast, hast Du zwei Sender bzw. Empfänger. woqoman schrieb: > "Ich habe gestern für einen Test mal die beiden MII über Kreuz > miteinander verbunden. Also TXD an RXD, RX_DV an TX_EN und umgekehrt. Hast Du das auch schon probiert? Das wäre für mich der erste Schritt. Dann kann man z.B. schon mal mit Chipscope gucken, wie die Daten/Pakete aussehen. Duke
woqoman schrieb: > PittyJ schrieb: >> Für eine Paketanalyse benutze ich lieber ein Wireshark auf einem 3ten >> Rechner der an einen zwischen geschalteten Hub hängt. Da hat man ein GUI >> mit interaktiver Anzeige. > > Wie zu Anfang beschrieben, reicht mir Wireshark nicht aus, weil ich auf > Schicht 2 mitloggen möchte (vor dem MAC). Ich glaube PittyJ meinte einen managebaren Switch zu verwenden, bei dem man 2 Ports als Monitor-Ports konfigurieren kann. Am einen Monitor-Port bekommst Du alles, was auf dem zu überwachenden Port gesendet wird, auf dem anderen alles, was dort empfangen wird. Da bekommst Du alles auf Layer 2 mit. Also ARP-Pakete, LLDP etc. Was möchtest Du denn genau loggen?
woqoman schrieb: > > Mein Ziel ist es im ersten Schritt, mich zwischen zwei Teilnehmer zu > hängen und die Daten einfach nur weiter zu reichen. In weiteren > Schritten sollen dann noch Loggen der Frames und Manipulation des > Datenstroms möglich sein. > Loggen sollte kein Problem sein (hast Du mal den Quellcode von pcap und wireshark angesehen)? Entzeitmanipulationen wirst Du aber nur in sehr rudimentären Protokollen hinbekommen. Wenn Du z.B. einen (unverschlüsselten, verschlüsselt brauchst Du gar nicht erst anfangen) TCP basierten Datenstrom "unsichtbar" verändern willst, musst Du u.A. dafür sorgen, dass die Sequenznummern und alle Checksummen noch stimmen. Wenn das Timing deiner "Box" auch nur gerade so weit auseinander gerät, dass eine Seite ein Retransmission macht, hast Du verloren... > > Ich möchte einen MAC im Datenstrom-Teil vermeiden, denn er soll im > Netzwerk nicht zu erkennen sein (keine MAC-Adresse haben). Nach meinem > Verständnis werden die Ethernet Pakete ja an MACs adressiert und mein > "MAC-in-the-middle" würde ja dann alle Pakete verwerfen, weil die Pakete > ja schließlich nicht an den Logger adressiert werden, ist das richtig? > Ein "transparentes" Dazwischensitzen setzt ein faken der MAC Adresse geradezu voraus, weil viele Router mittlerweile ports an MAC Adressen koppeln, d.h. wenn ein Paket von einer unbekannten MAC kommt, macht der Router den Port zu. Du könntest den PHY deiner Box im "promicuous mode" betreiben (ein Bit im PHY setzen), dann bekommst Du zunächst mal alle Pakete an die höheren Schichten geliefert (also nicht nur dedizierte und Braodcast Pakete). Allerdings musst Du in stark bevölkerten Netzen da einen extrem flinken Prozessor und einem gigiantischen Massenspeicher haben, damit alle Pakete schnell genug durchgeschleust werden (d.h. angesehen, geloggt und ggf. manipuliert). Da ein Netzwerkstack die Start- und Ziel MAC selber in ausgehende Pakete einfügt, ist die Manipulation an der Stelle nicht so schwierig. > > Ich hoffe, jemand kann mir eine oder alle Fragen beantworten oder > eventuell einen besseren Lösungsweg vorschlagen. > Mir ist noch nicht ganz klar, was Du eigentlich vor hast. Willst Du eine Box "zwischen einem wie auch immer zu überwachenden Endgerät und seinem Router" bauen, oder eine Brücke zwischen zwei Routern, die sämtlichen darüber gehenden Datenverkehr zwischen allen Knoten mitschneidet? Was genau willst Du damit machen? Etwas Legales? ;-) > > Gruß woqoman
woqoman schrieb: > Mein Ziel ist es im ersten Schritt, mich zwischen zwei Teilnehmer zu > hängen und die Daten einfach nur weiter zu reichen. In weiteren > Schritten sollen dann noch Loggen der Frames und Manipulation des > Datenstroms möglich sein. Googel mal Stichworte wie Ethernet TAP und Middlebox. > Ich habe bereits etwas recherchiert und diverse Netzwerk-Sniffer > gefunden, die meines Wissens nach aber alle erst auf Schicht 3 > (Vermittlung), also auf IP Ebene loggen. Ich möchte aber auch > beispielsweise die Check-Summe der Ethernet Frames mitloggen. Jein. Der allseits beliebte Wireshark zeigt natürlich auch die L2 FCS, WENN das OS und die drunter liegende Hardware die FCS liefern. Die meisten üblichen OS machen das aber nicht. Eine Ausnahme soll NetBSD sein (nicht selber probiert). Wenn Wireshark eine FCS bekommt sieht das beim aktuellen Wireshark 2.4.1 so aus:
1 | Frame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface 0 |
2 | Ethernet II, Src: Dell_09:7b:ea (00:13:72:09:7b:ea), Dst: IntelCor_11:68:d6 (00:12:f0:11:68:d6) |
3 | Destination: IntelCor_11:68:d6 (00:12:f0:11:68:d6) |
4 | Source: Dell_09:7b:ea (00:13:72:09:7b:ea) |
5 | Type: IPv4 (0x0800) |
6 | Frame check sequence: 0xea7924f6 [correct] |
7 | [FCS Status: Good] |
8 | Internet Protocol Version 4, Src: 192.168.77.7, Dst: 192.168.77.26 |
9 | Internet Control Message Protocol |
> Soweit ich > alles richtig verstanden habe, wird vom MAC jedoch das Ethernet Frame > "ausgepackt" und nur der Payload an die folgenden Instanzen weiter > gegeben, ist das richtig? Das hängt davon ab was der MAC-Layer kann und wie er konfiguriert ist. > Was mich wundert ist, dass ich nach langer suche, keinen richtigen > Ethernet Sniffer zu Kaufen gefunden habe, der auf der Schicht 2 > angreift. Warum gibt es so etwas noch nicht? Es wird nur ein bisschen teurer. Der müsste das können https://www.hilscher.com/products/product-groups/analysis-and-data-acquisition/ethernet-analysis/nanl-b500g-re/ Aber frag zur Sicherheit nach. Andere TAPs müssten es auch können. Der http://www.profitap.com/10gbase-t-tap/ sieht zum Beispiel auf den ersten Blick auch so aus, als ob er das kann.
vielleicht auch ganz interessant: lens is a framework that allows you to tap live cabling for inspection and injection: https://github.com/ervanaLb/Lens Und das Video dazu von der DefCon23 https://www.youtube.com/watch?v=RoOqznZUClI
woqoman schrieb: > Ich dachte mir, dass man eventuell auch ein Ethernet MAC, welches in > VHDL realisiert wurde, benutzen könnte und mir den Teil für die RMII > Schnittstelle heraus nehmen. Jedoch finde ich dazu nur Beispiele (z.B. > https://github.com/pkerling/ethernet_mac), die mit einer MII > Schnittstelle arbeiten. Außerdem werde ich als Anfänger von der > Komplexität des Codes erschlagen. Das muss doch auch irgendwie einfacher > gehen? Zwischen (G)MII und R(G)MII kannst du eine Bridge machen, aber du musst dich mit den DDR-Primitiven deiner Architektur auseinandersetzen. Das ist recht tricky.. Der pkerling-Core ist eine saubere Arbeit, damit machst du schon mal nix falsch. Um die FCS zu loggen, musst du allerdings am rx_fifo herumdrehen. Und für den Sniffer einen "promiscuous mode" einbauen, denn der Core filtert von Haus aus. Ansonsten sollte dein gekreuzter Ansatz tun, funktioniert bei mir zumindest im Loopback-Test. Aber das wird ja ansich erst fürs Paket-Filtern/Forwarden/modifizieren relevant. Der erste Schritt ist schon komplex genug...
:
Bearbeitet durch User
Hannes J. schrieb: > Es wird nur ein bisschen teurer. Der müsste das können > https://www.hilscher.com/products/product-groups/analysis-and-data-acquisition/ethernet-analysis/nanl-b500g-re/ Ja der kann dass :-) Der kann alles mitschneiden was auf der Leitung ist, auch zu kurz geratene Telegramme oder welche mit kaputter FCS. Allerdings nur mit 100MBit, 1GBit kann er nicht, würde so wie dieses Gerät gebaut ist technisch auch nicht funktionieren, da er quasi nur an der Leitung lauscht und nicht dazwischen hängt. Bei Gigabit muss man zwei Macs quasi Rücken an Rücken koppeln. Über den FPGA sollte das doch kein Problem sein, die beiden Datenströme über zwei FIFOs an den jeweils anderen PHY zu schicken...
Hannes J. schrieb: > Es wird nur ein bisschen teurer. Der müsste das können > https://www.hilscher.com/products/product-groups/analysis-and-data-acquisition/ethernet-analysis/nanl-b500g-re/ Hat das Ding nicht die Macke, dass man immer alle Ports raten muss?
woqoman schrieb: > Mein Ziel ist es im ersten Schritt, mich zwischen zwei Teilnehmer zu > hängen und die Daten einfach nur weiter zu reichen. In weiteren > Schritten sollen dann noch Loggen der Frames und Manipulation des > Datenstroms möglich sein. woqoman schrieb: > "Ich habe gestern für einen Test mal die beiden MII über Kreuz > miteinander verbunden. Also TXD an RXD, RX_DV an TX_EN und umgekehrt. > Das hat funktioniert, ich konnte mit meinem Laptop anschliessend über > dieses Konstrukt ins Netzwerk, aber die Verbindung war ziemlich > langsam." > Woran könnte das liegen? Lass erstmal den (FPGA-internen) MAC weg und verbinde beide PHYs über kreuz. Ich kenne jetzt dein Board nicht, aber bei deiner Beschreibung tippe ich mal auf ungünstig gesetzte Registerwerte (10 statt 100 Mb/s), die können von der Beschaltung (such mal nach MODE0/1-Pins am LAN8720A) oder auch von den Initialisierung (per SMII setzen) abhängen. D.h. du musst evtl. noch einen SMII-Controller hinzufügen, der auf 100 FullDuplex schaltet. Damit sollte es dann schneller gehen.
Tim schrieb: > Hannes J. schrieb: >> Es wird nur ein bisschen teurer. Der müsste das können >> > https://www.hilscher.com/products/product-groups/analysis-and-data-acquisition/ethernet-analysis/nanl-b500g-re/ > > Hat das Ding nicht die Macke, dass man immer alle Ports raten muss? Was meinst Du mit Macke? Das was bei dem NANL als "Port" bezeichnet wird kann man eher als Aufzeichnungskanal bezeichnen. Je zwei Aufzeichnungskanäle sind mit je einem der beiden internen TAPs verbunden. Und wenn man an den beiden verdrillten Adernpaaren einer 100 MBit Verbindung lauscht, kann man nicht wissen welches der Paare für welche Richtung benutzt wird. Das machen die beiden Netzwerkpartner beim Verbindungsaufbau normalerweise zufällig untereinander aus. (Autonegotiation) Das ist eben der Nachteil dieser Konstruktionsweise. Der Vorteil davon ist, dass die zusätzliche Verzögerung des Ethernetsignals durch Einschleifen dieses Gerätes im Bereich von wenigen cm Ethernet TP Kabel liegt. Wenn man zwei Ethernet Phy's Rücken an Rücken ankoppelt dann bekommt man was in der Größenordnung von mindestens 400ns, eher us. Das entspricht dann 60m oder mehr Ethernet Kabel, bei manchen Industrieprotokollen ist das schon zu viel.
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.