[Problem] Kabel-Fritzbox blockiert gewisse UDP-Pakete

leseratte10

Mitglied
Mitglied seit
23 Apr 2012
Beiträge
406
Punkte für Reaktionen
2
Punkte
18
Hallo zusammen,

ich habe seit ca. 1 Monat ein verdammt merkwürdiges Problem an meinem Unitymedia-Anschluss mit Fritzbox 6591 07.13, und ich weiß absolut nicht mehr weiter, und ich bin mir auch nicht sicher was jetzt alles relevant dafür ist. Vielleicht hat ja einer der Fritzbox-Spezialisten in diesem Forum noch eine Idee.

Angefangen hat das ganze vor ca. einem Monat. Ich habe einen Server im Internet, wenn ich diesem ein speziell formatiertes UDP-Paket schicke, antwortet dieser mit einem anderen Paket (mit einer Datei die auf dem Server liegt). Das hat auch schon ne ganze Weile so funktioniert. Dann habe ich den Inhalt dieser Datei auf dem Server geändert (gleiche Dateigröße, nur anderer Inhalt) und es hat plötzlich nicht mehr funktioniert. Nach einigem herumspielen habe ich es geschafft, einen Testfall zu isolieren - zwei Dateien, die sich nur in einem einzigen Byte unterscheiden. Eine Datei kommt an, die andere nicht.

Testfall:
Code:
( echo get-ap=test.bin; sleep 1 ) | ncat -u 95.217.77.151 27900 | xxd
( echo get-ap=test2.bin; sleep 1 ) | ncat -u 95.217.77.151 27900 | xxd

Diese Befehle weisen den Server an, die entsprechende Datei zu senden. Frage ich den Server nach der "test2.bin", klappt alles wunderbar - ich sehe den Hexdump der Datei.
Frage ich den Server nach der "test.bin", klappt es nicht. Ich sehe keine Ausgabe, und in einem tcpdump auf dem Server sehe ich, dass von meiner öffentlichen IP ca. 30 Sekunden später ein "ICMP ip reassembly time exceeded" empfangen wird. Die Fritzbox ist also anscheinend nicht in der Lage, dieses Paket - dessen Inhalt sich nur um ein Byte unterscheidet (gleiche Dateigröße) von dem funktionierenden - zusammenzusetzen.

Probiere ich das ohne Fritzbox, also z. B. indem ich meinen Laptop an einen Handy-Hotspot hänge, klappt alles.

Ich habe im Unitymedia- und im Vodafone-Forum nachgefragt, weil ich das zuerst für eine Störung an meinem Anschluss oder im Vodafone-Netz hielt:
https://www.unitymediaforum.de/threads/39732/
https://www.vodafonekabelforum.de/viewtopic.php?f=52&t=42824

Dort haben dann mehrere Leute die Situation nachgestellt, und folgendes ist dabei rausgekommen:
- Es liegt nicht am Bundesland bzw. dem Provider-Netz im entsprechenden Bundesland, denn es gab zwei Tester aus Hessen, bei einem hat es funktioniert, beim anderen nicht.
- Es liegt nicht am Unterschied "eigenes Endgerät" / "Provider-Endgerät", denn ein Tester mit ConnectBox hatte Erfolg, und ein anderer mit eigenem TC4400 auch.

Bleibt meiner Meinung nach eigentlich nur die Fritzbox 6591 als Ursache - die anderen beiden Tester, bei denen es nicht funktioniert hat, hatten beide auch eine Fritzbox 6591.
Die AVM-Hotline hat mir daraufhin erklärt dass das ja gar nicht sein kann, und dass eine Fritzbox ja nicht solche Filter hätte die sowas blocken würden.

Daher die Frage, hat zufällig noch jemand eine Idee, was das für ein merkwürdiges Problem ist?
Könnten ein paar der hier Anwesenden das evtl. mal mit verschiedenen DSL-Fritzboxen (oder auch anderen Kabel-Fritzboxen) testen und Rückmeldung geben, ob das vielleicht ein generelles Fritzbox-Problem ist? Ich habe leider keinen anderen Anschluss mit Fritzbox zur Verfügung.
Dazu einfach die beiden Befehle oben im Code-Block nacheinander (auf einer Linux-Maschine) ausführen - im Erfolgsfall sollten dann für beide ein Hexdump angezeigt werden.
Im Fehlerfall würde nur die test2.bin als Hexdump angezeigt werden, die test.bin gar nicht.

So langsam habe ich keine andere Idee mehr ...

Leseratte10
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Carsten H.
Moinsen


Selbe Ergebnis von einem 1&1 Anschluss ( 100/40 ) mit einer 7590 mit 7.21, nur test2.bin wird geladen/angezeigt.
 
Okay, vielen Dank für den Test. Also ist das wohl ne generelle Macke in allen Fritzboxen? Interessant... aber wie kommt sowas zu Stande?

Kannst du auf der Box mal einen Paketdump auf der WAN-Schnittstelle machen damit man mal sieht was genau da ankommt oder wieder gesendet wird? Am besten den Dump dann auch danach noch 1 Minute oder so weiter laufen lassen bis der ICMP reassembly timer abgelaufen ist. Den Dump kannst du ja danach auf die Server-IP filtern.

Mit meiner Kabelbox kann ich ja leider keinen Netzwerkdump machen (ist gesperrt).
 
Hier mal die Aktionen insgesamt in einer Ausgabe meines...
Screenshot_20201005-140720.png
...darkstat.

Und einen Dump, auch wie Obiges, von einem Raspberry Pi aus gemacht...
Code:
tcpdump -vvv -i eth0 -n udp -tttt portrange 27900
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
2020-10-05 14:25:24.373415 IP (tos 0x0, ttl 64, id 13705, offset 0, flags [DF], proto UDP (17), length 44)
    192.168.188.9.48118 > 95.217.77.151.27900: [bad udp cksum 0x2a4c -> 0x881b!] UDP, length 16
2020-10-05 14:25:25.485368 IP (tos 0x0, ttl 64, id 13758, offset 0, flags [DF], proto UDP (17), length 45)
    192.168.188.9.51518 > 95.217.77.151.27900: [bad udp cksum 0x2a4d -> 0xa970!] UDP, length 17
2020-10-05 14:25:25.531693 IP (tos 0x0, ttl 56, id 31714, offset 0, flags [+], proto UDP (17), length 1492)
    95.217.77.151.27900 > 192.168.188.9.51518: UDP, bad length 1476 > 1464
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
...nach 3m abgebrochen.

Habe 2 NATs, 1 NAT macht bei mir eine 7560 mit 7.12.
 
Zuletzt bearbeitet:
Ich würde test.bin in test1.bin oder socke.bin umbenennen. Ist es der Inhalt oder der Name?
 
Es ist definitiv der Inhalt.
Der Dateiname wird ja nur an den Server gesendet, damit der weiß, mit welcher der beiden Dateien er antworten soll. Habe auch schon probiert die Dateinamen mal zu tauschen - keine Änderung.
 
So mal auf die schnelle, wenn ich einen tcpdump auf der 6591 laufen lasse sehe ich das:

Code:
tcpdump -i cni0 host 95.217.77.151
19:44:13.943173 IP XXX > static.151.77.217.95.clients.your-server.de.27900: UDP, length 17
19:44:26.646334 IP XXX > static.151.77.217.95.clients.your-server.de.27900: UDP, length 17
19:44:26.784961 IP static.151.77.217.95.clients.your-server.de.27900 > XXX.35252: UDP, bad length 1476 > 1472
19:44:26.785018 IP static.151.77.217.95.clients.your-server.de > XXX: udp

Das 2te ist ein fragment von 4 bytes.

Bei ersten kommt also tatsaechlich nix zurueck, bein 2ten ein etwas zu grosses paket (das sehe ich auch nur box-intern, auch das wird nicht ins LAN weitergereicht). Ich weiss ja nicht wie du deine Pakete schickst, aber ich würde spontan vermuten das die etwas zu gross sind ...

Edit: Sollte das so sein, eine MTU von 1480 oder 1476 für UDP pakete ist "gewagt", um es vorsichtig auszudrücken. Wenn du sicher sein willst, nimm 576, oder besser gleich TCP.
 
Zuletzt bearbeitet:
Habe die Antwort leider erst jetzt gesehen.

Das 2te ist ein Fragment von 4 byte, korrekt, das war der kleinste Testfall den ich reproduzieren könnte. Das eigentliche Paket mit den "Nutzdaten" sind etwas über 3KB, die dann in mehrere IP-Pakete fragmentiert werden. Da aber ein existierender proprietärer Client genutzt wird der nur UDP kann, kann ich leider kein TCP nutzen, auch wenn ich es gerne tun würde.

Eine richtige Lösung für das Problem habe ich immer noch nicht. Eine zweite Supportanfrage an AVM mit sämtlichen Details und Testpaketen endete mit folgender Antwort vom Support:

Anhand Ihrer zugesendeten Daten, darf ich Ihnen Mitteilen, dass wir eine Lösung des Problems möglicherweise in dem kommenden FRITZ!OS-Update bereitstellen.

Ob wir Ihre Daten, sobald wir eine neue FRITZ!OS-Version veröffentlicht haben, dann berücksichtigen konnten, kann ich ihnen nicht mitteilen. Bitte haben Sie Verständnis dafür.

Ich bedanke mich sehr für Ihre Mithilfe und Ihre Mühe und wünsche Ihnen eine schöne Woche.

Das stimmt mich doch vage hoffnungsvoll dass AVM da tatsächlich ne Macke in den Fritzboxen gefunden hat und das vielleicht irgendwann repariert.
Mein Workaround bis dahin ist immer noch, nach jeder Änderung an der Datei zu testen ob sie noch ankommt, und wenn nicht, dann halt wieder so lange Datenmüll ergänzen bis sie wieder durchkommt. Keine optimale Lösung, aber die beste die mir einfällt.
 
Hi,

ich hab deinen Beitrag gefunden, weil ich heute nach "Fritzbox UDP Problem" gegooglet habe und wollte mich deswegen kurz melden. Habe eine 6660 an einem Vodafone-Kabel(Deutschland)-Anschluss und mit deinem Dateitest das gleiche Bild. Das eine geht, das andere nicht. Gesucht danach habe ich übrigens, weil ich mit der Fritzbox ein anderes Problem habe: Ich kann, wenn die "Paketbeschleunigung" der Fritzbox aktiviert ist, mich nicht auf BigBlueButton-Server ohne Turn-Server verbinden. Es wird quasi kein UDP-ausgehandelt und die WebRTC-Verbindung schlägt fehl. Als ob die UDP-Pakete der Server im Nirvana verschwinden. Deaktiviere ich diese "Paketbeschleunigung" funktioniert alles wie erwartet und problemlos. Nur dass dann halt nur noch 1% der Internetbandbreite bei mir durchkommt, also keine Lösung im weiteren Sinne. Schließ ich die easybox von VF vor die Fritzbox und nutze diese nur als Router, funktioniert es auch mit aktivierter "Paketbeschleunigung". Hatte mir die halbe Nacht um die Ohren geschlagen, weil ich dachte serverseitig ist was kaputt...

Wollte das nur mitteilen, auch wenn anderes Thema, aber dein Beitrag mir am Ende weiterhalf, weil in irgendeinem Strang ich dann auf die Paketbeschleunigung kam (die in deinem Fall ja keine Änderung bringt).

Beste Grüße,

grx
 
Ich jammer dann mal mit.

Konfiguration:
Box: 6591, aktuelle Firmware, selbst gekauft.
Anschluss: Vodafone Giga, Dual Stack,

Problem:
Verbindungen mit BigBlueButton wegen WebRTC und UDP.

Symptom:
Beim Aufbau einer Videokonferenz (Online-Schooling) mit Mikrofon Fehler 1007 beim Verbindungstest.

Diagnose:
Testserver test.bigbluebutton.com funktioniert zwar meistens, braucht aber ewig beim Aufbau.
about:webrtc offenbart dann den Schlamassel den die Fritte mit den UDP-Daten anrichtet.

Fürchterlicher Workaround:
Kommunikation über einen freien VPN Anbieter leiten

Bin mit dem AVM-Support in Kontakt und bin gespannt.

Gruß
 
  • Like
Reaktionen: Carsten H.
Das stimmt mich doch vage hoffnungsvoll dass AVM da tatsächlich ne Macke in den Fritzboxen gefunden hat und das vielleicht irgendwann repariert.
Mein Workaround bis dahin ist immer noch, nach jeder Änderung an der Datei zu testen ob sie noch ankommt, und wenn nicht, dann halt wieder so lange Datenmüll ergänzen bis sie wieder durchkommt. Keine optimale Lösung, aber die beste die mir einfällt.
Hier, mit der providereigenen FB6591 im RIP-Modus (nur natives IPv4), aktivierter Hardwarebeschleunigung und FW-Version 7.13, funktionieren z. Zt. beide Tests:
Code:
:~$ ( echo get-ap=test2.bin; sleep 1 ) | ncat -u 95.217.77.151 27900 | xxd | head
0000000: fefd 0600 0000 7b02 6bdc 7100 0000 0000  ......{.k.q.....
0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
Code:
:~$ ( echo get-ap=test.bin; sleep 1 ) | ncat -u 95.217.77.151 27900 | xxd | head
0000000: fefd 0600 0000 7b02 6bdc 9900 0000 0000  ......{.k.......
0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 
Mit deaktivierter Hardwarebeschleunigung volle Funktionalität aber schnarchlangsam über WLAN. Statt problemlosen 600 MBit mit meinem Smartphone ganze 8 MBit.
 
Ja. Der Unterschied ist eigene FB6591, aktuelle FW (und DS).
Sorry, ist das jetzt als konstruktiver Beitrag oder besserwisserisch gemeint? Das es unterschiedliches Verhalten abhängig von der Software gibt sollte allenthalben bekannt sein in diesem Thread. Oder geht es um das Bashing von uns "Trotteln" die keine Lust auf Bevormundung durch Providerhardware haben?
 
Also doch reine Überheblichkeit ^^
 
Oh man, habe mich gewundert, warum ich in Battlefield 5 keinem Game mehr joinen konnte. Das letzte mal ging es mit der alten Fritzbox 6590. Nun habe ich eine 6660 mit FritzOS 7.23 und ich kann nur zocken, wenn die Paketbeschleunigung deaktiviert ist. WebRTC Tests wie hier: https://test.webrtc.org/ fallen mit

Reflexive connectivity

[ INFO ] Gathered candidate of Type: srflx Protocol: udp Address: xxx.xxx.xxx.xxx
[ WARN ] Could not connect using reflexive candidates, likely due to the network environment/configuration.

auf die Fresse.
 
Zuletzt bearbeitet:
İch habe gleiche problem vodafone hat meine fritzbox blockiert hat eine lösung?
 
[Edit Novize: Überflüssiges Fullquote gelöscht - siehe Forumsregeln]

Ich habe exakt das gleiche Problem, hast Du dafür schon eine Lösung gefunden außer über eine VPN Verbindung zu gehen?

Stephan
 
Zuletzt bearbeitet von einem Moderator:
Hallo zusammen,

wollte nur das Problem auch von meiner Seite bestätigen.

- Provider: NetCologne
- Vom Provider bereitgestellte Fritzbox 6591 mit FritzOS 7.21
- Nativer Dual Stack

Besonders stark fällt es mir bei OpenVPN Verbindungen über UDP auf.
Bei aktiviertem Verbose Logging (Glaube mindestens verb 4) in den OpenVPN Logs sichtbar über Fehlermeldung "Replay-window backtrack occurred".

Besten Gruß


EDIT: Auch mal die Tests gemacht. Gleiches Ergebnis:

Code:
$ ( echo get-ap=test2.bin; sleep 1 ) | ncat -u 95.217.77.151 27900 | xxd | head
00000000: fefd 0600 0000 7b05 5ba4 1000 0000 0000  ......{.[.......
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................


$ ( echo get-ap=test.bin; sleep 1 ) | ncat -u 95.217.77.151 27900 | xxd | head
*Gar nix*
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.