[quote=„stefan6, post:20, topic:8211, full:true“]
Der tunneldigger läuft bei uns auf 10050 und max waren 18k auf einem 100k KD Uplink möglich
Kann es damit zusammenhängen? [/quote]
Gut möglich. Ich bin nicht sicher wo da das Problem ist - eventuell macht die Fritzbox auch komische Sachen. Fakt ist, dass über Port 53 bei 1und1 die volle Bandbreite durchkommt - bei anderen Ports (habe UDP 123,8942,5061,5060,1194,80,443,1935,3536 getestet) wird beim Testdownload die Verbindung langsamer und hängt so bei 400kByte/s - nur nicht bei Port 53.
Update: Die Probleme lagen an der MTU vom Tunnel - 1446 ist wohl zu hoch für tunneldigger und auch 1450 macht für vtun mit UDP Probleme. Ich teste jetzt mal in Ruhe die richtige MTU.
Ob das bei KD auch so ist, weiß ich nicht - eventuell wird da auch Port 53 gedrosselt.
Bist du auch bei 1und1 Kunde? Ich kann die verringerte Geschwindigkeit sowohl mit vtun über UDP als auch mit Tunneldigger nachvollziehen - vielleicht ist es auch kein allgemeines 1und1 Problem sondern etwas anderes. Über KD finden sich zumindest viele Hinweise für ein Drosseln von UDP - kann ich mangels Account nicht bestätigen. Vielleicht ist es nur eine technische Störung oder so… mal abwarten.
Habt ihr auf dem Gateway den BATMAN Patch mit drauf? Zwecks no Broadcast? Dies fehlt hier noch
Weist du zufällig wie ich das Batman mit dem Patch baue?
Kurzes Update: Die Probleme lagen an einer falschen MTU - 1446 war zu hoch für den Tunnel. Die von uns verwendeten 1450 für vtun mit UDP sind wohl auch zu hoch.
Also keine Drosselung seitens 1und1 - Sorry für die Verwirrung.
Ich hatte mit Wireshark fragmentierte Pakete entdeckt… diese ganze MTU,MSS,PMTU Problematik hab ich noch nicht so wirklich verdaut. Tunnel MTU von 1446 ist wohl zu viel für das VDSL. Ich will nichts falsches erzählen, jedenfalls sorgen Fragmentierte Tunnel-Pakete bei mir für die Probleme so wie es aussieht.
So, neue Erkenntnisse.
Batman läuft mit dem Patch in aktueller Version. Leider gehen maximal 8mbit durch den Router. Der Router ist ein 3600. Jemand (bei dem es läuft) noch weitere Ideen? @chrisno@stefan
Mache den Test mal zu verschiedenen Tageszeiten.
Ich habe das in der Tat auch. Backbone kann ich ausschliessen, da der Traffic direkt ab Supernode ins Netz geht. Wie sieht das da bei dir aus? Evtl mal einen Test von Router zu Supernode, um das Backbone auszuschliessen.
Evtl ist die Supernode gerade eh dicht?
Evtl ist aber auch der Host, auf dem die Supernode läuft dicht? Das ist mein Problem von Zeit zu Zeit … gerade Abends.
ich bin bei Unitymedia mit einem 100er Anschluss.
Ich habe die Firmware nochmal frisch mit ‚-n‘ drüber gebügelt.
Gleiches Ergebnis peak bis zu 85mbit (1043er)
Aber häufig Verbindungsabbrüche.
Ich schätze, dass es noch iwo an der Supernode hängt. Der L2TP Tunnel scheint zu funzen.
Nutze für meine Firmware und die Supernode mtu 1364. Das lüppt.
ping gw02.osnabrueck.freifunk.net
PING gw02.osnabrueck.freifunk.net (127.0.1.1): 56 data bytes
64 bytes from 127.0.1.1: seq=0 ttl=64 time=0.274 ms
64 bytes from 127.0.1.1: seq=1 ttl=64 time=0.245 ms
64 bytes from 127.0.1.1: seq=2 ttl=64 time=0.214 ms
64 bytes from 127.0.1.1: seq=3 ttl=64 time=0.216 ms
64 bytes from 127.0.1.1: seq=4 ttl=64 time=0.219 ms
64 bytes from 127.0.1.1: seq=5 ttl=64 time=0.222 ms
ist das richtig, das der die supernode unter 127.0.1.1 findet statt einer IP in eurem internen bereich?
eine route für den internen ip bereich hat die kiste scheinbar auch nicht?
ip r s
default via 192.168.1.1 dev br-wan
192.168.1.0/24 dev br-wan src 192.168.1.244
Mir scheint, nur eine Vermutung, dass da an der SuperNode config iwas schief ist.
Gruß
Chrisno
btw: ich flash zurück. ist mein einziges WLAN hier
Ja das Routing ist grade noch ein Problem.
Die statische interne Route, wie setzt ihr die?
10.33.0.0/18 ist auf br-mesh gelegt.
fd74 gibt es von radvd
Und wo kommt hier die 127.0.0.1 her?
