Hallo,
ich möchte gern über das Format der JSON-Files sprechen, in denen die Communities konfiguriert werden. Hauptsächlich geht es mir darum alles insgesamt logischer, intuitiver und besser erweiterbar zu machen.
Am Ende möchte ich gern zu einer Dokumentation im Stil der RFCs gelangen, die festlegt welcher Felder Pflichtfelder sind und in welchem Format die Werte sein müssen usw.
1) Der Header beinhalt Name, ID, ein Prefix und eine Sammlung an URLs, die dazu genutzt werden können den User zur richtigen Seite zu bringen. Vielleicht kann man die URLs in ein untergeordnetes Dictionary verschieben. Das ist aber meinerseits kein Muss.
Ich denke es versteht sich von selbst, dass der Name (und generell alle Strings) UTF-8 sein sollten. Für die ID würde ich vorschlagen nur Buchstaben und Ziffern zuzulassen.
2) Ein Protokoll-Block
Derzeit ist nicht spezifiziert über welches Protokoll sich die Systeme zu den Supernodes verbinden sollen. Wir gehen einfach von fastd aus, was sich aber in Zukunft mal ändern könnte. Vielleicht werden wir ein VPN irgendwann gar nicht mehr benötigen.
Das gleiche gilt für BATMAN. Wir haben ja schon jetzt inkompatible Versionen und sollten auch berücksichtigen, dass BATMAN irgendwann mal ausgetauscht wird. Manche Netze nutzen ja noch OSLR. Vielleicht möchte das irgendwann jemand nachrüsten.
Mein Vorschlag wäre folgender:
"protocols" : { "routing" : { "name" : "batman-adv", "version" : "20xx.x.x", "compat-version" : 15 }, }
Die Supernodes können ja als Liste organisiert bleiben. Es sollte dann nur dazu geschrieben werden, ob es sich um fastd handelt, oder OpenVPN, oder was auch immer eingesetzt wird.
Ebenso würde ich auch die Ciphers und MTU für jeden Node einzeln spezifizieren.
"supernodes": [ { "protocol" : "fastd", "peer": "ruhrgebiet0", "key": "b99ecd9663126a8036d9e9990df7110318567b6cfa06652e55de853a6384fb6a", "remote": "ffrg0.freifunk-ruhrgebiet.de", "port": 10000, "ciphers": ["aes128-gcm", "salsa2012+gmac", "xsalsa20-poly1305", "null"], "mtu" : 1426 }, ... ]
Mein grundlegender Gedanke ist, dass man jede Komponente irgendwann mal durch eine andere ersetzen könnte.
3) Ad-hoc-Netzwerke
Aktuell sieht das so aus:
"wifi24": { "ssid": "Freifunk", "channel": 3, "htmode": "HT40+", "mesh_ssid": "wifimesh-ruhrgebiet", "mesh_bssid": "02:ff:13:37:ff:01", "mesh_mcast_rate": 12000 },
"wifi5": { "ssid": "Freifunk (5GHz)", "channel": 44, "htmode": "HT40+", "mesh_ssid": "wifimesh-ruhrgebiet5", "mesh_bssid": "02:ff:13:37:ff:02", "mesh_mcast_rate": 12000 }
Ich finde die Unterscheidung nach Frequenzband eher unglücklich. Besser wäre es wieder eine Liste zu machen:
"adhoc" : [ { "ssid" : "wifimesh-ruhrgebiet", "bssid" : "02:ff:13:37:ff:01", "channel" : 3, "htmode" : "HT40+"}, { "ssid" : "wifimesh-ruhrgebiet5", "bssid" : "02:ff:13:37:ff:02", "channel" : 44, "htmode" : "HT40+"} ]
Und dann in etwa das gleich noch einmal für die APs:
"infrastructure" : [ { "ssid" : "Freifunk" } ]
Warum ihr dafür einen festen Kanal vorgebt und die SSID für das 5 GHz-Band verändert kann ich eigentlich gar nicht nachvollziehen. Das ist auch der Beweggrund warum ich das anders organisiert sehen möchte.
Mir fehlen noch Informationen zur MTU der ad-hoc-Interfaces. Ich finde, dass man das festlegen sollte anstatt dem Zufall zu überlassen.
Was "mesh_mcast_rate" ist, konnte mir bisher nicht beantwortet werden. Daher kann ich nicht sagen wo das untergebracht werden kann.
---
Das sind nun also in einem kurzen Abriss meine Ideen und Wünsche. Ich würde mich freuen eure zu hören...
-Michael