Fastd-Offloader mit und ohne Gluon (alle Platformen)

Ich will es auch auf meinem BayTrail-Server einsetzen, da der eh 24/7 läuft.

VBox wäre praktisch. Aber KVM ginge auch.

1 Like

Gibt es fastd überhaupt schon kompiliert für Raspberry Pi / armhf ?

Ich hätte ja lieber eine Lösung für debian!

https://pad.freifunk.net/p/fastd_anbindung

Das hier sollte tun für Debian und Ubuntu LTS.

Ahh! - Danke!

Schau ich mir mal an!

Fastd für armhf: kann man machen – http://v2.blogdoch.net/2015/01/23/wusel-085622/

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,- €:

Intel NUC Kit DE3815TYKHE Produktspezifikationen

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.

1 Like

Ja, das war Sinn und Zweck, und daher etwas aufwändiger als tar zxf && make :wink: Er hat sie schön nativ gebaut, hat an einigen auch Stunden rumgekaut :wink:

-rw-r--r-- 1 root root 111K Dec 26 10:09 /media/wusel/1af97748-34b7-4a6e-a16d-29c409d9c367/root/fastd_16-1_armhf.deb
-rw-r--r-- 1 root root 121K Dec 26 05:01 /media/wusel/1af97748-34b7-4a6e-a16d-29c409d9c367/root/libnacl-dev_20110221-4_armhf.deb
-rw-r--r-- 1 root root 8.1K Dec 26 02:30 /media/wusel/1af97748-34b7-4a6e-a16d-29c409d9c367/root/libuecc0_4-1_armhf.deb
-rw-r--r-- 1 root root 3.2K Dec 26 02:30 /media/wusel/1af97748-34b7-4a6e-a16d-29c409d9c367/root/libuecc-dev_4-1_armhf.deb
-rw-r--r-- 1 root root 137K Dec 26 05:01 /media/wusel/1af97748-34b7-4a6e-a16d-29c409d9c367/root/nacl-tools_20110221-4_armhf.deb

Gebaut auf und für Debian Wheezy; falls tatsächlich Bedarf besteht, kann ich den Kram irgendwo zum runterladen hochladen :wink:

1 Like

@wusel Bei mir besteht kein Bedarf da heute der Postmann mit nem Atom Board unterm Arm bei mir klingelt.

Schmeiss das ruhig mal auf dropbox oder ähnliches.

Ich hab 23 Beiträge in ein vorhandenes Thema verschoben: Status: Gluon für x86/„Nicht-Router“ wg. mehr VPN-Durchsatz

Fortsetzung der Diskussion von VPN-Anbindung (DN42/Intercity/ChaosVPN):

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.

Viel Erfolg,
kerel

In einem Pad ist die Einrichtung eines Fastd Rechners schön beschrieben:

Für viele Gluon Firmwares gibt es eine Linkliste zu den site.conf Dateien, die die von dir gesuchten Peers beinhalten:
http://gluon.readthedocs.org/en/v2014.4/user/site.html#site-repos-in-the-wild

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 :wink:

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.

Grüße
MPW

1 Like

„Das kannste schon so machen, aber dann ist es halt Kacke.“

Übersicht weg, Faden gerissen, Thread tot.

2 Likes

Gibt es einen Thread zu deinem Aufbau mit den Pis?

MfG Felix

Die Diskussion wurde nach Neuanfang: VPN-Beschleunigung jeglicher Art verlegt

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.