• Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
    Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

UDP-Contentfilter bei Unitymedia?

Diskutiere UDP-Contentfilter bei Unitymedia? im Internet und Telefon über das TV-Kabelnetz Forum im Bereich Internet und Telefon bei Unitymedia; Faszinierend. Ich habe deinen Test nachgestellt, und es passiert dasselbe wie bei dir. Ich erhalte mit tcpdump diese Meldung beim Senden von...
boba

boba

Beiträge
1.131
Reaktionen
286
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:


[[email protected] ~]# 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.
 
Zuletzt bearbeitet:

Leseratte10

Beiträge
1.513
Reaktionen
0
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

boba

Beiträge
1.131
Reaktionen
286
Was ist das denn für ein Protokoll in den Dateien, welche Anwendung generiert das?
 

Leseratte10

Beiträge
1.513
Reaktionen
0
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

boba

Beiträge
1.131
Reaktionen
286
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.
 
Zuletzt bearbeitet:

Leseratte10

Beiträge
1.513
Reaktionen
0
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.
 
Zuletzt bearbeitet:

tq1199

Beiträge
2.382
Reaktionen
9
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.:
Code:
sysctl -w net.ipv4.ipfrag_time=10
, ... ob der ICMP-Fehler dann nicht schon nach 10 Sekunden kommt?
 

Leseratte10

Beiträge
1.513
Reaktionen
0
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.
 

Leseratte10

Beiträge
1.513
Reaktionen
0
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

Beiträge
4.766
Reaktionen
103
Zeigt das unter v4 und v6 dasselbe Verhalten?
 
boba

boba

Beiträge
1.131
Reaktionen
286
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.

[[email protected] ~]# 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

Beiträge
1.513
Reaktionen
0
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.
 
Zuletzt bearbeitet:

Leseratte10

Beiträge
1.513
Reaktionen
0
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

Beiträge
4.766
Reaktionen
103
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

Beiträge
1.513
Reaktionen
0
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
 
Zuletzt bearbeitet:

addicted

Beiträge
4.766
Reaktionen
103
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

Beiträge
2.382
Reaktionen
9
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

Beiträge
1.513
Reaktionen
0
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.
 
Zuletzt bearbeitet:

tq1199

Beiträge
2.382
Reaktionen
9
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

boba

Beiträge
1.131
Reaktionen
286
Ü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

Beiträge
1.513
Reaktionen
0
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

Beiträge
2.382
Reaktionen
9
... 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

Beiträge
1.513
Reaktionen
0
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 ...
 
Thema:

UDP-Contentfilter bei Unitymedia?

UDP-Contentfilter bei Unitymedia? - Ähnliche Themen

  • Vodafone CableMAX: Upload von 700+ Mbits via UDP?

    Vodafone CableMAX: Upload von 700+ Mbits via UDP?: Hallo liebe Forengemeinde, Ich habe vor kurzem endlich (nach gefühlt 3 Monaten Wartezeit) meinen CableMAX 1Gbps / 50Mbps Tarif freigeschaltet...
  • OpenVPN Site-to-Site langsam im Upstream

    OpenVPN Site-to-Site langsam im Upstream: Hallo! Auch ich bin in der glücklichen Situation Eltern zu haben die ihre neue Technik lieben, aber hin und wieder "ein kleines Problem" damit...
  • 100% UDP Packet Loss?!

    100% UDP Packet Loss?!: Hallo ihr Forumsmenschen ich kämpfe seit der Routerumstellung mit Leitungsproblemen und komme an einem Punkt nicht weiter....vielleicht habt ihr...
  • wird incomming port 53 udp blockiert?

    wird incomming port 53 udp blockiert?: hallo, ich habe große probleme udp port 53 "durchzubekommen". sprich: udp port 53 vom internet aus auf meinen server zu leiten. der udp port 53...
  • Permanente UDP Anfragen von 10.121.64.1:67 ?

    Permanente UDP Anfragen von 10.121.64.1:67 ?: Hallo, wer weiss, warum Unitymedia Media auf das WAN Interface eines Routers ständig die Anfrage udp 10.121.64.1:67 > 255.255.255.255:68 stellt ...
  • Ähnliche Themen
  • Vodafone CableMAX: Upload von 700+ Mbits via UDP?

    Vodafone CableMAX: Upload von 700+ Mbits via UDP?: Hallo liebe Forengemeinde, Ich habe vor kurzem endlich (nach gefühlt 3 Monaten Wartezeit) meinen CableMAX 1Gbps / 50Mbps Tarif freigeschaltet...
  • OpenVPN Site-to-Site langsam im Upstream

    OpenVPN Site-to-Site langsam im Upstream: Hallo! Auch ich bin in der glücklichen Situation Eltern zu haben die ihre neue Technik lieben, aber hin und wieder "ein kleines Problem" damit...
  • 100% UDP Packet Loss?!

    100% UDP Packet Loss?!: Hallo ihr Forumsmenschen ich kämpfe seit der Routerumstellung mit Leitungsproblemen und komme an einem Punkt nicht weiter....vielleicht habt ihr...
  • wird incomming port 53 udp blockiert?

    wird incomming port 53 udp blockiert?: hallo, ich habe große probleme udp port 53 "durchzubekommen". sprich: udp port 53 vom internet aus auf meinen server zu leiten. der udp port 53...
  • Permanente UDP Anfragen von 10.121.64.1:67 ?

    Permanente UDP Anfragen von 10.121.64.1:67 ?: Hallo, wer weiss, warum Unitymedia Media auf das WAN Interface eines Routers ständig die Anfrage udp 10.121.64.1:67 > 255.255.255.255:68 stellt ...