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
