[Freifunk-Bonn] Problemfälle Unity-Media-Anschlüsse - wer ist betroffen?

Do Dez 11 09:59:15 CET 2014

Hi Jan,

ich versuche noch einmal zusammen zufassen was aus meiner Sicht das
Problem ist, wie ihr es versucht habt es zu lösen und wie ich es
stattdessen lösen würde.

Definition der Begriffe:

supernode = VPN-Gateway
mesh-node = VPN-client = openwrt Router beim "Kunden"

Wir müssen echt mal spezifizieren, was fastd und batman-adv sind. Mir
ist nämlich echt nicht klar, wie ihr die Begriffe nutzt.

batman-adv   ist ein Protokoll, richtig?
fastd ; rein aus dem Namen schließe ich mal, dass es ein daemon ist. Der
VPN client?

Aktueller Stand:

Der mesh-node kann einen VPN-Tunnel mit der supernode aufbauen. Richtig?
mesh-node und supernode können batman-adv pakete miteinander
austauschen. Richtig?

Bis hier her müsste alles funktionieren. heise kann ja aufgerufen
werden. Außer es geht am Tunnel vorbei.

Was nicht geht sind Spiegel, ebay usw. ich vermute grundsätzlich IPv4
mit TCP.

Es funktioniert nicht weil die Pakete zu groß sind und die
Fragmentierung nicht funktioniert.

Ihr habt versucht die Pakete der WLAN Clients die hinter der mesh-node
hängen kleiner zu machen. Mit dem Ziel, dass nicht mehr fragmentiert
werden muss.

Euer Ansatz war es die MTU kleiner zu machen und zwar mit Hilfe von
DHCP. Hat nicht funktioniert, weil die Clients die MTU in DHCP
ignorieren.

Ziel sind kleinere Pakete, richtig?

Kommen wir zu TCP.
TCP macht beim Verbindungsaufbau einen 3-Way-handshake. Im Ersten Paket,
das der Client sendet(SYN) ist eine Option namens Maximum Segment Size
(MSS). Die MSS gibt an wie groß der TCP Payload maximal sein darf.

MSS = MTU size - IP Header size - TCP Header size;

Beispiel:
 MSS = 1500 - 20(IPV4) - 20(TCP) = 1460

Der Server antwortet dann mit SYN ACK und dieses Paket enthält auch eine
MSS. Eben jene die sich beim Server durch MTU etc. ergibt.

Danach einige sich beide Kommunikationspartner auf den kleinsten der
beiden Werte. Weil ihr die MTU mittels DHCP nicht zuverlässig anpassen
könnt ist sie meist 1500, und die MSS 1460. Also zu groß.

Ihr könnt die MSS auf dem Weg zwischen Client und Server aber einfach
überschreiben ;-)

Wenn du die MSS jetzt also bspw. auf der supernode auf 1310 setzt, dann
wird es nur noch Frames geben die maximal 1310 + 20(TCP) + 20(IPv4) + 14
(Ethernet) = 1364 Byte groß sind.

Die Frames kommen noch in den Tunnel und dessen overhead drauf.

Es ist aber derselbe Effekt wie die MTU auf 1350 zu setzen, bloß dass es
funktioniert.

Ich hoffe es war verständlich, sonst lass uns mal irgendwann treffen,
Papier und Stift oder whiteboard nehmen,telefonieren, skypen oder was
auch immer teamviewer etc.

Für UDP funktioniert es nicht, aber es gibt so gut wie keine großen UDP
pakete. DNS darf ohne EDNS sogar nur 512Byte groß sein. teamviewer und
skype könnten probleme machen, wobei die eigentlich echt intelligent
sind und die Path-MTU selbst ausmessen.

Also, falls noch nicht klar, melden und wir machen einen Termin aus.

Viele Grüße

Sebastian

Am Mittwoch, den 10.12.2014, 18:55 +0100 schrieb Jan Lühr:
> Hallo,
> 
> vielen Dank für Deinen Input- Leider komme ich nicht wirklich
> hinterher auf Deine Ideen zu antworten - eine inhaltliche Antwort auf
> IPv6 steht leider immer noch aus :-/.
> 
> Auf jeden Fall bin ich sehr froh darüber, dass Du guten bringst.
> Kommentare siehe unten.
> 
> Am 12/10/2014 01:44 PM, schrieb Sebastian Seidel:
> > Hallo zusammen
> > 
> > Untersucht das mal weiter nach IPv4 und IPv6 denn heise, google
> > und facebooks sind bspw. über IPv6 zu erreichen.
> > 
> > Ein paar Lösungsvorschläge
> > 
> > -MSS Clamping, das funktioniert viel zuverlässiger als die MTU
> > mittels DHCP zu reduzieren. 
> > -Mallory(https://intrepidusgroup.com/insight/mallory/ ) als
> > transparent TCP/UDP proxy nutzen.
> 
> Ich bin mir nicht sicher, ob ich wirklich verstehe, was Du genau meinst.
> Das Problem ist, dass die Frames zwischen Client und ersten Router
> (aka Supernode verloren gehen).
> 
> Wahrscheinlich nutzt der Client, die eine große MTU nahe 1500, die
> dann vom Uplink-Node fragmentiert werden sollte um mit VPN+batman-adv
> overhead zum ersten Router weitergeleitet zu werden.
> 
> Hierbei sollten batman-adv und fastd Fragmentieren:
> - batman-adv, wenn der Frame nicht durch MTU des VPN-Interfaces passt
> - fastd, wenn das Paket zu groß wird um "im Stück" zum Supernode
> transport zu werden.
> 
> Ich vermute, dass von fastd Fragementierte Pakete verloren gehen. Nun
> gibt's zwei Optionen
> 
> - DSLite bei Unitymedia hat Fragementierungsprobleme
> - fastd Fragmentiert nicht richtig.
> 
> Mir ist leider nicht wirklich klar, welcher Fall eintritt. Da fastd
> upd basiert ist, sehe ich auch nicht, was PMTU-clamping der Nodes  /
> Supernodes hier gut ausrichten kann.
> Gleichzeitig gibt es auch keinen Router der die zu groß gewählte PMTU
> via ICMP quitieren könnte.
> 
> Die Frage ist jetzt, wie wir am besten aus der Chose herauskommen.
> IMHO sollten wir:
> -> Testen, ob fastd richtig Fragmentiert
> -> Eine neue Firmware releasen, bei der entweder noch batman-adv oder
> fastd Fragmentiert.
> 
> > mir fällt bestimmt noch mehr ein, aber versucht es echt mal mit
> > MSS Clamping, das löst alle Probleme mit TCP und die Probleme mit
> > großen UDP Paketen kann man noch einmal einzeln betrachten. Sollten
> > nicht so viele sein, VPN, videostreams mit RTP, RTSP funktioniert
> > bei euch wahrscheinlich eh nur interleaved.
> 
> > Hoffe das hilft.
> 
> Leder noch nicht so wirklich.
> Hättest Du Zeit und Lust, mögliche Probleme hier genau zu untersuchen
> oder mal ein Testbed aufzubauen?
> 
> Alles Gute
> Jan

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20141211/c935ca25/attachment.sig>