Freifunk an einem Kabel Deutschland Anschluss
Hinweis: Mit der neuen Firmware Version 0.7.1/gluon-v2015.1.1 ist dieser Workaround nicht mehr notwendig. Wir haben jetzt eine MTU von 1312 eingestellt im gesamten Netz.
Wir hatten auf Vpn0 eine extra fastd instanz auf dem Port 10001 am laufen, damit sich Kabel Deutschland Kunden, die das unten beschriebene Problem haben Ihren Router damit verbinden konnten:
Einfach auf dem Router einloggen auf der Konsole und dort diese Befehle eingeben:
uci set fastd.mesh_vpn_backbone_peer_ffki_vpn1.enabled=0 uci set fastd.mesh_vpn_backbone_peer_ffki_vpn2.enabled=0 uci set fastd.mesh_vpn_backbone_peer_ffki_vpn3.enabled=0 uci set fastd.mesh_vpn_backbone_peer_ffki_vpn4.enabled=0 uci set fastd.mesh_vpn_backbone_peer_ffki_vpn0.remote='ipv4 "vpn0.freifunk.in-kiel.de" port 10001' uci set fastd.mesh_vpn.mtu=1370 uci commit wifi
ev. einmal neu starten
Hintergrund
Kabeldeutschland Nutzer kennen das Problem: Manche Verbindungen über das Freifunk Netz funktionieren nicht oder nur sporadisch. Das Problem besteht ausschliesslich bei KabelDeutschland/Unitymedia Internetanschlüssen, die sogenanntes DSLite benutzen. Das ist eine Methode, um ipv4 und ipv6 gleichzeitig zu betreiben und spart beim Provider offizielle ipv4 Adressen, die in diesen Tagen ein knappes Gut sind.
IPV6 wird hier ganz normal ausgeleitet. IPV4 jedoch wird “huckepack” auf IPV6 zu einem zentralen Router beim Provider geschickt, wo es dann als IPV4 wieder “rausfällt”. Leider funktioniert auf diesem Weg die automatische Aushandlung maximal möglicher Paketgrößen (maximum transmission unit, MTU) nicht sauber. Eine mögliche Lösung wird eine spätere Version des von uns verwendeten VPN Dienstes “fastd” liefern. Da es aber wohl noch einige Zeit dauern wird, bis fastd v18 stable kommt, haben wir einen temporären Fix für das Problem. Dafür haben wir an den Gateways nun eine zweite fastd Instanz mit einer kleineren MTU gestartet. Dies verhindert die Path MTU Discovery Probleme bei DualStack Lite Anschlüssen.
Kabel Deutschland hält sich hier nicht an die RFC für ICMP.
Wenn mein Router ein UDP-Paket größer als 1370 Byte empfangen soll, dann filtert der Hitron Router das Paket und sendet an den Absender die Fehler-Nachricht Typ 3 (Destination Unreachable) Subtyp 13 (Communication administratively prohibited) Dies ist nicht korrekt, richtig wäre Typ 3 Subtyp 4 (Fragmentation required, and DF flag set)
Siehe https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
Wenn der korrekte Nachrichtentyp gesendet würde, dann würde mein angeschlossener Router auch korrekt arbeiten