Probleme mit IPTV (Entertain) über WLAN mit DDWRT/OPENWRT-Firmware auf dem Router? Lösung!

Installiert man auf einem Router die alternativen Firmwares DDWRT oder OpenWRT kann man darauf einige Funktionen aktivieren, die mit der Herstellerfirmware nicht vorgesehen waren.
Unglücklicherweise fängt man sich damit aber auch das Problem ein, dass die Accesspointfunktion in Mitleidenschaft gezogen wird und IPTV-Streams wie T-Entertain über WLAN nicht mehr richtig funktionieren oder stocken. Bei 802.11n WLAN-Protokoll basierten Routern, die problemlos 300 Mbps Bruttodatenrate erzielen unverständlich, zumal ein Speedtest schnell zeigt, dass die Bandbreite selbst nicht das Problem ist.

Ursächlich ist eine unglückliche Einstellung in den erweiterten WLAN-Settings bzgl. der Paketgröße über WLAN. Sie führt dazu, dass Pakete beispielsweise sehr stark fragmentiert werden und ein IPTV-Paket dann in 2 oder 3 WLAN-Pakete (richtig wäre 802.11n-Frame) eingepackt werden muss, weil es die „Fragementation Treshold“, also die Schwelle aber der fragmentiert wird, überschreitet. Die verursacht bei einem UDP-IPTV-Livestream ohne Bufferung natürlich Verzögerungen, instabile Paketlaufzeiten und reduziert den Durchsatz ein klein wenig. Moderne TCP-basierte Anwendungen erkennen diesen Umsatz und passen die Paketgröße durch Reduktion an, doch Entertain beherrscht dies nicht und ist ohnehin UDP-basiert.

Der Fehler kann aber auch in einer zu großen Paketgröße liegen, wobei der Router dann wartet, bis er ausreichend IPTV-Pakete gesammelt hat, um sie gemeinsam in eine WLAN-Datenpaket zu verpacken und zu senden. Der Client empfängt dann zwar mehrere Pakete auf einmal aber eben mit Verzögerung und u.U. ungleichen Laufzeiten. Geht ein WLAN-Paket durch Störungen fehlen gleich mehrere IPTV-Pakete und es gibt Bildstörungen oder Aussetzer.

Hintergrund Paketgrößen und MTU:
Ein Ethernet (LAN)-Frame bzw. Paket ist normalerweise 1518 Bytes groß (VLANs und Q-in-Q-tagging außen vor gelassen). Zieht man den Header ab, so verbleiben 1500 Bytes, was auch als maximum transmission unit (MTU) bezeichnet wird.
Beim Internetzugang über xDSL werden die Pakete mittels PPPoE-Protokoll eingepackt, was weitere 8 Bytes kostet
Bei der kabelgebundenen Übertragung tritt das Problem übrigens nicht auf, da die maximale IP-Paketgröße aus dem Internet bei 1500 Bytes MTU (Ethernet-Paketgröße) abzüglich PPPeE-Header bei 1492 Bytes liegt.
Beim Versand eines IP-Datenpaketes fallen für den IP-Header 20 Bytes weg, was die Nutzlast auf 1472 Bytes reduziert.
Mittels ping-Kommando kann man ein ICMP-Datenpaket versenden es mit do-not-fragment-Flag versehen, um die maximale Paketgröße zu ermitteln.
Da ICMP wiederum einen Header von 8 Bytes hat, führt folgendes Kommando auf einem DSL-Anschluss zum Erfolg:
ping -f spiegel.de -l 1464

Die Lösung liegt in der Anpassung zweier Werte in den WLAN-Einstellungen der alternativen Firmwares DDWRT/OPENWRT.
Die 802.11n-Pakatgröße beträgt normalerweise 2346 Bytes. Es wird deutlich, dass ein IP-Datenpaket mit maximal 1472 Bytes ohne Fragementierung genau einmal reinpasst. Für ruckelfreies IPTV sollte der Router also genau ein IP-Paket in ein WLAN-Paket packen und dieses dann sofort abschicken. Ein Entertain Multicast-IPTV-Paket ist typischerweise 1370 Bytes groß (Protocol 2048 (ip), IP Protocol 17 (udp), Size 1370, IP Packet Size 1356, IP: IP Header Size 20, TOS 32,..)
Der Wert müsste also so gewählt werden, dass ein Entertain-Paket nicht fragmentiert wird und zugleich nicht zwei Entertain-Pakete in einem WLAN-Paket landen. Zugleich sind aber weitere IP-Pakete auf dem WLAN-Interface unterwegs diese beanspruchen durchschnittliches nicht die volle Größe. Darüber hinaus senden PCs im lokalen Netz 1500 Bytes großes Ethernetframes.
Es lässt sich daher keine Patentlösung finden, die sich an einer bestimmen Paketgröße orientiert.
Man ist daher gezwungen, die WLAN-Datenpaketgröße so klein zu wählen, dass sowohl typische Standard-Ethernetframe als auch IPTV-Datenpakete zügig abtransportiert werden.

Neben der Fragmentierungsschwelle verwendet das WLAN-Protokoll 802.11n noch das RTS-CTS (Request to Send / Clear to Send)-Protokoll u.a. um zu prüfen, ob der Kanal frei ist und um Kollisionen und damit einhergehende verlorene oder defekte Pakete zu vermeiden. Die Einstellung „RTS Treshold“ legt fest, ab welcher Paketgröße WLAN-Accesspoint und Client das RTS-CTS-Protokoll verwenden müssen. Die WLAN-Paketgröße muss also kleiner oder gleich der RTS Treshold liegen, sonst wird letztere niemals überschritten.

Den Lösungsvorschlag habe ich nach einiger Recherche hier gefunden und er basiert darauf, Standard-Ethernet-Paket mit  1500 Bytes Größe (=MTU) in zwei WLAN-Pakete aufzuteilen und empfiehlt eine Fragmentation Treshold von 784 Bytes (1500 Bytes Framesize / 2 = 750 Bytes Nutzlast + 34 Bytes Overhead für Header).
Dem geht einher, das RTS-CTS-Protokoll ab einem Drittel Ethernet-Frame zu verwenden, also einer RTS Treshold von 534 Bytes.

Im Falle der Entertain IPTV-Datenpakete, die 1370 Bytes groß sind, wird das RTS-CTS-Protokoll verwendet und es wird auf zwei WLAN-Pakete fragmentiert.