In diesem Thread wird NUC leider wieder unreflektiert benutzt; kaum eine NUC-CPU kann AES, und nicht alle NUC kommen mit WLAN. Ausnahme für AES:
http://ark.intel.com gibt dir Auskunft über alle Intel Prozessoren.
Dort suchst du nach „AES Support“, sortierst dann nach Preis, pickst
dir den billigsten, hinterletzten Atom-Prozessor raus, suchst dir ein
Kit, in dem der verbaut wird und bestellst dir für 100,- €:
Effektiv sind >150.-- anzusetzen, für den Preis bekomme ich locker einen ODROID-U3, der ~90 MBit/sec per OpenVPN zu ver-/entschlüsseln in der Lage ist …
Es war ein kleiner Akt, fastd auf dem Banana Pi zu kompilieren – armhf-Binaries gibt’s AFAIK nicht –, aber schlußendlich war es keine unüberwindliche Hürde.
Kannst du @wusel denn dann vielleicht deb Pakete für armhf bauen?
Warum sollte man die durch das Gehäuse abgeschirmte und vermutlich eh inkompatible WLAN-Hardware für Freifunk nutzen? - Nur weils gerade mit dabei war?
Ich dachte, es ging um die fastd-Beschleunigung, und das hat ja mal mit WLAN gar nichts zu tun.
Jeder Plastik-Router für ein paar Euro hat deutlich bessere HF-Performance, als all diese internen Lösungen.
Sinn macht das ganze aus meiner Sicht nur als „fastd-Coprozessor“, und der braucht kein eigenes WLAN.
Ja, laut @CHRlS kannst du mit jedem beliebigen fastd-key einen Tunnel aufbauen, wenn du in der Domaine Ruhrgebiet bist1.
Es würde also afaik reichen fastd zu installieren, beliebigen Schlüssel erzeugen, Peers eintragen, Fertig[2].
Eine Liste der Peers findet sich auf jedem Node, wo genau, kann ich nicht sagen, hatte noch kein Gluon vorliegen.
ich habe die Threads nun zusammengelegt, da eine Gliederung in „x86“ „non-X86“ und „gluon“/„openwrt“/„fulldistro“ (und auch „virtualized vs. bare metal“) sowieso nicht durchzuhalten war.
Ist zwar nun arg unübersichtlich, geht aber wohl nicht anders, ohne immer wieder Artikel bei „falscher Thread“ zu schubsen (was dann für anderweitigen Ärger sorgt.)
Soweit ich weiß nutzt Fastd nur einen Thread. Wir haben Backbone + Client Verbindung in Rheinufer getrennt.
Sprich 1x Fastd für die Clients und 1x Fastd für die Verbindungen zwischen den Supernodes.
Ansonsten ist mir da nichts bekannt.
User-Space Daemons sind immer langsamer, evtl wäre eine Idee das jemand Fastd als Kernel Module schreibt falls dies möglich ist
Also jetzt hakt es aber aus hier! Erstens, wofür fragst du eigentlich vorher, wenn du es dann doch anders machst? Ich hatte vorgeschlagen, einfach zwei Threads zu schließen. Dann wäre alles ordentlich geblieben.
Man hätte die Diskussion in einem weiter führen können und zwei wären als Archiv bestehen geblieben. Jetzt findet man nichts mehr.
Scheiße nochmal, ich finde meinen eigenen Beitrag von vor ca. einer Stunde nicht mehr! Lass das bitte endlich sein! In vielen Communities läuft noch die Diskussion ob nicht eine Mailingliste besser wäre, das ist das Chaos hier nicht gerade hilfreich.
Ich habe mich vor ein paar Tagen noch zurückhaltend geäußert, aber jetzt gerade verstehe ich voll und ganz wovon die Leute angepisst sind. Das nervt - mich auch.
Das Thema war so geil, gestern Abend iwie 10 Beiträge und jetzt finde ich hier nichts mehr. Himmel, ich bin kurz davor das Forum herunterzuladen und selbst zu archivieren.
Für die RaPIs (auch den II) wurde es zumindest derzeit von allen mir bekannten Basterln verworfen, da die Anbindung des LANs via (internem) USB2 als unzureichend angesehen wird, zumindest wenn man als Ziel Offloading hat.
Wobei der Beweis da eigentlich noch aussteht, dass nicht trotzdem das 100MBit und die CPU (unabhängig von der I/O-Load auf dem USB) dann nicht doch der eigentliche Flaschenhals ist.