wireguard : für gluon openwrt?

[viisauksena]

ich würd das gerne haben , bzw bauen zum testen .. any way for support ? das angebotene Packet funktioniert nativ natürlich nicht

https://www.wireguard.io

# got email : baptiste@bitsofnetworks.org
# wireguard@lists.zx2c4.com
# wireguard for openwrt 

On Wed, Jun 29, 2016 at 01:24:23PM +0200, Baptiste Jonglez wrote:
> Hi there,
>
> I am working on an OpenWRT/LEDE package for wireguard.  It's mostly done,
> but I want to test it before pushing it to the repositories.  Hopefully, I
> will be able to do that this week-end.

Here is the package finally:

  https://github.com/openwrt/packages/blob/master/net/wireguard/Makefile

The built packages should be available in the snapshots quite soon, e.g.:

- wireguard-tools: https://downloads.lede-project.org/snapshots/packages/mips_34kc/packages/
- kmod-wireguard: https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/packages/

If you are running a recent snapshot version of Lede, this should be
enough if you have a compatible kernel:

  opkg install wireguard-tools kmod-wireguard

If you want build it yourself, you need this patch for proper dependency
handling, it has been included in Lede two days ago:

  https://git.lede-project.org/?p=source.git;a=commit;h=1d15a96b29dcd0947690951a7c36aead79a27129

One final note: there is no "multi-threaded" support for now, sorry Jason.
So, if you run this on your super modern 128-cores router, don't expect
exceptional performance   Well, you could always hack your kernel config
to enable CONFIG_PADATA and CONFIG_SMP before building wireguard.

Other than that, feedback on the packages is welcome!

Baptiste

[A-Kasper]

Im Labor gab es die Idee auch schon. Wireguard ist aber imho layer 3 Protokoll. man müsste also darüber einen l2 tunnel aufbauen, oder auf l3 mesh umsteigen. letzteres wäre imho sinnvoll. Am 05.07.2016 00:49 schrieb "viisauksena" notifications@github.com:

ich würd das gerne haben , bzw bauen zum testen .. any way for support ? das angebotene PAcket funktioniert nativ natürlich nicht

got email : baptiste@bitsofnetworks.org

wireguard@lists.zx2c4.com

wireguard for openwrt

On Wed, Jun 29, 2016 at 01:24:23PM +0200, Baptiste Jonglez wrote:

Hi there,

I am working on an OpenWRT/LEDE package for wireguard. It's mostly done, but I want to test it before pushing it to the repositories. Hopefully, I will be able to do that this week-end.

Here is the package finally:

https://github.com/openwrt/packages/blob/master/net/wireguard/Makefile

The built packages should be available in the snapshots quite soon, e.g.:

• wireguard-tools: https://downloads.lede-project.org/snapshots/packages/mips_34kc/packages/
• kmod-wireguard: https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/packages/

If you are running a recent snapshot version of Lede, this should be enough if you have a compatible kernel:

opkg install wireguard-tools kmod-wireguard

If you want build it yourself, you need this patch for proper dependency handling, it has been included in Lede two days ago:

https://git.lede-project.org/?p=source.git;a=commit;h=1d15a96b29dcd0947690951a7c36aead79a27129

One final note: there is no "multi-threaded" support for now, sorry Jason. So, if you run this on your super modern 128-cores router, don't expect exceptional performance Well, you could always hack your kernel config to enable CONFIG_PADATA and CONFIG_SMP before building wireguard.

Other than that, feedback on the packages is welcome!

Baptiste

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/freifunk-gluon/gluon/issues/816, or mute the thread https://github.com/notifications/unsubscribe/AIA7UnOWNNL6JoAdH_Gk56s11E7d8pCbks5qSY4XgaJpZM4JErin .

[viisauksena]

@A-Kasper wir würden das benutzen um endlich verschlüsselt l2tp zu benchmarken (statt das unverchlüsselte tunneldigger konzept) - erstmal nur zwischen den Supernodes. Es gab auch überlegungen die Meshwolken viel viel vile kleiner werden zu lassen und vor, bzw bei den einzelnen Supernodes zu terminieren (für Freifunk mal als vision/idee zum testen).. aber das ist hier erstmal alles offtopic und was für https://forum.freifunk.net

[viisauksena]

zum selber bauen .. at this moment i add manually openwrt/packages@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

# 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

[viisauksena]

@NeoRaider kannst du mir einen überblick/einblick geben wie das mit gluon 2016.2 und dem kernel sein wird, ich scheu mich davor das selber zu machen (konkret einen neueren openwrt commit im module benutzen), ich gehe davon aus das ich dann alle patches durchsehen muss.

[neocturne]

Da wireguard nur Layer 3 kann, ist es zur Zeit für Gluon uninteressant. Das ist eher eine längerfristige Sache.

[viisauksena]

@NeoRaider : versteh ich nicht, was spricht dagegen mesh nur in lokalen wolken zu haben und uplinks zu servern nicht mehr im mesh zu haben .. bzw. das extra zu regeln. das layer2 netz zum server bringt mir ja erstmal recht wenig .. aber die debatte will ich hier garnicht aufmachen (natürlich hat das impact auf karten, und community strukturen) .. ich würd das halt gerne ein wenig testen, und dazu am liebsten gleich mit einem aktuellen gluon - das geht aber nur wenn ich den kernel auf 4.1++ bringe, daher nochmal meine frage, ist das angedacht für 2016.2? natürlich könnt man auch den anderen weg gehen und openwrt soweit gluon ähnlich machen das es passt.

[neocturne]

@viisauksena, grundsätzlich spricht nicht viel gegen Netztopologien mit lokalen Mesh-Wolken und einem Layer-3-VPN (es gibt schon ein paar technische Nachteile, aber eben auch Vorteile). Allerdings unterstützt Gluon solche Topologien aktuell nicht, und Support dafür wird deutlich aufwändiger sein als nur ein neues VPN-Tool hinzuzufügen.

Gluon 2016.2 ist noch Chaos Calmer, also Kernel 3.18. Nach dem Gluon-Release planen wir, Gluon auf LEDE umzustellen, das im ersten Release Kernel 4.4 verwenden wird.

[viisauksena]

mittelmässige news .. wir haben wireguard mal auf dem aktuellen LEDE für den 841Nv11.1 getestet .. https://forum.freifunk.net/t/lede-test-wireguard-und-blanko-durchsatz-tp841nv11-1-und-bug/13163 denk damit is dieser issue auch erstmal auf pause gestellt - wir testen mal weiter

[RubenKelevra]

Wir haben auch einen Test mit Wireguard gemacht, mit Archer C7 v2:

"netto ziemlich genau 40 Mbit/s down und 9 Mbit/s up (ohne Wireguard sind 43,5/9,33 Mbit/s gemessen worden)"

Das klingt schon deutlich interessanter als eure Ergebnisse, denn Fastd macht ja schon 13 MBit/s auf den 841igern :)

[viisauksena]

@RubenKelevra .. versteh nicht ganz, geh mal davon aus ihr habt das mit neuestem OpenWRT/LEDE gemacht wegs dem Kernel ... wenn der CPU mässig besser ausgestattet ist kann das ja gut sein - fastd und wireguard machen ziemlich ähnliche crypto-magie soweit ich das verstanden hab. Daher verwundert das auch kaum das die beide gleich "gut" abschneiden. Damit ist aber auch ein wenig widerlegt das ein (Durchsatz) Problem von fastd die Kontextswitche von USER-space zu KERNEL-space sind. Wie gut macht sich denn fastd auf dem C7 ... und wenn du die Tests besser beschreibst, magst du das nicht auf wireguard Liste und ins freifunk forum als feedback schreiben?)

https://forum.freifunk.net/t/lede-test-wireguard-und-blanko-durchsatz-tp841nv11-1-und-bug/13163/9 https://forum.freifunk.net/t/841v11-fastdv18-841v11-iperf-tests/13308

Es ist in jedem Fall ein gutes Package für verschlüsselte Tunnel (wobei, habt ihr den auch mal mit udp voll gepumpt?) - für gluon kommt das aber sicher nicht in Frage bevor der Kernel 4.1++ ist .. und auch dann ist das eher ein LEDE/Openwrt schmankerl als ein echter direkter Ersatz für das bisher batman-adv basierende Gluon. Ich seh keinen default gewinn das in gluon einpflegen zu wollen der über Lede/Openwrt hinaus geht.

wenn das niemand anders sieht, mach ich das dann hier bald zu.

[viisauksena]

das kam letztens in der Wireguard Mailinglist ... durch bessere Speicherausnutzung und geschickteres Nutzen der Register, ist durchaus sehr viel mehr performance drin... das könnte aber auch gleich für fastd gelten .. ich habs noch nicht ganz durchstiegen aber @NeoRaider könnte das interessieren https://lists.zx2c4.com/pipermail/wireguard/2016-September/000398.html

[RubenKelevra]

Ich kann dir nicht groß folgen...

Jedenfalls war mein Punkt: in eurem Setup ist was kaputt, von 12 MBit fastd geht's auf 45 Mbit mit Wireguard auf der selben Hardware. Wenn du sonst noch konkrete Fragen hast verschachtel sie nicht irgendwo im Fließtext.

[viisauksena]

@RubenKelevra - ne das kann ich mir kaum vorstellen, beschreib doch mal dein Setup wo pumpst du welche Art von Traffic rein und an welcher Stelle besteht da ein Wireguard Tunnel. Das haben wir sehr genau beschrieben und kamen dabei auf fastd ähnliche Werte , die bei gleicher Crypto cha20 schlicht Sinn ergeben auf den 841v11. Ich weis jetzt nicht ob das an der unterschiedlichen HW liegt, oder ob du dir schlicht nen günstigeres Test-setup gelegt hast, und dann auch nur in 1 Richtung getestet hast. Wir wollten was bauen was der realität ziemlich nahe kommt. (beschrieben hier https://forum.freifunk.net/t/lede-test-wireguard-und-blanko-durchsatz-tp841nv11-1-und-bug/13163 ) Ohne das du dich genau auf den Aufbau beziehst kann ich das nicht vergleichen.

[neocturne]

Wireguard sollte auf jeden Fall signifikant schneller sein, die Zahlen von @RubenKelevra klingen realistisch.

Die Crypto von fastd kostet relativ wenig, relativ zur sonstigen Behandlung der Pakete (Context Switches, Kopieren zwischen Kernel- und Userspace, Overhead in fastd selbst), das kann man sich anhand der Werte unter https://projects.universe-factory.net/projects/fastd/wiki/Benchmarks ausrechnen.

[viisauksena]

dann bin ich auf Hinweise was wir mit den blanko Lede Routern "falsch" gemacht haben (könnten) sehr gespannt. Nochmal kurz unser setup :

Laptop (mit iperf) LAN> LEDE-841v11 < Wireguard WAN > LEDE-841v11 < LAN Laptop (mit Iperf)

gemessen in beide Richtungen Nackt mit fastd und mit wireguard, tcp und udp. (salsa2012+umac bei fastd - wireguard default cha20poly)

[RubenKelevra]

@NeoRaider ja, den Test hat Felix durchgeführt. Wir überlegen grade in wie fern wir wechseln können, da Fastd wohl nie in den Kernelspace wechselt ... das Ticket dazu ist seit nem Monat offen ohne weiteren Kommentar.

https://projects.universe-factory.net/issues/237

@viisauksena keine Ahnung, hab keine Zeit deinen Setup zu debuggen. Unser Test ist ebenfalls via iperf durchgeführt worden. Fedora auf C7 und einen Hop weiter.

Grundsätzlich hat der C7 eigentlich nicht signifikant mehr CPU-Power als ein 841iger.

[viisauksena]

@RubenKelevra ... doku lesen hilft .. dein "unwesentlicher" unerschied beläuft sich auf MIPS74Kc@720 MHz mit Gigabit gegen 500++Mhz mit 100 Mbit switchen und eben anderem Prozessor - wenn ich den jetzt richtig rausgesucht hab, fastd selber hat benchmarks bei Geräten mit weniger Unterschied die schon viel ausmachen https://projects.universe-factory.net/projects/fastd/wiki/Benchmarks

edit nicht nur cpu vergleichen (die in diesem Fall übertertaktet wird, simply weils geht! - afaik) Clocks: CPU:720.000MHz, DDR:600.000MHz, AHB:200.000MHz, Ref:40.000MHz Clocks: CPU:650.000MHz, DDR:390.551MHz, AHB:216.666MHz, Ref:25.000MHz Architektur des Chips .. 74Kc vs 24 Kc

ich wollte nicht das du unser "setup" debugst, nur nicht das du so große Töne rauslässt wenn du die Tests nichtmal selber gemacht hast - um uns dann zu sagen das wir was falsch machen - ohne einen leisen hauch an Hint - zumal auf der Wireguard Dev Liste wir mit anderen Gruppen die gleichen Werte bekommen

[RubenKelevra]

@viisauksena kein Grund die Nettiquette zu vergessen, nur weil dir missfällt was ich schreibe. Weder spucke ich hier große Töne (nirgends schrieb ich ich persönlich hab den Test gemacht) noch ist der CPU-Unterschied signifikant genug um 1x MBit auf 4x MBit zu rechtfertigen (650 zu 700 MHz).

Nichts für ungut aber das artet mir hier zu sehr aus für eine relativ nutzlose Diskussion um einzelne Tests.

[viisauksena]

update mit dem neuen LEDE Patch zum aligned meory access auf den kleinen tplink geräten erreicht WG dort auch 30 Mbit https://forum.freifunk.net/t/lede-test-wireguard-und-blanko-durchsatz-tp841nv11-1-und-bug/13163/11?u=fuzzle

(btw. @RubenKelevra no offense . ich verbuch das mal unter gegenseitig auf falscher Füße getreten .. )

[viisauksena]

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. evtl könnte ich den gluon lede branch mal bauen und da auch wireguard einbauen mit l2tp-eth und batman on top. das wird mein Wochenendprojekt [WireGuard] OpenWRT/MIPS Improvements : [WireGuard] [ANNOUNCE] Snapshot experimental-0.0.20161110 Available einer der oom bugs scheint aber noch zu existieren.

[viisauksena]

wieder neuigkeiten, habe das Testweise mit lede zusammengebaut und in unserem Mittelgroßem Freifunknetz getestet. ich komme auf etwa 16Mbit mit wireguard+gretap im Vergleich zu 5-6 Mbit fastd unter "livebedingungen" Durchsatz auf einem 841 / 842 Kisten. mehr dazu hier https://forum.freifunk.net/t/lede-wireguard-gretap-ergebnisse-unter-livebedingungen/14057/2

ich denke sobald gluon - lede based ist, kann man das gut als packet angehen, oder zumindest im lede branch mit anbieten. Sonst macht das keinen großen Sinn.

[RubenKelevra]

Moin viisauksena,

warum kommen denn bei fastd nur 5-6 Mbit/s raus? Bei uns sind so 10-12 MBit/s drin mit nem 841iger v11.

[viisauksena]

@RubenKelevra weis nicht, eckdaten wären hier 841v9 - Netz etwa 330 Knoten * insg. 450 uplinkverbindungen (weil je 2 fastd), und bis zu 1000 Nutzer, 6-8 GW Server. der V9 ist also langsamer und ich kenne euer Netz nicht - also ob das Vergleichbar ist. Wir nutzen bat.v14. Als unser Netz kleiner war meine ich mich an deutlich bessere Werte zu erinner, kann das aber kaum vergleichen - bzw finde da nichts was sich wirklich gut vergleichen lässt.

[rotanid]

irgendwie erreicht sowieso jeder andere Werte, weil jeder anders misst. wir kommen beim v10 z.B. auf ca. 9 MBit/s (siehe https://wiki.tecff.de/router-vpn-speed )

[viisauksena]

mittlerweile gibt es ein gluon Paket das aus der site.conf Daten liest um damit ein wireguard + gretap tunnel in bat0 zu hängen. das kann über die modules Datei ohne weiteres eingeführt werden, und ist community unabhängig. das funktioniert soweit, config mode zeigt Pubkey und inner-ip an. es bräuchte noch einiges an schön machen, und bugfixes (die im moment nicht funktionsrelevant sind) die Frage daher - möchte man ein gluon-mesh-wireguard haben? dann würde ich einen PR aus dem bisher bestehenden Paket machen https://github.com/viisauksena/gluon-mesh-wireguard generell infos zu dem Verlauf und so : https://forum.freifunk.net/t/wireguard-0-0-20161230-linuxkernel-3-18-gluon-v2016-2-2/14122/

[neocturne]

See #1058.