Ethernet-Schnittstelle unter Linux löscht Pakete


0

Ich versuche, einige Ethernet-Frames mit Linux zu erfassen. Einige dieser Pakete / Frames sind ungültig und enthalten beschädigte Daten.

Beispielsweise enthält ein Ethernet-Frame den Typ 0x0800 (IPv4), die folgenden Daten enthalten jedoch nur zufällige Bytes. Darüber hinaus sind die Quell- und Ziel-MAC unbekannt und nicht vorhersehbar.

Um diese Frames zu erhalten, habe ich ein C-Programm geschrieben, das zuerst Raw-Sockets verwendete. Das hat nicht wie erwartet funktioniert, also bin ich zu libpcap gewechselt.

Ich öffne das Ethernet-Gerät im Promiscuous-Modus, um alle Frames zu empfangen und die MAC-seitige Filterung zu verhindern. Das funktioniert gut. Ich kann Frames mit jeder Ziel-MAC-Adresse empfangen.

Jetzt kommen wir zum großen Problem:

Ich sende einen Ethernet-Frame mit zufälligem Ziel und Quell-MAC. Das Feld Typ ist 0x1234 und die Daten sind nur wenige Bytes, sagen wir 0xdeadbeef. Dies wird auf die minimale Nutzlast aufgefüllt. Dieser Frame wird von meinem Programm mit libpcap ganz gut empfangen.

Wenn ich denselben Frame mit einem "bekannten" Ethernet-Feldwert wie 0x0800 sende, wird der Frame gelöscht und kann von meinem Programm nicht empfangen werden.

Die Software läuft auf einer eingebetteten Plattform, einem Altera Cyclone V SoC mit einem STMMAC-Ethernet-Modul. Auf einem normalen PC / Notebook usw. läuft das Programm einwandfrei und kann diese ungültigen IPv4-Frames sogar empfangen.

Um herauszufinden, wo die Pakete abgelegt werden, habe ich mir das angesehen /sy/class/net/eth0/statistics/rx_* Dateien. Es gibt Dateien, die die Anzahl der empfangenen Pakete und Bytes sowie die Anzahl der verworfenen Pakete zählen. Diese Statistiken funktionieren gut mit normalem Ethernet-Verkehr. Das Senden eines ungültigen Frames wie oben beschrieben hat jedoch keine Änderung der Statistik zur Folge. Der Treiber zählt nicht einmal den Zähler für abgelegte Frames hoch. Ich kann das nicht verstehen, da meines Wissens die Statistik der Netzwerkschnittstelle beeinflusst wird, sobald ein Paket von der Hardware empfangen wird. Der Filter- und Auswertungsprozess des Netzwerkstacks sollte nichts damit zu tun haben. Habe ich recht? Daher scheint es mir, dass ein wirklich niedriger Treibercode diese Pakete oder vielleicht sogar die Hardware selbst filtert.

Nochmals: Mit einem normalen PC auf der anderen Seite können die Pakete mit dem von mir geschriebenen Programm empfangen werden.

Das zweite Problem betrifft gültige TCP-Pakete:

Obwohl ich libpcap verwende, das mir unformatierten Datenverkehr bereitstellt, werden empfangene TCP-Pakete zu riesigen Paketen zusammengesetzt, die sogar größer sind als die MTU der empfangenden Netzwerkschnittstelle. Diese Pakete werden normalerweise auch mit einem PC empfangen.

Kann mir jemand helfen? Ich muss rohen Ethernet-Verkehr "wie er ist" unter Linux auf der Altera SoC-FPGA-Plattform empfangen.


Haben Sie versucht, mit wireshark (was auch verwendet libpcap )? Lässt es Frames fallen / liest sie falsch? Wenn dies der Fall ist, ist Ihre Hardware möglicherweise nicht für die Aufgabe geeignet.
AFH

Entschuldigung, ich kann auf diesem Level nicht helfen. Ich habe in der Vergangenheit TCP-Programmierung durchgeführt und verwendet wireshark um den TCP / UDP-Verkehr zu überwachen, aber ich musste mich nicht mit dieser Art von Problem befassen. Ich hoffe jemand anderes kann helfen.
AFH

Ich weiß es noch nicht, aber Linux-Kernel hatten früher die Möglichkeit, Paketfragmente zu ganzen Paketen zusammenzusetzen, bevor sie weitergegeben werden. Vermeidung von Ping-of-Death- und anderen fragmentierungsbasierten Angriffen. Vielleicht sehen Ihre zufälligen Daten für diesen Code wie Fragmente aus, und der Kernel versucht, alles wieder zusammenzusetzen, bevor er das Paket verarbeitet
infixed

Ich habe das überprüft. Das Problem ist, dass das Paket nicht einmal den Kernel-Netzwerkstapel erreicht. Nicht einmal der Low-Level-Hardwaretreiber sieht dieses Paket. Ich habe keine Ahnung, warum es gefiltert wird. Wie ich oben geschrieben habe: Die Netzwerkstatistiken (Empfangsanzahl usw.) ändern sich nicht, obwohl dies vor jeder weiteren Überprüfung erfolgen sollte, sobald ein Paket empfangen wird.
GNA
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.