Unitymedia UDP-Contentfilter bei Unitymedia?

[boba]

Faszinierend. Ich habe deinen Test nachgestellt, und es passiert dasselbe wie bei dir.

Ich erhalte mit tcpdump diese Meldung beim Senden von test-working.bin:

[root@linux2 ~]# tcpdump -n -i ens160 udp port 5678 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes 19:11:06.102649 IP 87.230.18.40.36776 > 10.1.0.5.rrac: UDP, bad length 1476 > 1472

Wenn ich hingegen test-fail.bin sende, erhalte ich nichts. Es scheint auch bei mir herausgefiltert zu werden.
Ein tcpdump parallel beim Senden auf dem Server hingegen zeigt beide Pakete als ausgehend an.

 

[Leseratte10]

Vielen vielen Dank für den Test, dann kann ich ja aufhören bei meinem lokalen Setup oder auf meinem Server den Fehler zu suchen.
Dann schreibe ich mal eine lange lange Mail an den 2nd-Level-Support bei Unitymedia.

 

[boba]

Was ist das denn für ein Protokoll in den Dateien, welche Anwendung generiert das?

 

[Leseratte10]

Das ist ein proprietäres non-Standard-Protokoll was von einer selbstgeschriebenen Anwendung generiert wird. Ich habe jetzt nur die "Nutzdaten" (nach dem Header) entfernt und durch Nullbytes ersetzt, bis auf das letzte Byte was dann den Unterschied macht.

Darf ich fragen, was du für einen Anschluss hast / welchen Router du nutzt? Wenn du zufällig keine Fritzbox sondern was anderes nutzt dann könnte man AVM als "Fehler-Verursacher" ja schonmal ausschließen.

 

[boba]

Ich habe einen 500/25 Anschluss bei Vodafone West (ehemals Unitymedia) und eine providergestellte Fritzbox 6591. Die Empfängermaschine ist über einen Switch an die Fritzbox angeschlossen, wobei sie genau genommen eine virtuelle Maschine ist und der Switch ist der virtuelle esxi-Switch des esxi-Hosts, auf dem sie läuft.
Andere udp Portweiterleitungen auf diese Maschine, z.B. für das Teamspeak voice Protokoll, funktionieren bestens.

Die Firewall beim Empfänger sagt auch eindeutig, dass genau 1 Paket angekommen ist:
Chain IN_dmz_allow (1 references) pkts bytes target prot opt in out source destination 15 900 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW,UNTRACKED 1 1504 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5678 ctstate NEW,UNTRACKED

Egal, wie oft ich test-fail.bin schicke, es bleibt bei 1 Packet. Schicke ich jedoch weitere test-working.bin, erhöht sich der Paketzähler jeweils um genau 1.

Was die Fragmente angeht, da hab ich den tcpdump zu streng aufgerufen, tatsächlich kommen bei test-working.bin 2 Pakete an, eines mit 1472 Bytes Nutzdaten und das zweite mit 4 Bytes Nutzdaten. Bei test-fail.bin kommt kein einziges an. Die Firewall scheint die Pakete nach Rekombination zu zählen.

 

[Leseratte10]

Könntest du noch verifizieren (mit einem tcpdump auf dem Server) ob deine Fritzbox ca. ~30 Sekunden nach Versand des test-fail.bin mit einem ICMP-Fehler antwortet?
Ich erhalte nämlich nach genau 30 Sekunden ein "ICMP ip reassembly time exceeded" von meiner Fritzbox, was dann vermutlich bedeuten würde, dass eins der beiden Stücke auf der Fritzbox ankommt, das andere unterwegs verloren geht, und die Fritzbox dann das Fragment verwirft weil sie das Paket nicht zusammen bauen kann.

 

[tq1199]

Könntest du noch verifizieren (mit einem tcpdump auf dem Server) ob deine Fritzbox ca. ~30 Sekunden nach Versand des test-fail.bin mit einem ICMP-Fehler antwortet?

Bist Du sicher, dass das von deiner FB kommt? Versuch mal auf dem Client (Empfänger) mit z. B.:

sysctl -w net.ipv4.ipfrag_time=10

, ... ob der ICMP-Fehler dann nicht schon nach 10 Sekunden kommt?

 

[Leseratte10]

Habe ich gerade ausprobiert, auch mit dieser Einstellung auf meinem Client kommt der ICMP-Fehler erst nach 30 Sekunden, also wird der wohl tatsächlich von der Fritzbox kommen.

Auf dem Client selber sehe ich ja im Netzwerkdump gar nichts, kein eingehendes Fragment, nichts. Wenn die ICMP-Meldung von meinem Client käme, müsste ich ja sowohl eins der Fragmente als auch die ICMP-Antwort in einem Netzwerkdump sehen.

 

[tq1199]

..., also wird der wohl tatsächlich von der Fritzbox kommen.

OK, dann ist das so, ... denn die 30 Sekunden sind der default Wert für "net.ipv4.ipfrag_time" in Linux. Schon eigenartig, dass die FB das blockt und am Client gar keine Nachricht ankommt.

 

[Leseratte10]

Naja, ich vermute mal, die Fritzbox wird halt alle eingehenden fragmentierten Pakete erstmal zusammenbauen, und dann anhand dem zusammengebauten Paket Firewall-Entscheidungen oder sowas treffen. Die weiteren Fragmente haben ja keine UDP-Header mehr, dann würde die Box ja bei nachfolgenden Paketen gar nicht wissen, wohin damit.
Kurze Recherche heute (habe mich mal eingelesen in IP-Fragmentierung) ergab dass das wohl viele Firewalls tun.

Und wenn dann nicht alle Fragmente an der Box ankommen, wird halt auch gar keine Routing-Entscheidung getroffen.

 

[addicted]

Zeigt das unter v4 und v6 dasselbe Verhalten?

 

[boba]

Das reassembly time exceeded kommt tatsächlich auch bei mir auch nach 30 Sekunden.

95.223.113.999 ist mein unitymedia Anschluss mit 999 verschleiert, also die Fritzbox, und 87.230.18.40 ist der Internet Server, von dem gesendet wurde.

[root@mail ~]# tcpdump -v -n -i venet0:0 host 95.223.113.999 tcpdump: listening on venet0:0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 01:54:12.913393 IP (tos 0x0, ttl 64, id 6109, offset 0, flags [+], proto UDP (17), length 1500) 87.230.18.40.55662 > 95.223.113.999.rrac: UDP, bad length 1476 > 1472 01:54:12.913419 IP (tos 0x0, ttl 64, id 6109, offset 1480, flags [none], proto UDP (17), length 24) 87.230.18.40 > 95.223.113.999: ip-proto-17 01:54:42.243772 IP (tos 0x0, ttl 56, id 6109, offset 0, flags [none], proto ICMP (1), length 56) 95.223.113.999 > 87.230.18.40: ICMP ip reassembly time exceeded, length 36 IP (tos 0x0, ttl 55, id 6109, offset 0, flags [+], proto UDP (17), length 1500) 87.230.18.40.55662 > 95.223.113.999.rrac: UDP, bad length 1476 > 1472 ^C
Das ist die Aufzeichnung des Senders. Beim Empfänger wird kein einziges Paket davon protokolliert, auch kein icmp 30 Sekunden später.

 

[Leseratte10]

Zeigt das unter v4 und v6 dasselbe Verhalten?

Nein.

Ich habe einen IPv4-only-Anschluss von Unitymedia und nutze IPv6 über einen Tunnel von Hurricane Electric, und über IPv6 kommen beide Pakete ganz normal an, wie es sein sollte. Spricht also auch dafür dass nicht die Fritzbox das Problem ist sondern Unitymedia.

Einen Unitymedia-IPv6-Anschluss zum Testen habe ich leider nicht zur Verfügung.

 

[Leseratte10]

Und der Techniker war hier, hat ein bisschen am Verstärker rumgeschraubt und ein paar Werte verändert; das Problem hat sich dadurch aber nicht gelöst - wer hätte es gedacht...

 

[addicted]

Es könnte noch eine Docsis-Eigenart sein, dass z.B. das CMTS oder der PP im Endgerät das Paket verwirft, weil es zufällig irgendeinem Muster ("a0 00 00 0a" an 7.–10. Stelle oder sowas in der Art) entspricht.

Hast Du die Möglichkeit ein anderes Endgerät als die Fritzbox auszuprobieren?
Kann jemand ohne Fritzbox das Verhalten im UM-Netz nachstellen?

 

[Leseratte10]

Ich habe leider kein anderes Endgerät zur Verfügung.
Ich werde das Thema aber auch mal im Vodafone-Forum ( https://www.vodafonekabelforum.de/ ) posten, da tummeln sich ja auch Unitymedia-Kunden seit das jetzt alles zu Vodafone geworden ist, vielleicht hat ja dort noch jemand eine Idee oder eine Möglichkeit, mit einem anderen Endgerät zu testen.

Muster im Paket - theoretisch möglich, halte ich aber für unwahrscheinlich. Der Beginn der Datei ist ja in beiden Fällen identisch, danach kommen eine Menge Nullbytes, und danach nur noch ein einziges Byte, was sich dann in beiden Dateien unterscheidet. Das wäre schon ein merkwürdiges Muster ...

EDIT: Schauen wir mal ob hier noch jemand eine Idee hat: https://www.vodafonekabelforum.de/viewtopic.php?f=52&t=42824

 

[addicted]

Ich bin offen für andere Erklärungen – aber Du hast sogar selbst den Titel "Contentfilter" gewählt und Filter operieren typischerweise auf Mustern

 

[tq1199]

Kurze Recherche heute (habe mich mal eingelesen in IP-Fragmentierung) ergab dass das wohl viele Firewalls tun.

Und wenn dann nicht alle Fragmente an der Box ankommen, wird halt auch gar keine Routing-Entscheidung getroffen.

Bei welchem Internetprovider ist der Internetanschluss mit deinem Server (von dem aus, die Dateien per UDP gesendet werden)? Kann es sein, dass auf dem Weg (im Internet) zwischen Sender und Empfänger, das DF-Flag entfernt wird bzw. Informationen via ICMP zur MTU, geblockt werden? Es ist ja is-providerabhängig, weshalb die 2. Datei nicht ankommt.

Es ist doch so, dass beim senden beider Dateien per UDP, fragmentiert wird. Warum klappt das Zusammenbauen bei der 1. Datei (die kommt ja beim Client an) und bei der 2. Datei (die kommt nicht an) klappt das Zusammenbauen ja anscheinend nicht?

 

[Leseratte10]

Habe mehrere getestet. Ursprünglich aufgefallen ist der Fehler, als die Pakete von einem Server bei Hetzner gesendet wurden, ich habe aber auch testweise mal von einem Server bei servdiscount.com aus gesendet.

Müsste dann schon bei drei verschiedenen Internetprovidern auftreten (Hetzner, servdiscount, und der ISP vom Server mit dem @boba getestet hat) ...

Der Zusammenbau klappt anscheinend ja nicht weil eins der Fragmente nicht ankommt. Die Fritzbox antwortet ja mit "ICMP ip reassembly time exceeded", das heißt, die Fritzbox weiß, dass sie eigentlich ein fragmentiertes Paket zusammen bauen müsste ...

EDIT: Das Paket von meinem UM-Anschluss an den Server zu senden, geht ... also ist nur der Empfang betroffen.

 

[tq1199]

Müsste dann schon bei drei verschiedenen Internetprovidern auftreten (Hetzner, servdiscount, und der ISP vom Server mit dem @boba getestet hat) ...

EDIT: Das Paket von meinem UM-Anschluss an den Server zu senden, geht ... also ist nur der Empfang betroffen.

Teste mal mit einem TCP-Ping mit gesetztem DF-Flag, in beide Richtungen, ob das Datenpaket mit oder ohne gesetztem DF-Flag ankommt.

 

[boba]

Über ipv6 udp werden bei mir beide Pakete übertragen. Da tritt das Problem nicht auf. Selbe Konfiguration, nur cat test-working.bin > /dev/udp/2a02:908:xxx:xxxx:xxx:xxxx:xxxx:xxxx/5678 als ipv6 verwendet und mit tcpdump halt auf ipv6 Adressen gefiltert. Scheint also ipv4-spezifisch zu sein.

Ich habe Dual Stack, d.h. sowohl native ipv4 als auch native ipv6.
Kann ich nur empfehlen. Den ipv6 Tunnel über Hurricane Electric hatte ich auch mal, ist aber kein Vergleich zu native ipv6. Der Hurricane Tunnel ist einfach viel zu langsam. Da man das nicht erträgt, bastelt man so herum, dass übers Internet ipv4 forciert wird und ipv6 nur für Experimente benutzt wird. Das ist ein Graus, hat mich seinerzeit tierisch genervt. Als es möglich wurde, Dual Stack zu bekommen, habe ich gleich umgestellt - Unterschied wie Tag und Nacht. Endlich auch vollkommen normales ipv6.

Wer weiß, vielleicht haben wir hier ja den geheimen remote Control Code der NSA Spyboxen gefunden. Wo ist mein Aluhut?

 

[Leseratte10]

Also dieser Test hier im Browser ist auf jeden Fall erfolgreich, an meinem Anschluss: http://icmpcheck.popcount.org/

Und ein "nping --tcp -p 5678 1.2.3.4" (einmal ohne --df und einmal mit --df) zeigt mir auch im Dump ein Paket mit "Do not fragment"-Flag und eins ohne. Das klappt in beide Richtungen.
Interessant, dass es bei Unitymedia-IPv6 nicht auftritt ...

 

[tq1199]

... zeigt mir auch im Dump ein Paket mit "Do not fragment"-Flag und eins ohne. Das klappt in beide Richtungen.
Interessant, dass es bei Unitymedia-IPv6 nicht auftritt ...

Bei IPv4 bist Du hier auf die Fragmentierungsfähigkeit der Router (zwischen Sender und Empfänger) angewiesen. Deine Anwendung, die diese Datei erstellt bzw. die Paketgröße bestimmt, macht diesbezüglich keine Optimierung. Wenn auf dem Weg vom Server zum Empfänger ein Router nicht optimal konfiguriert (MTU, icmp-messages, ...) ist, dann kann so etwas schon mal passieren.

Bei IPv6 wird die Fragmentierung bzw. das Zusammenbauen nicht von den Router (unterwegs) gemacht, sondern von den Hosts (d. h. am Sender bzw. am Empfänger).

 

[Leseratte10]

Hm, das heißt ich könnte das Problem evtl. umgehen, wenn die sendende Anwendung keinen UDP-Socket nimmt sondern einen RAW-Socket; und schon vorgefertigte, auf 576-Byte fragmentierte IPv4-Pakete rausschickt? Dann sollte ja eigentlich kein Router unterwegs einen Grund haben, nochmal anders zu fragmentieren.

Wäre aber auch wieder so eine Bastellösung ...

 

[tq1199]

Wäre aber auch wieder so eine Bastellösung ...

Ich denke nicht, dass das eine Bastellösung wäre, denn gerade für UDP-Übertragung, sollte die Paketgröße auf Anwendungsebene optimiert bzw. festgelegt werden.