ich habe soeben einen neuen Freifunk-Knoten auf einem TP-Link WR841N v9 installiert, mit dem aktuellen stabilen Image von Freifunk Wuppertal. Der VPN-Tunnel wird korrekt aufgebaut, sobald man aber einen Download startet, gehen die ersten paar KB noch zügig über die Leitung, dann nimmt die Geschwindigkeit rapide ab und der Download und bricht nach ca. einer Minute ganz ab. Der Abruf von Websites dauert ebenfalls eine halbe Ewigkeit.
Im Router-Log finden sich dann massenhaft dieser Einträge, teilweise mehrere Dutzend davon pro Sekunde:
Sun Jan 4 07:14:10 2015 daemon.warn fastd[1179]: recvmsg: Resource temporarily unavailable
Lädt man Daten hoch, bekomme ich knappe 10 MBit durch die Leitung, was meinem Internetzugang entspricht. Dabei werden auch keine Warnungen im Log ausgegeben.
Ich habe einen 200/10 MBit Internet-Zugang von Unitymedia mit DS-Lite, der VPN-Tunnel wird über IPv4 aufgebaut, da die Wuppertaler Backbones ja noch Probleme mit IPv6 haben. Ob IPv6 ist in der Freifunk-Konfiguration aktiviert oder deaktiviert ist, macht keinen Unterschied. Gehe ich direkt über die FritzBox ins Internet, funktioniert alles einwandfrei. Auch der (nicht empfohlene) Wechsel des WLAN-Kanals bringt keine Besserung.
Dass der Router eine schwache CPU hat, ist mir bekannt und dient nebenher als natürliches Bandbreitenlimit. Da aber für Up- und Download prinzipiell ähnliche Leistung zum Ver- und Entschlüsseln benötigt wird, und der Upload bei 10 MBit liegt, dürfte die CPU-Leistung nicht die Ursache sein.
Mache ich etwas falsch, liegt das am Backbone, oder ist die Hardware tatsächlich dann schon am Ende?
Das liegt nicht am Backbone sondern an der Wupper-Infrastruktur. Mein Ticket (#767071), der eine Abhilfe des Problems bewirken sollte, ist seit 2015-08-14 unbeantwortet. Weitere Maßnahmen werden über das Ticketsystem erbeten, nachdem dieser Ticket bearbeitet wurde. Mir ist das jetzt egal … kotzt Euch beim Verein aus.
Im Übrigen sind nun die Root-Server des Vereins das Nadelöhr, da der Verein keine anderen Server anbindet …
Nachdem ich etwas Zeit hatte, das Problem näher zu betrachten, liegt das Problem offenbar an DS-Lite. Verschiedene Quellen nennen hier unterschiedliche empfohlene Maximalwerte, je nach Anbieter und verwendeter VPN-Technik. Für fastd habe ich jedoch keine höheren Angaben als 1406 Bytes gefunden, oft wird als sicherer Wert nur 1312 Bytes angegeben (in einigen Threads anderer Communities hier im Forum). Da die fastd-Server von Wupper alle mit 1426 laufen, könnte das knapp zu viel sein.
Ist es möglich, testweise irgendwo eine fastd-Server-Instanz mit niedrigerer MTU aufzusetzen? Dann könnte ich prüfen, ob der VPN-Tunnel dann stabil arbeitet. Einfach die Client-MTU reduzieren klappt ja nicht.
Abgesehen davon, dass derzeit Server in der Domäne Wupper fehlen, was auch für die Geschwindigkeit und Paketverluste verantwortlich sein könnte, ist das Problem mit der MTU bekannt. die 1426 wurde gemäß Anleitung vor einer halben Ewigkeit gewählt. Alle bekannten Unitymedia-Anschlüsse haben dabei mitgespielt. Ein paralleler Betrieb von mehreren MTUs wird an der Instabilität von Batman scheitern. Die einzige Möglichkeit derzeit ist die gesammte Freifunk-Wolke anzureißen und von Vorne zu beginnen. Da ich dafür keine Zeit habe und dies auch auf Grund der Fülle der Freifunkknoten nicht möglich ist, ist dies keine Option. Es bleibt also abzuwarten, bis Batman in dieser Hinsicht stabilisiert wurde. To do Vorschläge:
sprich mit deinen Nachbarn, ob nicht jemand anderes einen unterstützten Internetanschluss zum Freifunk beisteuern kann
schaue, ob Du einen Link*) zu einer mit Freifunk versorgten Gegend einrichten kannst (siehe Karte)
behebe den Fehler in Batman
Fahre selbst einen Server, auf dem Du die fastd-Verbindung mit der gegebenen MTU auf eine für Dich passende MTU änderst. da dieser Server nicht so einen hohen Datenaufkommen aufweisen wird ist die Chance den Fehler in Batman zu Provozieren zwar minimiert aber gegeben.
Fange für neue Vorhaben einen neuen Thread im Forum an, wenn Du dabei Hilfe brauchst.
*) WLAN-Langstreckenverbindung mit Richtfunkantennen auf Dächern, Masten usw.
Wenn DS-Lite-Anschlüsse ihre Verbindungen zu V4-Adressen machen, dann ist zusätzlicher Overhead fällig.
Ich würde im Knoten prüfen, ob die fastd-server per IPv6 erreicht werden können.
In Szenarien mit „kaskadierten Heim-Routern“ funktioniert das meist nicht. Inbesondere wenn der Kabeltv-Zwangsrouter ein TC7200 ist, der keine IPv6-Prefixe deligieren kann.
Dann bekommt die Fritzbox (oder das OpenWRT) hinter dem Technicolor zwar noch eine öffentliche IPv6, aber kann seinen Clients widerum (also z.B. dem Freifunk-Router) kein (funktionsfähiges) IPv6 bereitstellen.
Von den Frankfurtern gibt es das Auto-MTU-Script.
Wenn man also sowieso schon „Übung“ hat mit mehreren Fastd-Instanzen auf einem Supernode, dann wäre das evtl. lohnen.
der Server stürzt reproduzierbar ab, wenn ich mehrere verschiedene MTUs nutze … darüber habe ich bereits berichtet. Ich habe derzeit keine Zeit für Experimente und bin froh, dass das Netz halbwegs benutzbar ist.
Die fastd-Instanzen hattest Du mit ihren tun-devices auf einen gemeinsamen bat gelegt oder noch eine normale br-bridge dazwischen?
(Mir ist gerade nicht klar, was schlimmer ist
es gibt keinen unterschiedlichen MTU innerhalb einer fastd-Instanz … ich wüsste nicht, dass man verschiedene MTUs miteinander Brücken könnte … Batman wurden die unterschiedlichen Schnittstellen mitgeteilt → Absturz nach einer Weile
Nachdem dank Philipps nächtlichem Einsatz gestern Abend jetzt auch die IPv6-DNS-Einträge für die Wupper-Server aktiv sind, reicht die MTU über natives IPv6 aus.
Um die Wupper-Server auch darüber anzusprechen, habe ich in /etc/config/fastd bei allen Peers in der „list remote“-Einstellung „ipv4“ auf „ipv6“ geändert und fastd neu gestartet, danach gingen alle Pakete sauber durch.
Die gemessenen maximalen MTUs für Unitymedia mit DS-Lite sind übrigens 1432 für IPv4 (mit ICMP, ggf. weniger aufgrund von zusätzlichen Header-Optionen), sowie 1452 für IPv6.
Da bei mir im Moment zwei Internetanschlüsse im Haus sind, habe ich gestern für GM umfangreiche Tests gemacht und kann deine Aussagen bestätigen.
Unitymedia Anschluss (DS-Lite):
Verbindung zu wupperX Servern ist nur nutzbar, wenn fastd remotes per ipv6 erreichbar sind. GM wupper nutzt im Moment eine MTU von 1426.
Verbindung zu radeX Server, die nur per ipv4 erreichbar sind, ist erst bei MTU 1364 nutzbar. Mit 1426 oder 1406 klappt es nicht.
1und1 Anschluss (ADSL 2+):
Die Gegenprobe mit diesem Anschluss und MTU 1426 klappt mit allen Servern. Die Verbindung wurde dabei über ipv4 aufgebaut, wie auch schon die ganze Zeit
Frage:
Im Gegensatz zu kblaschke habe ich einfach die Einschränkung „ipv4“ komplett weg gelassen.
remotes = {
'ipv4 "2.wupper.ffrl.de" port 42477',
'ipv4 "wupper2.freifunk-radevormwald.de" port 42477',
},
Somit steht jetzt nur noch
remotes = {
'"X.wupper.ffrl.de" port 42477',
'"wupperX.freifunk-radevormwald.de" port 42477',
},
in der site.conf.
Kann ich das für alle wupper Server so machen, oder sind nur bestimmter für ipv6 reserviert? Oder sollen wir langfristig lieber die MTU senken?
Und danke an phip fürs verfügbar machen per ipv6. Sonst würden sicher auch bei uns in Zukunft neuere unitymedia Anschlüsse im Moment außen vor bleiben.
die Server sind seit der neuen Servereinrichtung über IPv6 verfügbar, also seit einem dreiviertel Jahr.
das ist laut Anleitung legitim und kein Fehler.
Das kannst Du für alle so machen, wenn es funktioniert. Alle fastds antworten auf IPv6.
mir ist das immer noch ein Rätsel, wie das mit so einer hohen MTU durch IPv6 durch passt. Ich habe noch keine Zeit gefunden dies zu analysieren. Wird da wirklich nichts abgeschnitten?
Muss man dafür in die Datenpakete schauen, oder wie kann man das feststellen?
Das Netz in GM ist aber schon länger nicht mehr so performant wie früher. Unabhängig ob der Anschluss über ivp4 oder ipv6 läuft. Ich will das bei Gelegenheit mal mit ein paar Speedtests näher eingrenzen.
der Flaschenhals sind die überlasteteteteteteteteteteteteteteten FFRL-Server. Ich habe tief in die Trickkiste gegriffen, um diese Überlastung irgendwie zu überkommen. Als die Jungs aber angefangen haben mit dem Backbone zu spielen, habe ich Berlin komplett deaktiviert, da ich Beschwerden über nicht funktionierende Gateways erhielt …
