Ethernet Frames mit fehlerhafter Prüfsumme erzeugen

Thomas W. schrieb:

Wenn ich die Frames absende, bleint der ifInErrors Zähler bei der Gegenstelle jedoch konstant auf 0.

Hast Du bei der Gegenstelle das RX-Checksum-Offloading abgeschaltet?

Hmmm schrieb:

Hast Du bei der Gegenstelle das RX-Checksum-Offloading abgeschaltet?

Meine "Gegenstelle" ist aktuell eine Siemens SPS (mit integriertem 3-Port Switch), wo ich nichts dahingehend anpassen kann. Später wird es ein managebarer Switch sein dessen Ports ich so abfragen möchte, und zusätzlich auch die Ports der SPS. Nach meinem Verständnis verwirft ein Switch Pakete mit falscher Prüfsumme direkt, ohne sie weiterzuleiten. Und dann sollte der Error-Counter hochzählen.

In Wireshark bekomme ich im Normalfall die Ethernet FCS nicht zu sehen. Bei meinem Test auf dem Raspberry sehe ich in Wireshark zwar die angeblichen 4 Bytes falscher Checksumme, aber ich weiß eben nicht, ob nicht die Hardware doch noch die korrekte Prüfsumme anhängt und somit für die Gegenstelle alles in Ordnung aussieht.

In der MIB steht zu ifInErrors:

"For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character- oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol."

Thomas W. schrieb:

Meine "Gegenstelle" ist aktuell eine Siemens SPS (mit integriertem 3-Port Switch), wo ich nichts dahingehend anpassen kann.

Also kann sowohl der Switch-Baustein als auch der Ethernet-Controller der SPS (sofern er Checksum-Offloading beherrscht und es genutzt wird) verhindern, dass die SPS das Paket überhaupt sieht.

Wie verhält sich der Zähler, wenn Du korrekte Ethernet-Frames, aber falsche IP-Header-Checksums verwendest?

Thomas W. schrieb:

ich weiß eben nicht, ob nicht die Hardware doch noch die korrekte Prüfsumme anhängt

Vielleicht mal mit einer anderen Gegenstelle (z.B. weiterer RPi) testen?

Hmmm schrieb:

Vielleicht mal mit einer anderen Gegenstelle (z.B. weiterer RPi) testen?

Ich habe mir die Frames an einen Windows PC über einen Router geschickt, und die Frames kommen fehlerfrei an. Ich kann sie unter Windows in Wireshark sehen, inkl. der eigentlich falschen 4 Null-Bytes FCS. Unter Windows lassen sich die verworfenen Frames mit netstat -e auch direkt abfragen.

Bedeutet für mich, dass im Raspberry das tx-checksumming doch noch aktiv ist, obwohl ethtool sagt es wäre off. Ist jetzt die Frage, ob das an der Netzwerkschnittstelle des Raspberry liegt, dass das Deaktivieren nicht funktioniert. Bzw. welche Voraussetzungen gegeben sein müssen (Hardware?), damit sich das auch wirklich deaktivieren lässt.

Hmmm schrieb:

Wie verhält sich der Zähler, wenn Du korrekte Ethernet-Frames, aber falsche IP-Header-Checksums verwendest?

Habe ich nicht getestet, weil das Protokoll was hier zum Einsatz kommt und dessen Fehler ich analysieren möchte, auch kein IP verwendet (Profinet). Zum An-/Abwählen der IP Checksum besitzt ethtool einen eigenen Parameter (tx-checksum-ip-generic).

Die FCS ist Teil des Ethernetstandards. Sie wird vom MAC automatisch generiert/überprüft (vergleichbar mit der Parity bei RS232, nur dass sie bei Ethernet Pflicht ist, gibt kein "n").

Bei kaum einem MAC kann man das für TX abschalten (gibt wohl ein paar von Intel die das "können"). Bei RX wird ein fahlerhaftes Paket weggeschmissen und ein Fehlerzähler erhöht. Bei einigen kann man das umstellen, so dass auch kaputte Frames zur Anwendung weitergeleitet werden. Kaputte Frames werden aber durch keinen Switch/Router durchkommen.

Was ethtool angeht: der schwindelt gerne mal ... (bzw der Kartentreiber und ethtool gibt das nur weiter).

Ich würde versuchen, das Signal wirklich zu stören.

Nachtrag: im Gegensatz zu den ganzen anderen Off-load Features ist die FCS-Behandlung bei allen MACs (in Hardware) vorhanden.

Foobar schrieb:

Was ethtool angeht: der schwindelt gerne mal ... (bzw der Kartentreiber und ethtool gibt das nur weiter).

Ist das denn nicht ein Bug der zu melden wäre, wenn es nur in Ausnahmefällen überhaupt funktioniert? Es gibt einige Artikel zu ethtool, die Optionen werden erläutert, aber nicht, dass das nur in Ausnahmefällen funktioniert, auch wenn die Funktion Erfolg zurückmeldet.

Ich würde versuchen, das Signal wirklich zu stören.

Erfahrungen damit? Das müsste dann ja wirklich nur 2-3 Bits kippen lassen, d.h. Störung von ein paar 100 ns bei 100 MBit/s Ethernet. Schirm öffnen, ent-twisten, und dann mit irgendwas stören. Möglichst ohne großen Elektronikaufwand.

Ich glaube, da musst du noch mindestens eine Ebene tiefer gehen.

Es gab vor Jahren mal ein AVR-Projekt, wo jemand UDP-Messages buchstäblich "zu Fuß" zusammensetzt und sendet. Dort hättest du jede Gelegenheit, falsche Prüfsummen zu produzieren. Guck' mal hier:

https://www.modding.kh.ua/a/IgorPlug-UDP%20(AVR)_eng.htm

Wenn offloading abgeschaltet wird, kann der Treiber die Prüfsumme selbst berechnen.
https://stackoverflow.com/questions/723635/how-do-you-send-an-ethernet-frame-with-a-corrupt-fcs

Ich würde versuchen, das Signal wirklich zu stören.

Erfahrungen damit?

Nein. Könntest mit nem langen Kabel anfangen ;-)

Mir fällt gerade noch ein, dass man es evtl hierrüber provozieren könnte: https://en.wikipedia.org/wiki/Duplex_mismatch

Damit solltest du zumindest deine Fehlerzähler checken können.

Foobar schrieb:

Mir fällt gerade noch ein, dass man es evtl hierrüber provozieren könnte: https://en.wikipedia.org/wiki/Duplex_mismatch

Damit solltest du zumindest deine Fehlerzähler checken können.

Das ist interessant, danke. Das ist gerade im industriellen Umfeld wo teils sehr exotische und alte Geräte unterwegs sind, auch durchaus eine mögliche Fehlerquelle. Und vor allem eine die überhaupt nicht auffällt, und man sucht nach Kabeldefekten oder dergleichen. Schreibe ich mir auf jeden Fall mit auf die Checkliste.

Fehlerzähler zählt auf jeden Fall, nach 10 Minuten ifInErrors auf 40 sowie ifOutErrors auf 5.