Toxic Frame auf Netgate SG-2100: 49% und kein Byte weiter

TL;DR

#

Ein Toxic Frame auf der Netgate SG-2100 stoppt Dateiübertragungen über SMB/HTTP. Das Problem liegt in der Hardware des integrierten Marvell 6000 Switch und tritt auf, wenn der LAN-Port der SG-2100 am Switch beteiligt ist – unabhängig von VLAN-Konfiguration, Routing oder Firewall-Regeln. Das spezifische Datenmuster aus toxic.bin triggert den Bug deterministisch (z.B. bei einer bestimmten Datei exakt bei 49%). Wann genau der Bug getriggert wird und welche anderen Datenmuster ebenfalls problematisch sind, ist derzeit unklar. Reproduzierbar mit toxic.bin. Die Datei nontoxic.bin überträgt problemlos. Problem seit mindestens vier Jahren bekannt, keine Lösung gefunden. Workaround: kein Workaround bekannt.

🌙 Die nächtliche Reise beginnt

#

“Wer reitet so spät durch Nacht und Wind?
Es ist der Vater mit seinem Kind
Er hat den Knaben wohl in dem Arm,
Er fasst ihn sicher, er hält ihn warm.”

Das Symptom – exakt 49%, dann Stillstand

#

“Wer reitet so spät durch Netz und Port?
Es ist der Admin mit seinem Support.
Er hält die Datei wohl fest im Arm,
Bei neunundvierzig Prozent wird’s warm.”

Die Datei stdww2.cab (≈195 MB) bricht beim Übertragen über SMB stets an derselben Stelle ab: exakt bei 49 %. Nicht zufällig, nicht lastabhängig – millimetergenau. Das Verhalten ist ebenso über HTTP reproduzierbar (einfacher Test: toxic.bin über HTTP herunterladen). Der Befund: ein sogenannter Toxic Frame – ein spezifisches Datenmuster, das auf der Netgate SG‑2100 (pfSense) nicht über die Switch‑Pfadlogik transportiert wird. Wann genau der Bug getriggert wird und welche anderen Datenmuster ebenfalls problematisch sind, ist derzeit unklar.

“Mein Vater, mein Vater, jetzt fasst er mich an!
Erlkönig hat mir ein Leids getan!”

Rahmenbedingungen und Ausschlussliste

#

• Protokolle: SMB, HTTP – gleicher Effekt
• Topologien: IPsec‑Tunnel und lokal über VLAN‑zu‑VLAN auf dem internen Switch – gleicher Effekt
• VLAN-Konfiguration: Das Problem tritt auch ohne VLAN auf – VLAN-Setup ist nicht die Ursache
• Hardware-Anforderung: Das Problem tritt auf, wenn der LAN-Port der Netgate SG-2100 am integrierten Marvell 6000 Switch beteiligt ist – unabhängig von VLAN-Konfiguration, Routing oder Firewall-Regeln
• Clients/Dateien: andere Dateien gleicher Größe oder Struktur – unauffällig
• Zeit/Last: unabhängig

Die Präzision des Abbruchs spricht gegen klassische MTU‑/Fragmentierungs‑ oder Bandbreitenthemen. Logs bleiben still. Es wirkt nicht wie Rate‑Limit oder DPI‑Block – eher wie ein deterministischer Drop auf einer spezifischen Bitfolge.

“Mein Kunde, was birgst du so bang dein Gesicht?
Siehst, Admin, du den Fehler nicht?
Den Fehler-Frame mit Kron’ und Schweif?"
“Mein Kunde, es ist ein Netzwerk-Greif.”

Reproduktion und Artefakte

#

• Binärdaten: toxic.bin vs. nontoxic.bin

  • toxic.bin: enthält das spezifische toxische Byte-Muster (extrahiert aus stdww2.cab bei 49%) – triggert den Bug deterministisch
  • nontoxic.bin: enthält zufällige Bytes ohne das problematische Muster – diese Datei wird problemlos übertragen, als Vergleichsbasis.

  Testdateien zum Download (HTTP-Links, um den Bug zu triggern):

  • toxic.bin
  • nontoxic.bin

• Checksummen (zum Verifizieren der Testdateien):

# sha256sum toxic.bin
c53442b8ebc2631d4326fb70cdcc62a5c452674ed306d31120235fc180cfd499  toxic.bin
# shasum toxic.bin
528a21bf89c2529122b8bcab429a983263aa5a62  toxic.bin
# md5sum toxic.bin
b5c1a508e7cd741b94d5645d81375fbc  toxic.bin

• Videos: Reproduktionen über SMB und HTTP (siehe Screenshots-Sektion)

Technischer Verdacht

#

Die Tests deuten auf einen Drop im Switch/SoC‑Pfad der SG‑2100 hin (Marvell‑Plattform). Unabhängig vom Protokoll bricht der Fluss ab, sobald das „toxische” Sektor‑/Paketmuster ansteht. Roh‑Dumps (mvneta1.dump, mvneta1-1111.dump) unterstützen die These, dass ein sehr spezifischer Frame nicht übergeben wird. Das Verhalten reproduziert sich VLAN‑intern ohne IPsec – die IPsec‑Kette ist damit als Ursache ausgeschlossen.

Wichtig: Das Problem tritt auch ohne VLAN-Konfiguration auf. Entscheidend ist, dass der LAN-Port der Netgate SG-2100 am integrierten Marvell 6000 Switch beteiligt ist – unabhängig davon, ob VLANs konfiguriert sind oder nicht. Das VLAN-Setup ist nicht die Ursache des Problems.

Hardware-Spezifikationen:

• CPU: Dual-core ARM Cortex-A53
• NIC: Marvell 88E6141 (mvneta-Treiber)
• Affected Interface: mvneta1
• pfSense-Version: 2.7.x
• Switch: Marvell 6000-Switch

Die Extraktion des toxischen Sektors erfolgte mit:

dd if=stdww2.cab bs=1024 skip=99989 count=1 of=toxic.bin

PCAP-Analysen zeigen: Die Übertragung stoppt abrupt ohne FIN/RST, das letzte ACK-Paket wird nie beantwortet, der Frame enthält das toxische Byte-Muster in der Payload. Die PCAP-Dumps (mvneta1.dump, mvneta1-1111.dump) sind in der Screenshots-Sektion verlinkt.

“Den Vater grauset’s; er reitet geschwind,
Er hält in Armen das ächzende Kind;”

Was wurde ausgeschlossen?

#

• VLAN-Konfiguration: Das Problem tritt mit und ohne VLAN auf – VLAN-Setup ist nicht die Ursache
• MTU/PMTUD‑Probleme: fragmentationsrelevante Tests ohne Befund
• Timeout/Rate‑Limit/DPI: keine korrespondierenden Log‑Events
• Datei/Client‑Spezifika: nur die „toxische" Sequenz triggert den Effekt
• Routing/Firewall-Regeln: unabhängig von der Konfiguration

Kritische Erkenntnis: Das Problem liegt in der Hardware des Marvell 6000 Switch, speziell wenn der LAN-Port der Netgate SG-2100 am Switch beteiligt ist. Es ist ein Hardware-bezogener Fehler auf Switch-Ebene, nicht konfigurationsbedingt.

Systematisches Debugging

#

“Ich liebe dich, mich reizt deine schöne Gestalt;
Und bist du nicht willig, so brauch’ ich Gewalt."
“Mein Admin, mein Admin, jetzt fasst er mich an!
Der Toxic Frame hat mir ein Leids getan!”

Die Identifikation des Problems erforderte eine systematische Isolierung jeder Variable. Über mehrere Tage wurden Tests durchgeführt:

• Verschiedene Dateien gleicher Größe → Kein Problem
• Andere Dateien ähnlicher Struktur → Kein Problem
• Dieselbe Datei von verschiedenen Clients → Problem tritt immer auf
• Übertragung über andere Protokolle (HTTP) → Problem tritt immer auf
• Verschiedene Zeiten, verschiedene Lasten → Problem bleibt konstant
• Andere Internetlinks → Problem tritt immer auf
• Andere Firewallhersteller → Kein Problem
• Andere pfSense-Versionen → Problem tritt immer auf
• Parameterisierung der Firewall → Problem tritt immer auf

Die Erkenntnis: Es war nicht das Protokoll, nicht die Netzwerkverbindung im klassischen Sinne, sondern das spezifische Byte-Muster innerhalb der Datei. Mit binären Dumps wurde die Übertragung Byte für Byte analysiert – extrem zeitaufwändig und erfordert tiefes Verständnis der Netzwerk- und Dateisystem-Protokolle.

Ein einzelner Sektor wurde nie übertragen. Nicht verzögert, nicht korrupt, sondern einfach nicht übertragen. Die Verbindung brach exakt an dieser Stelle ab, jedes Mal, ohne Ausnahme.

Warum war das so schwierig zu finden?

#

“Dem Admin grauset’s, er reitet geschwind,
Er hält in Armen das klagende Kind,
Erreicht das Datacenter mit Mühe und Not;
In seinen Armen das Paket war tot.”

Dieses Problem zu debuggen war extrem schwierig, weil:

1. Die Symptome täuschten: Es sah zunächst wie ein typisches Netzwerkproblem aus
2. Die Präzision war ungewöhnlich: Dass ein Problem immer an exakt derselben Byte-Position auftritt, ist in der Netzwerktechnik extrem selten
3. Die Isolierung war komplex: Jede Variable musste systematisch isoliert werden – Protokoll, Route, Zeit, Last, Dateiinhalt
4. Die Reproduzierbarkeit war schwierig: Nicht jeder Sektor verursachte das Problem, sondern nur ein sehr spezifischer
5. Die Transparenz war gering: Standard-Netzwerk-Tools zeigen dieses Detail-Level nicht – binäre Dumps und sektorbasierte Analysen waren erforderlich

Eine entmutigende Entdeckung

#

Bei der Recherche nach ähnlichen Fällen stießen wir auf eine Reddit-Diskussion im r/PFSENSE Subreddit von vor vier Jahren, in der jemand genau dasselbe Problem beschrieben hatte.

“Du feines Paket, so wohlgestalt,
Ich liebe dein Muster – so wohlerhalt’;
Und bist du nicht willig, so brauch’ ich Gewalt.”

Die Beschreibung war praktisch identisch: SMB-Hangs über IPsec, eine Datei, die immer an derselben Stelle abbricht, Tests über verschiedene Protokolle – alles deckte sich mit unseren Beobachtungen. Was jedoch besonders beunruhigend war: Damals wurde keine Lösung gefunden. Die Diskussion endete ohne abschließende Antwort, ohne Fix, ohne Erklärung.

Das bedeutet, dass dieses Problem bereits seit mindestens vier Jahren bekannt sein sollte, aber offenbar nie richtig analysiert oder behoben wurde.

“Mein Vater, mein Vater, jetzt fasst er mich an!
Der Erlkönig – Toxic Frame – hat mir ein Leids getan!”

Die Herausforderung: Kommunikation mit Hersteller/Reseller

#

Wie erklärt man einem Support-Team, das normalerweise mit Standardproblemen zu tun hat, dass ein einzelner, spezifischer Sektor auf Hardware-Ebene nicht übertragen werden kann? Die meisten Support-Mitarbeiter haben noch nie von einem “Toxic Frame” gehört und werden zunächst an Konfigurationsfehler oder Anwenderfehler denken.

Die Dokumentation muss daher umfassen: Binäre Dumps der toxischen Sektoren, Testprotokolle über mehrere Tage, Screenshots, Schritt-für-Schritt-Analyse, PCAP-Dateien und Video-Beweise der reproduzierbaren Fehler. Die Herausforderung liegt nicht nur darin, das Problem zu dokumentieren, sondern auch darin, die Dringlichkeit und technische Komplexität so zu kommunizieren, dass der Hersteller es ernst nimmt.

Für Hersteller/Reseller: Ein detaillierter Bug-Report steht als Bug Report zur Verfügung und kann direkt an den Support weitergeleitet werden.

Für Hersteller/Reseller: reproduzierbare Vorlage

#

• Testdatei: stdww2.cab (195 MB) – Abbruch bei 49 % (Beispiel für das Problem)
• Minimalbeispiel: toxic.bin (Hash s. oben) löst den Drop deterministisch aus; nontoxic.bin funktioniert einwandfrei
• Reproduktion: LAN-Port der Netgate SG-2100 am integrierten Marvell 6000 Switch beteiligt – tritt mit und ohne VLAN-Konfiguration auf, ebenso über IPsec. Einfacher Test: toxic.bin über HTTP herunterladen
• Erwartung: Übertragung ohne Abbruch; Ist‑Zustand: deterministischer Stillstand
• Unklarheiten: Wann genau der Bug getriggert wird und welche anderen Datenmuster ebenfalls problematisch sind, ist derzeit unklar

Wichtig: Das Problem ist nicht VLAN-bezogen. Es tritt auf, sobald der LAN-Port der SG-2100 am integrierten Marvell 6000 Switch beteiligt ist – unabhängig von VLAN-Konfiguration, Routing oder Firewall-Regeln. Die Screenshots zeigen zwar VLAN-Konfigurationen, dies diente jedoch nur zur Isolierung des Problems und ist nicht die Ursache.

Zur Eingrenzung wird empfohlen, den Paketpfad auf der SoC‑Ebene bzw. im Treiber‑Handling des Marvell 6000 Switch-Interfaces nach dieser spezifischen Bit‑/Frame‑Signatur zu prüfen.

“In seinen Armen das Kind war tot."

Der Admin schaudert, er reitet geschwind,
Trägt PCAPs und Checksums gegen den Wind.
Erreicht das Rack mit Müh’ und Not;
Bei neunundvierzig erstarrt der Knot.

Fazit

#

Ein Toxic‑Frame‑Bug ist selten – hier jedoch klar reproduzierbar: ein spezifisches Datenmuster (wie in toxic.bin enthalten) stoppt den Transfer auf der SG‑2100 deterministisch (z.B. bei der Testdatei stdww2.cab exakt bei 49 %). Die Belege (Checksummen, Dumps, reproduzierbare Videos) sind konsistent. Wann genau der Bug getriggert wird und welche anderen Datenmuster ebenfalls problematisch sind, ist derzeit unklar. Bis zur Analyse seitens Hersteller/Reseller empfehlen wir, kritische Transfers über alternative Pfade/Hardware zu routen.

Um das Problem weiter zu verbreiten und betroffene Nutzer zu erreichen, verwenden wir den Hashtag #toxicframe für die Publikation und Kommunikation dieses Hardware-Bugs.

“Und bist du nicht willig, mein Paket allein,
So wechsle die Hardware - dann wird’s wieder fein!”

Screenshots und weitere Ressourcen

#

Screenshots:

• screenshot_1174.png – Die Testumgebung, eine Netgate SG-2100 mit pfSense 2.7.x
• screenshot_1175.png – Die Netzwerkarten sowie VLAN der Hardware
• screenshot_1176.png – Das VLAN-Setup der Hardware
• screenshot_1177.png – Der integrierte Switch der Hardware
• screenshot_1178.png – Die Ports des integrierten Switches
• screenshot_1179.png – VLAN-Setup des Switches
• screenshot_1180.png – Fehlermeldung nach Abbruch der SMB-Verbindung
• screenshot_1181.png – Fehler beim Übertragen des problematischen Sektors via HTTP

PCAP-Dumps:

• mvneta1.dump – Packet-Capture des betroffenen Interfaces
• mvneta1-1111.dump – Weitere Packet-Capture-Analyse

Videos:

• SMB‑Reproduktion – Video-Demonstration des Problems über SMB
• HTTP‑Reproduktion – Video-Demonstration des Problems über HTTP

Das Erlkönig-Gedicht, neue Nachdichtung

#

Wer reitet so spät durch Nacht und Wind?
Es ist der Vater – Admin – mit Kind;
Er hält die Datei wohl fest im Arm,
Bei neunundvierzig wird’s plötzlich warm.

„Mein Vater, mein Vater, siehst du den Schein?
Den Frame mit Krone im Byte-Geflecht?"
„Mein Sohn, mein Sohn, es ist ein Nebelstreif;
Ein Switch im Geäst, nur Netzwerk-Greif."

„Du feines Paket, so wohlgestalt,
Ich liebe dein Muster – so wohlerhalt’;
Und bist du nicht willig, so brauch’ ich Gewalt."

Es plätschert das TCP, der ACK bleibt aus,
Kein FIN, kein RST – nur stummer Graus;
VLAN hin, VLAN her – der LAN-Port bleibt dabei,
Marvell schweigt, mvneta gibt dich nicht frei.

„Mein Vater, mein Vater, jetzt fasst er mich an!
Der Erlkönig – Toxic Frame – hat mir ein Leids getan!"
Der Vater schaudert, er reitet geschwind,
Trägt PCAPs und Checksums gegen den Wind.

Erreicht das Rack mit Müh’ und Not;
Bei neunundvierzig erstarrt der Knot.
Er beugt sich nieder, der Atem stockt:
In seinen Armen das Kind war tot.

Der Admin schaut, der Bugreport kommt,
Der Frame hat gesiegt, der Transfer versagt.
Vier Jahre schon, kein Fix, kein Licht, ich habe keine Macht –
Das Toxic Frame regiert die Nacht.

Wim Bonis ist CTO der Stylite AG und beschäftigt sich schwerpunktmäßig mit Storage und Netzwerktechnik.