zum testen gibt es ja bereits openwrt lösungen, für die server sollte das bauen kein problem sein …
wer für gluon bauen will … dem kann der hinweis hier helfen
zum selber bauen …
at this moment i add manually openwrt/packages@35cb289 https://github.com/openwrt/packages/commit/35cb289
( just add directory and Makefile gluon/packages/openwrt/net/wireguard/Makefile and than build fw or/and modules )
und man sollte die Version noch pimpen PKG_VERSION:=0.0.20160708.1
derzeitiges problem kernel >4.1 : #error „WireGuard requires Linux >= 4.1“
# aus dem make log
make[5]: Entering directory '/media/freifunk/firmware/gluon/packages/openwrt/net/wireguard'
rm -f /media/freifunk/firmware/gluon/build/ar71xx-generic/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/stamp/.wireguard_installed
/media/freifunk/firmware/gluon/build/ar71xx-generic/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/WireGuard-experimental-0.0.20160708/src/wireguard.h:11:2: error: #error "WireGuard requires Linux >= 4.1"
make[5]: Leaving directory '/media/freifunk/firmware/gluon/packages/openwrt/net/wireguard'
package/Makefile:191: recipe for target 'package/feeds/module_openwrt/net/wireguard/compile' failed
make[4]: *** [package/feeds/module_openwrt/net/wireguard/compile] Error 2
im moment geh ich davon aus, das erst der kernel in gluon auf 4.1++ gebracht werden muss, soweit ich das verstanden hatte, sollte das mit v2016.2 kommen
Dann hat Wireguard (als L3-Protokoll „nativ“ auf einem 841er netto 40MBit/s.
Man könnte dann also anfangen zu überlegen, ob man das „statt Tunneldigger“ benutzt, um L2TP da durchzuschleusen und L2TP „mit Verschlüsselung“ zu bekommen.
@Handle bitte diesen Thread auch lesen und dann interpretieren oder glauben - was soll das sein blanco? @CyrusFox wireguard ist erstmal nen l3 tunnel … was man da dann mit macht - mal sehen, wir wollten probieren ob man damit fastd ersetzen kann, dazu braucht man on top l2tpv3 und dann wie bei fastd auch batman. Wenn man das netz so behalten will wie es ist.
@CyrusFox wireguard ist erstmal nen l3 tunnel … was man da dann mit macht - mal sehen, wir wollten probieren ob man damit fastd ersetzen kann, dazu braucht man on top l2tpv3 und dann wie bei fastd auch batman. Wenn man das netz so behalten will wie es ist.
Das wäre natürlich eine Möglichkeit, aber sinn machen tut das nicht. Da dann eher darauf hin arbeiten das Wireguard auch Layer2 Tunnel unterstützt. Tunnel in Tunneln ist generell keine gute Idee da man später mit einer MTU unter 1300 arbeiten muss da heute oft DS-Lite verwendet wird. Für Unitymedia nutzen wir schon eine MTU von 1364, davon 32 Bytes abgezogen für den Batman Header und man landet bei 1332.
IPv6 braucht mindestens 1280 Bytes, kleiner als das sollte man also nicht gehen. Wenn man Gretap im Wireguard Tunnel verwendet würde es gerade noch so passen mit 14 Bytes übrig. Mit L2TPv3 via UDP klappt es nicht ohne das aller IPv6 Traffic fragmentiert.
Du hast das doch selbst geschrieben im von @adorfer verlinkten Github-Issue:
es gibt neues zu berichten, unter anderem testet jason (wireguard dev) das nun selbst an einem 841 und wir sind einige weitere Schritte gekommen mit den MIPS oom Problemen, und bekommen im Moment blanko 40 Mbit mit wireguard durch die leitung.
@rubo77 kam auf das „ohne encryption“ vermutlich, weil man die bei fastd ja deaktivieren kann und man im Kontext von fastd wesentlich geringere Geschwindigkeiten bei aktivierter Verschlüsselung im Hinterkopf hat. Du schreibst dann, was Wireguard ist, aber nicht, ob der Test nun mit Verschlüsselung durchgeführt wurde oder ohne (ob man die bei Wireguard überhaupt deaktivieren kann, weiß man als jemand, der nicht in der Materie drin steckt, erst einmal nicht).
Vor dem Hintergrund ist mir nicht direkt klar gewesen, was du mit deinem
blanko 40 Mbit
ausdrücken wolltest.
Anstatt das kurz für jeden klarzustellen, kommst du in dem gleichen ruppigen Tonfall daher, mit dem du auch schon im verlinkten Github-Issue angeeckt bist und der Leser ist nach der Lektüre deines Beitrags genauso schlau wie vorher. Für sonderlich zielführend halte ich das nicht.
@handle ich weis ja nicht, will niemandem auf die Füße dappen - allerdings find ich komisch das dir nichtmal klar zu sein scheint was wireguard überhaupt ist. hier mal erster Satz wireguard.io Seite WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography - meine Kritik geht dahin das du scheinbar nicht gelesen hast was geschrieben wurde und dann glaubst/vermutest/whatever. Das du dir ein themenfremdes Anecken aus dem github-issue hier zu eigen machst um dein Argument zu stützen gibt dir auch nicht mehr recht. (dort ging um „Mißverständnisse“ welcher Durchsatz auf welchen Geräten erreicht werden kann mit der damaligen Version - unaligned Memmory, Mips32c)
Wie gesagt, ausser zu sagen mach deine Hausaufgaben - will ich niemanden auf die Füße dappen.
edit Das mein letzter nicht inhaltlicher comment dazu
@fuzzle ich weiß nicht, warum du dich scheinbar schwer damit tust, thematisch weiterführend auf die Beiträge einzugehen und abermals das Äquivalent von „RTFM“ herunterbetest. Würde dir ein Zacken aus der Krone brechen, wenn du inhaltlich auf @rubo77 oder meinen Beitrag eingehst? Was WireGuard ist hat in groben Zügen hier glaube ich jeder verstanden. Hier ging es aber um eine kleine Detailfrage, die du mit ein paar Worten hättest beantworten können, was du aber immer noch nicht getan hast.
vermutlich ist die Diskussion um Geschwindigkeit etc. eh besser hier aufgehoben, dort sind auch scripte um mit 2 laptops/computern und 2 routern wie dem 841 und iperf eigene Tests zu machen.
edit: @Mitsch wir testen nur auf 841 , da das eh auf diesen schwachen kisten laufen können muss - das ist auch gut so, so sind Fehler die andere mit den 1043 nichts hatten überhaupt erst aufgefallen (siehe Mips 74k 32k ) - evtl machen wir noch 940 und 842 - wenn du das machen willst bin ich sehr auf deine Zahlen gespannt. edit: @Handle … blanko geht durch das kabel etwa 93Mbit mit reinem Routing (was nix mit wireguard zu tun hat). Mit Wireguard scheints 40 aktuell - wireguard kann nur 1 Art von Crypto die is ähnlich zu chachapoly1305 in fastd und ist nicht optional.
Testet Ihr das mal noch mit z.B. einem dicken 1043 v2?
Würde mich wirklich interessieren, was dabei rum kommt…
Hab jetzt schon Angst, dass die 50MBit/s VDSL bald mit Freifunk gefüllt werden könnten…
es gibt im Gluon einen holprigen aber brauchbaren branch Namens LEDE - der ist hochgradig experimentell , aber funktioniert - man kann daraus also sein Gluon bauen (Achtung - target ist dann ar71xx-tiny nicht generic) - damit bekomme ich lauffähiges meshendes „normal“ Freifunk
ich kann das aber ohne fastd bauen (mesh-vpn pakete) und gleich mit wireguard und kmod-gre und kmod-gre6 … das passt soweit auch auf einen 841er (und entspricht unwesentlich mehr als fastd-mesh paket und config) . dann sollte ich einen wireguard tunnel bauen können, darin einen gretap tunnel und darauf dann batman. Die Pakete hab ich so gebaut bekommen, muss dass nur die Tage testen.
ich hab noch das Makefile von wireguard so angepasst, das es wirklich die letzte Version baut 161116.1.
war ziemlch straight forward.
ick freu mich , und neoraider und andere bestimmt auch , wenn Gluon-LEDE viele Menschen mal anfassen … also das LEDE branch bauen - unabhängig davon ob man da was mit wireguard reinbastelt. Damit bekommt man dann 4.4 Kernel- und erster probelauf war deutlich weniger RAM verbrauch - (nach 2 Stunden laufen … 60% im vgl zu 80%++)
ar71xx-tiny sind ar71xx-generic devices, die nur 4 MB Flash besitzen, soweit ich das auf den ersten Blick sehe. Je nach Modell möchte man also immernoch ar71xx-generic zum basteln bauen.
korrekt, nur das ich immernoch den fokus lege auf die 4 mb, mehr is schön, aber da will ich das zum laufen bringen, selbst wenn es minimal ist. wir haben 250++ 841 Router in unserem Netz, auch wenn es so aussieht das wir nun auf 842 mit 8 mb und 940 (wobei der auch meist 4mb hat) umsteigen.
gerade kam eine Email (neben der ganzen Diskussion im Vorfeld)
in den letzten Wochen ist viel passiert zu Wireguard:
[ANNOUNCE] Snapshot 0.0.20161216 Available
With the recent changes to add alignment in the headers, I now get 60
megabits per second on a super crappy TL-WR841N board (QCA9533)
transmitting over the internet. This is awesome performance – a good
milestone for little CPUs.
awesome, würd gern auf dem 33c3 mal ein paar Stunden dazu brainstormen, und gerne selber etwas zu den neueren babel Mesh Protokoll lernen, und mich über fastd/wireguard Erfahrungen austauschen.
Wow, 60mbit/s auf 'nem 841 sicher verschlüsselt, damit wäre das Thema Tunnel/VPN durchgespielt.
Ich nutze WG bisher nur für statische Tunnel und es tut richtig geil. Vermutlich fehlt für Freifunk ein Management-Protokoll zum dynamischen&sicheren Setup eines Tunnels. So wo der Node sich melden kann, Parameter aushandelt und dann werden auf beiden seiten die Interfaces angelegt und wieder abgerissen. Also quasi Tunneldigger für WG. Sollte wenn ich das richtig verstehe über das Netlink-Interface auch mit einem eigenen Daemon machbar sein, ohne Shellscripterei um das wg Tool herum.
Interessant wäre wie das performt mit 'nem l2-tunnel drin, also l2tp oder gretap durch den wg-Tunnel. Damit könnte man das Thema WG erstmal vom Thema Babel entkoppeln.
- also mal real Dinge bauen
