Unitymedia UDP-Contentfilter bei Unitymedia?

[Leseratte10]

Hallo zusammen,

ich habe jetzt die letzten zwei Tage mit einem kuriosen Netzwerkproblem an meinem Unitymedia-Business-Anschluss (immer noch der alte "Unitymedia Office Internet & Phone 50" Vertrag von vor ein paar Jahren) mit Fritzbox 6591 verbracht und weiß nicht mehr weiter, vielleicht hat ja hier noch jemand eine Idee:

Ich habe im Internet einen Server, der lauscht auf einem UDP-Port. Ich schicke mit NCAT ein Paket an diesen Port mit einer Anfrage, und der Server antwortet - testweise - einfach mit der angefragten Datei:

(echo get-file=test1.bin; sleep 3) | ncat -u 1.2.3.4 5678 | xxd

Auf dem Server gibt es zwei Dateien - test1.bin und test2.bin - mit leicht unterschiedlichem Inhalt, aber exakt gleicher Dateigröße. Frage ich den Server nach "test1.bin", bekomme ich eine Antwort, siehe tcpdump:

06:39:03.997767 IP 10.0.1.102.51250 > sv2.27900: UDP, length 28
06:39:04.063854 IP sv2.27900 > 10.0.1.102.51250: UDP, bad length 3448 > 1472
06:39:04.063898 IP sv2 > 10.0.1.102: udp
06:39:04.063937 IP sv2 > 10.0.1.102: udp

(fragmentiertes Paket, daher das "bad length").

Frage ich den Server nach "test2.bin", bekomme ich keine Antwort:

06:38:53.606182 IP 10.0.1.102.34910 > sv2.27900: UDP, length 28
<keine weiteren Pakete>

Das kann ich so beliebig oft wiederholen, das ist also nichts "einmaliges".

Der entsprechende Dienst auf dem Server funktioniert prima - beide Dateien vorhanden, beide Dateien im ausgehenden tcpdump des Servers sichtbar, und wenn ich meinen Rechner von der Unitymedia-Fritzbox trenne und mit meinem Handy-Hotspot verbinde, klappt auch alles und beide Pakete kommen an. Und im tcpdump übers Handynetz sind auch keinerlei Unterschiede zu sehen.

Ich habe durch die Menüs der Fritzbox geschaut und sämtliche Filter, die ich finden konnte, abgeschaltet (Email-Filter, Teredo-Filter, sonstwas ...), in der Hoffnung, dass es was bringt - kein Erfolg.
Ich würde gerne einfach die nicht-funktionierende test2.bin mal hier zur Verfügung stellen damit vielleicht jemand anderes testen kann, leider sind da aber Dinge drin die ich nicht mit der ganzen Welt teilen möchte.

Hat zufällig irgendjemand hier im Forum ne Idee, was das für ne Unitymedia-Eigenart ist? Das einzige, was mir einfallen würde, wären irgendwelche Content-Filter - aber sooo sehr unterscheiden sich test1.bin und test2.bin jetzt auch nicht voneinander ...

Gibt es irgendeine Möglichkeit, bei Unitymedia irgendwen zu kontaktieren der mit solchen technischen Details was anfangen kann? Wie erkläre ich sowas am besten der Hotline ...

 

[MartinP_Do]

Nur eine Frage zur Sicherheit: Sind die Rechte der beiden Files gleich eingestellt? Womöglich "sieht" der Prozess das eine File nicht, weil er keine Rechte für das File hat ...

 

[Leseratte10]

Beide Dateien gleiche Rechte, gleicher Eigentümer, gleiche Gruppe.

Die Dateien tauchen ja auch beide im ausgehenden tcpdump auf Serverseite auf, und über einen Handy-Hotspot kommen sie auch bei mir an. Nur über den Unitymedia-Anschluss halt nur eine der beiden. Ich habe es gerade im Moment nochmal übers Handynetz und über den UM-Anschluss mit beiden Dateien getestet.

UM hat ja leider auch die /capture.lua auf ihren Fritzboxen gesperrt, sonst könnte ich mal auf der Box dumpen und schauen ob die Pakete da ankommen oder schon von UM verworfen werden ...

 

[tq1199]

... Fritzboxen gesperrt, sonst könnte ich mal auf der Box dumpen und schauen ob die Pakete da ankommen oder schon von UM verworfen werden ...

Versuch mal den Traffic für den Rechner, via FritzBox auf einen anderen Rechner umzuleiten. Evtl. kannst Du dann auf dem "man-in-the-middle"-Rechner, im ankommenden Traffic etwas erkennen.

 

[Leseratte10]

Schon passiert. Habe eine Portfreigabe auf einen UDP-Port angelegt, dann den Server die Antwort mit dem Dateiinhalt an diesen Port senden lassen. es kommt aber immer noch nur eine der beiden Dateien an.
IPv4-Route anlegen, zweites Netz erstellen, und Portfreigabe auf IP in diesem zweiten Netz, mit einer Linux-Kiste als Router dazwischen, klappt auch nicht; kommt auch nur eine der beiden Dateien an.

Oder meinst du mit "den Traffic umleiten" etwas anderes?

Es muss eigentlich entweder was bei UM im Netz, oder direkt, low-level, auf der Fritzbox sein...

 

[MartinP_Do]

Wenn es eine Leih-Fritzbox ist, ggfs. einen LAN-Port in den Bridge-Mode versetzen, und einen PC direkt, oder einen anderen Router dahinterhängen ...

Du sprichst von "eine der beiden Dateien " Funktioniert immer nur die erste Datei, und die zweite Datei geht nicht? Bei Vertauschung der Reihenfolge (also zuerst Datei2) würde Datei2 funktionieren, aber Datei1 nicht?

 

[Leseratte10]

Es ist eine Leih-Fritzbox, das mit dem Bridge-Modus werde ich heute Abend mal ausprobieren wenn der Rest des Haushalts das Internet nicht zwingend benötigt.

Es ist immer die gleiche Datei (der gleiche Inhalt), die nicht funktioniert. Reihenfolge egal, X-mal hintereinander, etc., es liegt am Datei-Inhalt. Also nicht "immer die erste geht nicht", sondern "test2.bin" geht nicht, egal ob ich zuerst test1 oder zuerst test2 sende. Auch wenn ich die test2 5x hintereinander sende, nichts.

Und das nur an diesem Anschluss, über DSL oder im Handynetz gehen beide ...

 

[tq1199]

Oder meinst du mit "den Traffic umleiten" etwas anderes?

Ich meinte auf dem MITM-Rechner an der FB, mit z. B.:

sysctl -w net.ipv4.ip_forward=1
arpspoof -i <Interface> -c host -t <IP-Adresse-Opfer> -r <IP-Adresse-FB>
arpspoof -i <Interfrace> -c host -t <IP-Adresse-FB> -r <IP-Adresse-Opfer>
tcpdump -veni <Interface> host <IP-Adresse-Opfer> and not arp and not multicast and not host <IP-Adresse-MITM-Rechner>

(oder gleichwertig).

 

[tq1199]

...., es liegt am Datei-Inhalt.

Wie sind die Ausgaben von:

file test1.bin test2.bin
stat test1.bin test2.bin

?
Kannst Du diese Datei test2.bin, per UDP übertragen, wenn sie sich in einem Archiv (z. B. *.tar.gz oder gleichwertig) befindet?

 

[Leseratte10]

ARP spoofing werde ich heute Abend mal ausprobieren, danke. Aber wie ist das denn - aus Sicht der Fritzbox - anders, als wenn ich die Pakete direkt an den Linux-Rechner hinter der Fritzbox schicke? Welchen Unterschied macht es, mit ARP spoofing auf einem anderen Rechner als dem eigentlichen Ziel zu dumpen?

In den Dateien ist in beiden Fällen binäre Daten die "file" nicht erkennt:

test1.bin: data
test2.bin: data

Und auch an der Ausgabe von "stat" sehe ich nichts verdächtiges, bis auf die Inode-Nummer und die Zugriffszeiten sind die auch identisch:

# stat test1.bin test2.bin
Datei: test1.bin
Größe: 3437 Blöcke: 8 EA Block: 4096 reguläre Datei
Gerät: 903h/2307d Inode: 8852639 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2020-09-13 21:29:18.252721143 +0200
Modifiziert: 2020-09-12 21:27:14.445156510 +0200
Geändert : 2020-09-12 21:27:14.445156510 +0200
Geburt : -
Datei: test2.bin
Größe: 3437 Blöcke: 8 EA Block: 4096 reguläre Datei
Gerät: 903h/2307d Inode: 8852642 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2020-09-14 06:34:56.615115381 +0200
Modifiziert: 2020-09-12 21:45:22.616170308 +0200
Geändert : 2020-09-12 21:45:22.616170308 +0200
Geburt : -

Und wenn *da* was nicht stimmen würde würden die Probleme ja nicht nur am Unitymedia-Anschluss auftreten, oder?

Ob ich beide Dateien übertragen kann wenn sie in einer .tar.gz stecken, probiere ich mal aus.
EDIT: Jeweils in ein .tar.gz-Archiv verpackt kommen beide Dateien an.

 

[tq1199]

Aber wie ist das denn - aus Sicht der Fritzbox - anders, als wenn ich die Pakete direkt an den Linux-Rechner hinter der Fritzbox schicke? Welchen Unterschied macht es, mit ARP spoofing auf einem anderen Rechner als dem eigentlichen Ziel zu dumpen?
...
EDIT: Jeweils in ein .tar.gz-Archiv verpackt kommen beide Dateien an.

Eigentlich sollte es egal sein, auf welchem Rechner man mit tcpdump nachschaut.
Aber da man die Ursache für das nicht ankommen der test2.bin-Datei auf dem Opfer-Rechner nicht kennt, kann man ja mal auf einem zwischengeschalteten Rechner (MITM) nach schauen.

Mit arpspoof gibt sich der MITM-Rechner gegenüber der FB (Router), als Opfer-Rechner aus und gegenüber dem Opfer-Rechner, gibt sich der MITM-Rechner als Router aus.

 

[boba]

Sind in den Dateien DNS-Antworten drin? In den Fritzboxen gibts den dns-rebind-Schutz, der dns-Antworten wegfiltert, die auf IP Adressen im lokalen Netz verweisen. Dein Server scheint zwar nicht auf dem DNS Port 53 zu laufen, aber vielleicht ist dieser Filter in der Fritzbox ja portunabhängig implementiert. Die Richtung der Daten müsste stimmen.
Die Filtereinstellungen findest du in der Fritzbox->Heimnetz->Netzwerk->Netzwerkeinstellungen->DNS-Rebind-Schutz

 

[Leseratte10]

In den Dateien sind keine DNS-Antworten drin. In der DNS-Rebind-Liste in der Fritzbox stehen vier Hostnamen drin, keiner dieser Hostnamen steht in der Datei, und die URLs die in der Datei stehen (vollständige URLs, also a la "https://some-random-server.some-domain.de/some-path"; nicht nur Hostnamen) lösen auch auf öffentliche IPs auf die nichts mit der Fritzbox zu tun haben. Diese URLs sind auch in test1.bin und test2.bin identisch.

Ich werde aber einfach mal testweise die vorhandenen Hostnamen in den Dateien in die DNS-Rebind-Liste eintragen und nochmal testen - schaden kann es ja nicht.

 

[boba]

Dann ist das weitere hier im Forum im Prinzip Kaffeesatzleserei, solange man nicht genau schauen kann, was die Dateien beinhalten bzw. genauer in was sie sich unterscheiden. Du hast bereits herausgefunden, dass die Pakete vom Server noch herausgehen, aber am UM-Anschluss hinter der Portweiterleitung nicht ankommen. Die Portweiterleitung hingegen funktioniert, sonst würde der Inhalt einer gleich großen Datei anderen Inhalts nicht ankommen. Ich würde daraus auch schließen, dass es auf irgendeinem Gerät zwischen dem Sender und dem Empfänger nicht weitergeleitet wird. Da es unwahrscheinlich ist, dass das auf einem Backbone-Router passiert, würde ich auf 3 Geräte tippen:
- die Fritzbox
- mögliche Router netzintern
- die Maschine, auf die die udp Portweiterleitung zeigt (der Empfänger)

Beim Empfänger könnte es noch eine Firewall geben, die Daten anhand des Inhalts filtert. Gibts das nicht, hast du meiner Ansicht nach das Problem bereits auf die Fritzbox eingegrenzt. Oder auf einen Router dazwischen, falls er existiert - davon hast du bisher nichts geschrieben.

Wenn du von der Fritzbox die Diagnose-Daten erstellen lässt, dann kannst du dort nahezu die komplette Konfiguration der Fritzbox durchsehen. Es ist ein Linux System, und meiner Erinnerung nach hat man dort auch eine iptables Konfiguration. Würde ich mal nach suchen und schauen, ob da noch irgendein bislang unbekannter Filter drin ist.

 

[tq1199]

In den Dateien ist in beiden Fällen binäre Daten die "file" nicht erkennt:

Wie hast Du diese bin-Dateien erstellt bzw. mit welchem tool benutzt (schreiben + lesen) Du diese bin-Dateien? Bekommst Du mit:

od test1.bin
od test2.bin

jeweils eine Ausgabe ohne Fehlermeldung?

 

[Leseratte10]

- Mögliche Router zwischen Fritzbox und Endgerät gibt es nicht. Das einzige, was da zwischen hängt ist ein normaler (unmanaged) Gigabit-Switch, und daran dann direkt mein Testgerät.
- Die Maschine auf die die Weiterleitung zeigt, auch unwahrscheinlich. Ich habe zwei verschiedene Geräte getestet und auf beiden direkt mit tcpdump am eingehenden Interface aufgezeichnet.

Die Support-Daten habe ich durchgesucht und nichts entsprechendes gefunden.

Ich hatte noch einmal Gelegenheit, auf dem Server einen tcpdump zu machen, und habe noch etwas herausgefunden:
Nachdem der Server das Binary sendet ...

14:31:54.592068 IP ip-xx-xxx-xxx-xx.hsi01.unitymediagroup.de.55078 > sv2.27900: UDP, length 28
14:31:54.592158 IP sv2.27900 > ip-xx-xxx-xxx-xx.hsi01.unitymediagroup.de.55078: UDP, bad length 3448 > 1472
14:31:54.592163 IP sv2 > ip-xx-xxx-xxx-xx.hsi01.unitymediagroup.de: udp
14:31:54.592165 IP sv2 > ip-xx-xxx-xxx-xx.hsi01.unitymediagroup.de: udp

antwortet die Fritzbox nach ca 30 Sekunden folgendermaßen:

14:32:23.683214 IP ip-xx-xxx-xxx-xx.hsi01.unitymediagroup.de > sv2: ICMP ip reassembly time exceeded, length 36

.

Bisher nie gesehen, da ich den Dump immer schon beendet hatte. Interessant. Das bedeutet, die Fritzbox kann die Fragmente aus irgendeinem Grund nicht wieder zusammensetzen. Aber warum nicht, wenn doch nur der Dateiinhalt anders ist?

 

[Leseratte10]

@tq1199 Die Dateien sind binäre Dateien die per SFTP auf den Server hochgeladen werden. Die werden vorher außerhalb des Servers mit irgendeinem Programm erstellt. "od test1.bin" und "od test2.bin" geben mir beide einen Hexdump der entsprechenden Datei aus. Die Serversoftware (die die Datei sendet) ist eine selbstgeschriebene C-Software.

 

[tq1199]

Die Serversoftware (die die Datei sendet) ist eine selbstgeschriebene C-Software.

BTW: Mit netcat soll man ja auch mit UDP, Dateien über das Internet senden können. Teste mal ob das mit deinen beiden bin-Dateien funktioniert.

 

[boba]

Wenn der Empfänger signalisiert, dass die reassembly time exceeded ist, dann würde ich daraus schließen, dass eines von den beiden udp Paket weggefiltert worden ist, aber nicht das andere.
Wenn beide Pakete weggefiltert worden wären, dann würde es keine solche icmp Meldung geben, weil der Empfänger nicht wüsste, dass eine reassembly erforderlich ist.
Wenn beide durchgekommen wären, hättest du den Thread nicht eröffnet.
Also ist eines der Pakete durchgekommen, entweder das erste oder das zweite. In beiden Fällen wüsste der tcp/ip Stack, dass etwas unvollständiges angekommen ist, und würde auf die Ankunft des anderen Paketes warten.

Ansonsten: proier doch mal einen anderen Port.

 

[Leseratte10]

Genau, eins der Teilstücke muss auf jeden Fall irgendwo verloren gehen, die Frage ist nur wo oder warum.
Ein anderer Port hat auch nicht geholfen.

Für den Moment habe ich allerdings eine Notlösung gefunden:
Ich habe die nicht-funktionierende Datei im Hex-Editor geöffnet und so lange am Ende Bytes abgeschnitten, bis der Rest (also der Dateianfang) vernünftig ankam.
Dann habe ich mir das Programm geschnappt was die Datei generiert, und habe kurz vor dieser Stelle ein paar Müll-Bytes generieren lassen (die dann in der Datei ignoriert werden vom Empfänger) und seitdem kommt das vollständige Paket, mit den paar Müll-Bytes in der Mitte, wieder korrekt an.

Die Stelle mit dem Fehler konkret herausisolieren konnte ich aber nicht - nehme ich am Dateianfang ein paar Bytes weg, funktioniert die bis dahin nicht funktionierende Datei plötzlich auch wieder ...

Ne super-tolle Dauerlösung ist das zwar nicht (nachher muss ich jetzt bei jeder Änderung wieder woanders Müllbytes einfügen ...) aber immerhin läuft es jetzt wieder.

Unitymedia habe ich mal angerufen und erklärt dass bestimmte fragmentierte UDP-Pakete verloren gehen, da will sich morgen jemand aus der Fachabteilung melden. Mal schauen was da bei rum kommt.

 

[addicted]

Das klingt danach, als ob in dem zweiten Fragment irgendeine Byte-Sequence drin ist (vermutlich nah am Anfang), welche dafür sorgt, dass das Paket verworfen wird. Das kann aber auch schon auf der Seite des Servers passieren, d.h. Du müsstest die Serverseite auch mal auf einem anderen Host und ISP/RZ versuchen. Ideal wäre vielleicht ein anderer UM-Anschluss, weil es dann nicht über die Ingress-Router muss.

 

[tq1199]

Unitymedia habe ich mal angerufen und erklärt dass bestimmte fragmentierte UDP-Pakete verloren gehen, da will sich morgen jemand aus der Fachabteilung melden. Mal schauen was da bei rum kommt.

Der DSL- bzw. der Mobilfunkanschluss wird eine andere MTU benutzen, im Vergleich zum UM-Anschluss. Wenn man UDP benutzt, dann sollte doch besser nicht fragmentiert werden müssen (siehe VoIP, streaming, ...) oder das Fragmentieren sollte schon auf Anwendungsebene "geregelt" werden. Die Mechanismen die mit TCP bei der Fragmentierung benutzt werden, funktionieren mit UDP nicht.
Warum ist es für dich wichtig, dass diese Dateien per UDP (und nicht per TCP) übertragen werden?

EDIT:

Mit einem UDP-ping kann man das simulieren. Z. B.:

:~$ nping -c 3 --udp --mtu 888 --data-length 4567 --df -g 34567 -p 53 1.1.1.1
WARNING: Payload exceeds maximum recommended payload (1400)

Ausgabe von tcpdump:

08:56:12.744365 c0:25:06:yy:yy:yy > xx:xx:xx:17:62:b4, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 63, id 34688, offset 0, flags [none], proto ICMP (1), length 56) 192.168.180.1 > 192.168.178.22: ICMP ip reassembly time exceeded, length 36 (tos 0x0, ttl 63, id 34688, offset 0, flags [+], proto UDP (17), length 908) 192.168.178.22.34567 > 1.1.1.1.53: [|domain]
08:56:13.856631 c0:25:06:yy:yy:yy > xx:xx:xx:17:62:b4, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 56, id 30024, offset 0, flags [none], proto ICMP (1), length 576) 1.1.1.1 > 192.168.178.22: ICMP ip reassembly time exceeded, length 556 (tos 0x0, ttl 56, id 34688, offset 0, flags [+], proto UDP (17), length 908) 192.168.178.22.34567 > 1.1.1.1.53: 61088 stat+ [b2&3=0x134e] [21872a] [16816q] [64740n] [4532au] Type41221 (Class 17375)? OM-vM-DM-[M-c^^M-~M-^XM-5M-PNM-t!M-^@M-uM-\M-eM-;).<BAD PTR>[|domain]

 

[MartinP_Do]

Da könnte schon der Hase im Pfeffer liegen... In der Regel werden Dateien ja nicht "binär" übertragen, sondern es wird eine Kodierung benutzt, z. B. Base64 ... evtl. ergeben die beiden gleich großen Dateien nach Kodierung keine gleich großen UDP-Pakete ....

 

[Leseratte10]

Das mit der Byte-Sequenz werde ich mal durchprobieren - vielleicht bekomme ich ja ein Beispielpaket gebaut was möglichst klein ist und den Fehler auch auslöst.

UDP hat kein Verfahren zur Fragmentierung, das ist korrekt. IP an sich unterstützt aber Fragmentierung. Die Daten müssen per UDP übertragen werden, weil sie (in Zukunft, wenn das Übertragen denn funktioniert) von einer bestehenden, proprietären, closed-source Anwendung empfangen werden sollen, und die will halt nur UDP. Das soll dann auch für andere Nutzer out-of-the-box laufen, also kann ich auch nicht einfach einen Proxy dazwischen hauen der lokal läuft und auf TCP empfängt und per UDP an die Anwendung weitergibt.

Den von dir genannten nping habe ich mal auf dem Server ausgeführt, mit meiner öffentlichen IP und dem freigegebenen Port als Ziel, und das klappt alles. Da kommen problemlos 3x4650 Bytes an.

Die Dateien werden binär, so wie sie sind, als Payload in einem UDP-Paket verschickt, da wird nichts noch kodiert. Die gesamten Daten sind dabei ca 3500 Byte groß, werden also definitiv aufgeteilt auf drei Pakete und passen auch an einem DSL- oder Mobilfunkanschluss nicht in ein Paket.

Unitymedia hat sich heute zurückgemeldet, hat nur meine Anschlusswerte und sowas durchmessen lassen, und jetzt habe ich ne Mailadresse zum 2nd-level-support, mal schauen was die sagen.

 

[Leseratte10]

Okay, ich habe es endlich geschafft einen Testcase zu isolieren der keine privaten Daten mehr beinhaltet.

Hier eine ZIP-Datei. Zwei Dateien, gleiche Länge (1476 bytes), EIN einziges Byte unterschiedlich.
Auf meiner Maschine läuft Wireshark, dumpt alles, was vom Server im Internet kommt.

Auf dem Server entweder `cat test-working.bin > /dev/udp/1.2.3.4/5678` oder `cat test-fail.bin > /dev/udp/1.2.3.4/5678`, wobei 1.2.3.4 dann die öffentliche IP meiner Fritzbox ist und 5678 der UDP-Port, den ich auf meinen Rechner (wo Wireshark läuft) weitergeleitet habe.
Auf dem Rechner dann irgendein Programm, was auf diesem UDP-Port hört.

Mit der "test-working.bin" sehe ich in Wireshark fragmentierte IP-Pakete, und Wireshark kann diese zu einem gesamten Paket zusammensetzen, wo eins-zu-eins der Inhalt der "test-working.bin" drin steht. Mit der "test-fail.bin" sehe ich - Überraschung - nichts.

Ich wäre sehr froh wenn jemand anderes diesen Testfall mal nachstellen könnte um das zu vergleichen - vielen Dank schon mal im Vorraus ...