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
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)
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.
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...
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...
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.
Konzept.png
(25 KB)
