Wenn ich so sehe, wie meine RaspberyPi-Gruppe bei FB gerade explodiert (Userzahl), dann denke ich, daß wir dringend eine RPI-Lösung für GLUON brauchen! (mit passendem USB-Adapter versteht sich)
In dem Bereich gibt es auch viel „Human-Kapital“, das wir dringend nutzen sollten!
1 „Gefällt mir“
Das Problem ist wirklich ein langzeit-verfügbarer wlanstick. mit ordentlichen Antennen.
Man sollte evtl. eine Version nehmen die zumindest zwei lan-ports gleich mit an Bord hat, um am zweiten wahlweise mesh oder lan haben zu können.
Da sehe ich weniger das Problem.
Die leute, die da ernsthaft basteln haben auch keine Angst vor VLANs, und 100mbit USB-Adapter gibts auch für kleines Geld, so, daß man mehr LAN-Ports hat.
Die USB-Unterstützung reicht aus um 3 100mbit-LAN-Ports mit max. speed zu befeuern.
Was man machen müsste, wäre, ein Repo aufsetzen, aus dem man batman und fastd in der passenden Version bekommt, und jeweils ein meta-Paket/Community mir allen Settings und Abhängigkeiten.
USB-WALN-Sticks gibts einige recht ordentliche mit Atheros-Chipsatz und SMA-Buchse…da geht schon was.
Also 1. interessiert die bastler nicht, daß das paar € mehr kostet, und 2. braucht das Freifunk-Projekt dringend mehr Leute, die die verwendete Technik wirklich verstehen, und die finden wir eher unter den RPI-Nutzern als unter denen, die sich den billigsten Router auf dem Markt „gönnen“ 
Bei Gluon steckt erstaunlich viel Gehirnschmalz in den den Scripten, die das Netzwerk konfigurieren.
Irgendwas kompiliert zu bekommen ist vermutlich gar nicht so schwierig. Aber die Netzwerkscripte, die überall ein identisches environment herstellen, das könnte tricky werden.
(derzeit kommt gluon gar nicht damit zurecht, wenn es gar kein Wifi gibt.)
Würde ich mir zutrauen, aber ich hab keinen Bock allein an so einem Projekt zu basteln.
Eine Beispielkonfiguration wäre hier interessant. RPI+Netzteil sind klar. Was für einen Stick und was für eine Antenne könnte man da nehmen?
Vollkommen richtig. Das ist dann aber kein Ersatz für unser Arbeitstier den WR841N, sondern eine Erweiterung des Projekts zu Forschungszwecken. Sicherlich eine absolut tolle Sache, aber du kannst einen PI mit Stick und externer Antenne niemals bei einem ohnehin schon skeptischen Wirt aufstellen.
bei jeglichem Stick in bezahlbaren Preisbereich (<15€… bedenkt, ein 1043v2 kostet auch nur 40€) finde ich kaum welche mit 2 schwenkbaren Antennen.
Und die, die es gibt haben Linux-Support der nach Höllenqualen klingt…
Es gibt doch Sticks mit SMA-Buchse.
Gute Antennen findet man genug.
Ein Kollege hatte da einen ganz feinen Stick gefunden.
Ich werd da mal nachhaken.
Antenne und Tranceiver sollte man immer getrennt betrachten, und selbst interne Antennen kann man via Lötkolben und Skalpell durch Externe ersetzen.
Ach ja…natürlich ist das alles völlig o.T…einen 841 kann man damit natürlich nicht ersetzen
Genau, und das schon als Client. Unsere speziellen Anforderungen mit adhoc und Infrastruktur-Mode gleichzeitig werden nicht unterstützt sein.
@adorfer: Vorschlag alle den RPI betreffenden Beiträge in ein neues Thema ausgliedern.
Auf jeden fall eine gute Idee!
Als ich zuletzt einen potentiell Meshfähigen WLAN Stick (TP-Link WN722N) an meinen Raspberry Pi B angeschlossen hab, ist direkt mal die Spannungsversorgung zusammen gebrochen. Bei den neuen Raspberrys soll das besser sein.
Ich verwende diverse PI´s für mein ADSB-Projekt um Transpondersignale von Flugzeugen auszuwerten. In der Grundumgebung ist ein Edimax EW 7811 und ein Noname DVB-T Stick mit RTL2832 Chipsatz angeschlossen. Das ganze wird von einem 2A Samsung „Tablet“ Netzteil mit Strom versorgt. Das ganze macht seit 8 Monaten nichts anderes als 24/7 laufen…laufen…laufen.
Ich meine, dass es die WLAN Dongle von Edimax auch mit externer Antenne gab. Müsste der EW 7612 gewesen sein. Dieser sollte auch nicht mehr Strom verbrauchen.
Die Stromversorgung an den USB-Buchsen entspricht nicht ganz dem USB-Standard, (es stehen nicht wie üblich bis zu 500mA zur Verfügung) und daher wird grundsätzlich empfohlen für stromhungrige USB-Peripherie einen powered USB-Hub zu verwenden.
Das steht auch so in der Dokumentation und ist kein Fehler sondern eine Design-Entscheidung.
Harry
Ergänzend sei hier noch erwähnt, dass man sich dafür das Netzgerät des Pis sparen kann. Der Pi kann seinen Strom dann direkt über einen der beiden USB-Ports vom Hub ziehen.
1 „Gefällt mir“
Ist der Pi eigentlich mit der neuen Revision interessant als Zuliefergerät für das Meshing geworden? Kann man sowas ausprobieren ohne gleich einen ganzen Gluon Port zu basteln?
Der Banana PI Router (5 Ports, 2 eigenständige Netzwerkkarten!) wird bereits von OpenWRT unterstützt.
Leider kenne ich mich mit OpenWRT / Gluon zu wenig aus, um dem Compiler die notwendigen Änderungen mit auf den Weg zu geben, damit ein fertiges Gluon Image bei raus kommt - hätte als allgemeine Basis (ohne WLan!) zum Offloaden des fastd aber ebenfalls großes Interesse daran, da es derzeit noch keine fertige Lösung dafür gibt.
Traut sich das jemand zu eine Gluon Firmware für den Banana Pi Router zu backen, wäre das grundsätzlich möglich?
3 „Gefällt mir“
Fände ich auch klasse, zumal man dann alle 4 freien Ports für Mesh on WAN/LAN nutzen könnte.
Ich selbst hab leider auch zu wenig Ahnung von OpenWRT, als dass ich das machen könnte 
Wenn jemand das Gluon-Target „Banana-Pi“ im Git hinbekäme, dann wäre mir das „einen Banana-Pi ink. Netzteil frei Haus“ wert.
Bei glaubhafter Versicherung, daran arbeiten zu wollen, gibt’s den auch „vorab“ (hätte ich nur dann gern binnen 2 Monaten wieder, wenn’s -warum auch immer- nicht hinhaut)
Ach ja, geht mir NUR um einen Fastd-Offloader für größere LAN-Mesh-Wolken (also meshvpn plus mesh-on-wan), definitiv kein Wifi oder gar zusätzliche Spielereien benötigt.
2 „Gefällt mir“
Ich zitiere aus einer Mail mit @anon75826926:
Der Banana Pi, bzw. das ganze sunxi-Target wird von OpenWrt Barrier
Breaker noch nicht unterstützt, d.h., zur Zeit kann man Gluon nicht
dafür bauen. Wenn die ersten Betas oder RCs von Chaos Calmer kommen,
werden wir aber sicher schnell Gluon auf die Basis des neuen OpenWrt
portieren.
Scheint also (zumindest zur Zeit) noch nicht möglich zu sein.