Hast Du dafür mal die Config (für ISC dhcpd), mit der Android & Windows das fressen? Mit DCHP Options, IIRC 26, war mein Linux-Laptop das einzige Gerät, welches eine MTU != 1500 setzte; weder Android-Geräte noch Windows-Tablets kümmerten sich darum einen feuchten Kehrricht 
Oh, man kann forcieren, daß DHCP-Parameter geschickt werden? Das werde ich mal probiere, danke! (Denn Windows & Android scheinen nicht nach der MTU-Option zu fragen. Wenn sie sie trotzdem auswerten, wäre das ja schick.)
Leider wertet zumindest Windows das trotzdem nicht aus (zu Android habe ich keine Infos). Habe hier den DHCP-Server so konfiguriert, dass die Interface MTU (option 26) mitgesendet wird. Laut „netsh interface ipv4 show interface WLAN“ wird dieser Wert aber nicht übernommen. Zumindest aber für IPv6 wird die MTU, falls sie in den Router Advertisements enthalten ist, übernommen.
@CyrusFox zu deiner DHCP Config oben bzgl. der Unterdrückung von wpad DHCPINFORM requests: Diese ist ja darauf angewiesen, dass der Client einen vendor-identifier (in diesem Fall MSFT) übermittelt. Dies ist zumindest bei einem System mit Windows 10, soweit ich das sehe, nicht der Fall. Alternativ kann man die Option auch einfach immer setzen, unabhängig vom vendor-identifiert. Habe aber keine Erfahrungen, ob das irgendwelche Nachteile hat.
Nachdem ich im neuen ICE-WLAN gesehen habe, daß dort die Interface-MTU auf 1350 gesetzt wurde: was spricht dagegen, auf den Knoten eine WLAN-MTU von 1280 zu konfigurieren, dann passen die batman-Pakete auch endlich in die 1500er Ethernet-MTU? Wahrscheinlich müßten dann die br-Interfaces auch mit 1280 laufen, aber wäre das so schlimm?
Genau diesen Weg gehen wir.
magst du da bitte deutlich mehr dazu sagen? 
Nun ja wir nutzen eine MTU von 1280.
Das wollte ich damit sagen.
eingestellt in der site.conf und am gateway - oder noch woanders?
ansonsten machen wir das schon seit Februar so.
Natürlich in der site.conf und in der fastd config auf den Gateways.
Wir seit bestehen des Netzes 09/2015.
Was @rotanid meint ist aber nicht die fastd-MTU, sondern die MTU des WLAN-Interfaces, welche bei Gluon fest auf 1500 gesetzt ist.
In der Kürze liegt nicht immer die Würze. Stelle ich die noch im Puffer liegende Frage also doch:
—8<—
… statt 1400 auf den GRE-Tunneln zum FFRL oder statt 1500 auf den wlan-Interfaces auf den Knoten? Falls letzteres, wüßte ich gerne a) wie und b) mit welchen Erfahrungen.
—>8—
Und ich muß relativieren, die 1350er MTU sah ich auf meinem Linux-Laptop; der fraß aber auch vorher schon die MTU-Hints per DHCP. Aber das …
… war ja das initiale Problem, und das würde man nur lösen können, setzte man beim Endgerät (nicht: AP) die MTU runter. Vor dem Connect. Was nicht geht. War leider verwirrt, sorry.
@paulinsche hatte irgendwie mal rausgefunden, dass Android die MTU nicht richtig ermittelt (path discovery) und hat bei uns eine Regel dafür gesetzt, sodass die für neue Verbindungen hart erzwungen wird:
-A POSTROUTING -o tun-+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss ! --mss 0:1240 -j TCPMSS --set-mss 1240
Die tun-Schnittstellen (tun-+) sind die GREs zum FFRL-Backbone.
Zum Thema MTU(s) in einem batman-adv (compat 14 oder 15) mit fastd als VPN Daemon habe ich mal folgendes Bild erstellt. Sollte soweit recht vollständig sein. Falls nicht, bin ich offen für Feedback.
Wow, mega gute Grafik. Da reicht ein einfaches Herzchen nicht. Richtig gut geworden.
Aber eine Anmerkung: Soweit ich es verstanden habe, ist im IPV6 nicht das Problem, dass die MTU an sich zu klein ist, sondern dass Android-Geräte bei der path discovery versagen. Daher oben der iptables-Befehl.
die Regel oben ist für ipv4. Für ipv6 ist es vergleichbar: der ipv6 header ist halt 40Byte, statt 20Byte groß, wie man an dem tollen Bild oben von @ohrensessel sehen kann.
Die Graphik finde ich seht gut, ich habe mich mit der mtu vor längere Zeit befasst, und dokumentiert allerdings in reiner Textform, die war nicht so übersichtlich wie der graphische Darstellung.
Die mtu sollte so groß wie nur möglich sein. Laut Daten der Graphik könnte eine mtu von 1392 ausgenutzt werden Bzw. 1384 wenn die ppoe Einkapselung der meisten DSL Anschlüsse berücksichtigt wird. Die Forderung einer mtu >= 1280 mit IPv6 ist erfüllt.
Wir haben neuerdings 2 Test Supernode. Damit war es mir möglich einige Test in eine Umgebung vorzunehmen, bei der ein tcpump auf der Gateway ohne Bauchschmerze vorgenommen kann. Als „FF-Router“ laufen bei mit ganz normale Linux Prozesse (kein Gluon), der emulierte Router verrichtet sein Arbeit in ein Network Space.
Die Ergebnisse von Speed Tests waren ursprünglich nicht berauschend. Das MSS Clamping hat mit nie überzeugt. Durch setzen der MTU auf der Bridge oberhalb von batman, sowohl auf der GW wie auf der „Router“ konnte ich die mir zur Verfügungen stehende Bandbreite (50.000/5000) beinahe vollständig ausnutzen (l2tp Tunnel).
Als mtu habe ich 1340 gewählt. Die Tests erfolgten sowohl auf der „Router“ wie mit ein per WIFI angebundenen Rechner Bzw . ein Android Smartphone. Die Ergebnisse mit der Smartphone waren zwar nicht ganz so gut wie mit der Notebook dem noch ausgezeichnet. Durch setzen der MTU an de Bridge wurde sichergestellt, dass die client ein passende mss erhalten (1300) und dass diese mss auch an den FFRL weitergereicht wird. MSS Clamping habe ich auf der Gateway noch nicht abgeschaltet, ich gehe aber davon aus dass Nachteile dadurch nicht entstehen dürften.
Die selbe Tests habe ich auch unter Ausnutzung von fastd vorgenommen. Die Performance war geringer, dies kann ich aber nicht unbedingt mit Kontextwechseln (Kernel/Userspace) in Verbindung bringen. Der Gateway ist weit davon ausgelastet zu sein.
Die Tests habe ich mit AVM Zack vorgenommen. Test mit speedof.me waren ursprünglich sehr bescheiden. Auf der Gateway lief ein uralten batman_adv (2104.3), auf mein Rechner die Version 2016.5. Nachdem batman_adv 2016.5 auf der Test Gateway installiert wurde lief auch speedof.me mit durchaus gute Ergebnisse die eigentlich durch der automatischen Wahl einen Gesprächspartner in Paris ein wenig getrübt wurde.
