Einfach verständlich (nur vanilla lede, uci und ein paar shell-scripts)
Internet mit / ohne VPN direkt freigeben (IPv4 & IPv6)
Babel und batman-adv parallel
Die Firmware wird langsam reifer - zum Congress hatte ich den Berliner meshwizard (JavaScript GUI), s.d. die Konfiguration nicht per per ssh erfolgen muss. Der technische unterbau (Lede Packages, Firmware files) steht auch mittlerweile. Dennoch gibt’s einige Baustellen.
Ich wollte daher einfach mal in die Runde fragen, wer sonst noch Lust hätte, mit mir an der Firmware zu basteln. Konkret geht’s um die folgenden Punkte:
Map / Hopglass-Integration: JSON-Statusdaten via Shell erzeugen. (Stammdaten wie z.B. Standort gibt’s schon)
Nutzerfreundliche Doku: Eine github-Bauanleitung überfordert einige.
Testen: Es wird nicht überall rund laufen
meshwizard-merge: Der Build für die Angular-Anwendung muss konfigurierbar sein, dann können die Patches in den Berliner Upstream.
hast du schon darüber nachgedacht einfach das respondd als Paket einzubinden? Das ist mWn relativ modular und sollte auch als LEDE-Paket einbaubar sein. Dann wäre die Kommunikation mit dem HopGlass-Server einheitlich. Es erfordert allerdings netzinternes IPV6.
Puh danke’ für’s feedback. Über respondd, nachgedacht hab’ ich; dich hab’ die Idee auch noch nicht verworfen. Es gibt ein paar Punkte die respondd eher unattraktiv machen:
Pull statt Push: Respondd reagiert auf Multicast-Anfragen. Da babel layer3 ist, wäre ein Push-Mechanismus einfacher. Gleichzeitig find’ ich ein ServerSocket aus security Gründen auch nicht 1. Wahl.
Nicht in Lede enthalten: Das Paket müsste gebaut werden. Da es C ist, wäre der Build damit Plattform-abhängig. Es würde nicht mehr ausreichen, einfach Dateien auf den Router zu kopieren
Eher komplex: Einiges an Plugins und indirektionen.
Das sind soweit keine k.o.-Punkte. Falls jemand Dinge tun möchte, bin ich auf jeden Fall dafür offen. Im Idealfall würde respondd dann in Lede landen und via ubus abfragbar sein, s.d. 10 Zeilen shell reichen um die Daten via UDP an den Server zu senden.
Ich wünsche mir bei Gluon ja immer noch einen (Opt-In) Verschlüsselungs-Mechanismus, der mehr oder weniger die Herausgabe der Daten nur an eine „vertrauenswürdigen“ Person (de facto also der Firmwarebäcker) ermöglicht. Das kann man damit vielleicht direkt mit erschlagen, wenn man eh schon dabei ist. Bei Gluon war da das Problem dass man irgendwie Crypto von fastd zweckentfremden müsste oder so aus Platzgründen.
Einerseits:
Mein Ansatz ist, möglichst einfach und simpel Daten an einen öffentlichen Map-Server zu senden.
Gluon ist ist - allein von der Komplexität her - eine völlig andere Nummer.
Hier geht’s darum mit ein paar Zeilen shell / awk-Code Ausgaben von batctl (usw.) so aufzubereiten, dass sie passenden json sind.
Vgl.
Andererseits:
Meine Motivation für die Einfachheit ist, Hacking zu erlauben, d.h. die Sache soll so einfach sein, dass jeder basteln kannst. D.h. falls Du in
auf dem Server in der Datei authorized_keys, das kommand auf nc -u 127.0.0.1 4711 für den Key einschränkst,
hast Du genau das gewünschte verhalten.
(Ja, ich weiß, SSH aber einerseits ist Optimierung der Feind der Einsamkeit und andererseits macht die Crypto Session-Key-Handling erforderlich, das dann die ACKs enthalten kann).
Gruß, yanosz
P.S. Ich hab’ zu dem Firmware-Bäcker ohne weiteres nicht wirklich Vertrauen. Wichtiger wäre mir Offenheit.