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
Am 2014-12-04 18:20, schrieb Michael Tremer:
Das sind nun also in einem kurzen Abriss meine Ideen und Wünsche. Ich würde mich freuen eure zu hören...
-Michael
Hallo Michael! Hallo Liste!
Vielen Dank für deine ausführlichen Anmerkungen und Idee zum Format und der Struktur der JSON Files. Ich habe deine Ideen zur Struktur für die Supernodes und den WLAN Netzen übernommen, dadurch wird es deutlich modularer.
Ich bin mir aktuell nicht sicher ob es sich lohnt, die Struktur auch zu den Informationen über die eingesetzte batman-adv Version zu erweitern.
Bitte sieh Dir einmal die Version der FFRG.JSON im Repository an und prüfe auf ggfs. vorhandene Fehler. https://github.com/ffrl/FF-IPFire/blob/master/sites/FFRG.json
Nach einem Feedback von Dir würde ich dann die anderen Files im Repository auch anpassen.
Hi,
ja, das sieht doch schon ganz gut aus. Ich habe trotzdem noch ein paar Anmerkungen:
On Wed, 2014-12-10 at 19:41 +0100, Philip Berndroth wrote:
Am 2014-12-04 18:20, schrieb Michael Tremer:
Das sind nun also in einem kurzen Abriss meine Ideen und Wünsche. Ich würde mich freuen eure zu hören...
-Michael
Hallo Michael! Hallo Liste!
Vielen Dank für deine ausführlichen Anmerkungen und Idee zum Format und der Struktur der JSON Files. Ich habe deine Ideen zur Struktur für die Supernodes und den WLAN Netzen übernommen, dadurch wird es deutlich modularer.
Bei den Supernodes steht zunächst "protocol = fastd" drin. Ab dem zweiten aber nicht mehr. Ist das Absicht oder ein Bug?
"supernodes": [ { "protocol": "fastd", "peer": "ruhrgebiet0", "key": "b99ecd9663126a8036d9e9990df7110318567b6cfa06652e55de853a6384fb6a", "remote": "ffrg0.freifunk-ruhrgebiet.de", "port": 10000, "mtu": 1426, "ciphers": ["aes128-gcm", "salsa2012+gmac", "xsalsa20-poly1305", "null"] }, { "peer": "ruhrgebiet1", "key": "15e1601791c201e463ca404ae9174f937859346ef1b7311a3e9eebf02fe6ebbe", "remote": "ffrg1.freifunk-ruhrgebiet.de", "port": 10000, "mtu": 1426, "ciphers": ["aes128-gcm", "salsa2012+gmac", "xsalsa20-poly1305", "null"] },
Ich bin mir aktuell nicht sicher ob es sich lohnt, die Struktur auch zu den Informationen über die eingesetzte batman-adv Version zu erweitern.
Was sind die Argumente, die du abwägst?
Bitte sieh Dir einmal die Version der FFRG.JSON im Repository an und prüfe auf ggfs. vorhandene Fehler. https://github.com/ffrl/FF-IPFire/blob/master/sites/FFRG.json
Erledigt. Oben ist einer.
Ein zweiter Punkt ist, dass ich denke (wie am Telefon bereits kurz besprochen), dass man den Kanal des Infrastructure-APs nicht vorgeben sollte. Das ist eine Limitierung der Hardware im Fall der TP-Link-Router, aber kein generelles Problem des Netzes. Ganz im Gegenteil ist es sogar sinnvoller einen anderen Kanal zu nutzen, wenn möglich.
Ebenfalls kann man meines Erachtens die Definition weglassen, dass 40 MHz breite Kanäle genutzt werden. Erzwingen kann man das eigentlich nicht (laut 802.11) und wir könnten es so gestalten, dass man es probiert wenn die Hardware es erlaubt und wenn nicht, dann eben nicht. Die Nodes im Adhoc-Netz sollten sich trotzdem finden.
Und dann bleibt noch: "mesh_mcast_rate": 12000. Was soll ich damit anstellen?
-Michael
Am 2014-12-10 22:30, schrieb Michael Tremer:
Bei den Supernodes steht zunächst "protocol = fastd" drin. Ab dem zweiten aber nicht mehr. Ist das Absicht oder ein Bug?
Es war ein Fehler von mir und ich habe es korrigiert.
Am 2014-12-10 22:30, schrieb Michael Tremer:
Ein zweiter Punkt ist, dass ich denke (wie am Telefon bereits kurz besprochen), dass man den Kanal des Infrastructure-APs nicht vorgeben sollte. Das ist eine Limitierung der Hardware im Fall der TP-Link-Router, aber kein generelles Problem des Netzes. Ganz im Gegenteil ist es sogar sinnvoller einen anderen Kanal zu nutzen, wenn möglich.
Nur welchen Kanal will man dann nutzen, soll der User es einstellen können oder scannt man einmal und schlägt dann einen "guten" Kanal vor? Wie stellst Du dir das vor?
Ebenfalls kann man meines Erachtens die Definition weglassen, dass 40 MHz breite Kanäle genutzt werden. Erzwingen kann man das eigentlich nicht (laut 802.11) und wir könnten es so gestalten, dass man es probiert wenn die Hardware es erlaubt und wenn nicht, dann eben nicht. Die Nodes im Adhoc-Netz sollten sich trotzdem finden.
Wenn das so funktionieren würde (ich habe es nicht getestet) steht dem denke ich nicht's im Wege. Für uns ist es ja nur wichtig, dass sich die Adoc-Verbindung klappt.
Und dann bleibt noch: "mesh_mcast_rate": 12000. Was soll ich damit anstellen?
Das konnte ich noch nicht in Erfahrung bringen. Sobald ich eine Info habe, werde ich es kommunizieren.
Hi,
On Thu, 2014-12-11 at 17:39 +0100, Philip Berndroth wrote:
Am 2014-12-10 22:30, schrieb Michael Tremer:
Ein zweiter Punkt ist, dass ich denke (wie am Telefon bereits kurz besprochen), dass man den Kanal des Infrastructure-APs nicht vorgeben sollte. Das ist eine Limitierung der Hardware im Fall der TP-Link-Router, aber kein generelles Problem des Netzes. Ganz im Gegenteil ist es sogar sinnvoller einen anderen Kanal zu nutzen, wenn möglich.
Nur welchen Kanal will man dann nutzen, soll der User es einstellen können oder scannt man einmal und schlägt dann einen "guten" Kanal vor? Wie stellst Du dir das vor?
Für die meisten Router gibt es ja ohnehin keine Option. Die haben nur ein Radio-Modul und das kann nur auf einem Kanal gleichzeitig funken. Will man also das adhoc-Nutzen, dann muss auch der AP auf dem gleichen Kanal sein. Nachteil ist ja ganz offenbar, dass man die Bandbreite des Netzes um etwa die Hälfte teilt.
Das Szenario kann für Installationen mit IPFire ja anders aussehen. Du hast uns zu Beginn vorgestellt, dass du ein Gebäude mit einem bestehenden Netz von APs betreust. Die stellt man ja in der Regel auf verschiedene Kanäle ein, sodass die sich nicht stören (1, 6 und 11 im 2.4GHz Band). Das verletzt dann sowieso die Richtlinie.
Ferner kommt es auch in einigen Szenarios, die wir besprochen haben gar nicht vor, dass das IPFire-System per adhoc mesht, sondern nur per VPN. Das Freifunk-Netz fällt dann entweder im eingebauten AP raus, oder per Kabel. Für den AP finde ich es sinnvoll, dass man den Kanal frei wählen kann, denn Kanal 3 könnte ja schon belegt oder aus anderen Gründen ungeeignet sein.
Das ist alles vollkommen unabhängig vom eigentlich Mesh und soll nur die Bandbreite im AP-Modus vergrößern. Ich sehe hier überhaupt keine technischen Probleme.
Man könnte das den User auswählen lassen oder einfach den hostapd selbst wählen lassen. Der hat eine Funktion um seine Umgebung einmal kurz abzuscannen und dann den Kanal zu nutzen wo bisher am wenigsten drauf funkt.
Ebenfalls kann man meines Erachtens die Definition weglassen, dass 40 MHz breite Kanäle genutzt werden. Erzwingen kann man das eigentlich nicht (laut 802.11) und wir könnten es so gestalten, dass man es probiert wenn die Hardware es erlaubt und wenn nicht, dann eben nicht. Die Nodes im Adhoc-Netz sollten sich trotzdem finden.
Wenn das so funktionieren würde (ich habe es nicht getestet) steht dem denke ich nicht's im Wege. Für uns ist es ja nur wichtig, dass sich die Adoc-Verbindung klappt.
Ich habe hier ein Modul, das ich für das adhoc-Netz nutze, das definitiv keine 40 MHz breiten Kanäle unterstützt (802.11g). Das verbindet sich problemlos mit einem Router mit eurer Default-Firmware.
Und dann bleibt noch: "mesh_mcast_rate": 12000. Was soll ich damit anstellen?
Das konnte ich noch nicht in Erfahrung bringen. Sobald ich eine Info habe, werde ich es kommunizieren.
Supi!
-Michael
Hi,
Am 11.12.2014 um 17:50 schrieb Michael Tremer:
Das Szenario kann für Installationen mit IPFire ja anders aussehen. Du hast uns zu Beginn vorgestellt, dass du ein Gebäude mit einem bestehenden Netz von APs betreust. Die stellt man ja in der Regel auf verschiedene Kanäle ein, sodass die sich nicht stören (1, 6 und 11 im 2.4GHz Band). Das verletzt dann sowieso die Richtlinie.
1,6,11 war bei 802.11b korrekt. Bei 802.11g sollte man 1,5,9,13 nutzen. Dann hat man nämlich 4 überlappungsfreie Kanäle.
Siehe hier: https://de.wikipedia.org/wiki/Wireless_Local_Area_Network#Kanalbreiten.2C_.C...
Gruß Jan-Marten
Hi,
das mag ja rechnerisch passen und im Frequenzraum für Europa sein, aber sobald jemand mit nem Laptop vorbeikommt, wo der Hersteller mal eben World oder US in die Firmware gecodet hat, wird der feststellen, dass er unter Umständen den Kanal 13 nicht mehr sieht...
Ist zwar nicht standardkonform, aber ich habs oft genug gesehen und würde es daher in der Praxis ignorieren, dass es Kanäle oberhalb 11 gibt.
-Michael
On Fri, 2014-12-12 at 06:39 +0100, Jan-Marten Brüggemann wrote:
Hi,
Am 11.12.2014 um 17:50 schrieb Michael Tremer:
Das Szenario kann für Installationen mit IPFire ja anders aussehen. Du hast uns zu Beginn vorgestellt, dass du ein Gebäude mit einem bestehenden Netz von APs betreust. Die stellt man ja in der Regel auf verschiedene Kanäle ein, sodass die sich nicht stören (1, 6 und 11 im 2.4GHz Band). Das verletzt dann sowieso die Richtlinie.
1,6,11 war bei 802.11b korrekt. Bei 802.11g sollte man 1,5,9,13 nutzen. Dann hat man nämlich 4 überlappungsfreie Kanäle.
Siehe hier: https://de.wikipedia.org/wiki/Wireless_Local_Area_Network#Kanalbreiten.2C_.C...
Gruß Jan-Marten _______________________________________________ SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
...deshalb sind auch alle mir bekannten Communities im unteren Kanal, denn im 802.11n 40 MHz gibt es nur 2 Kanäle (Kanalgruppen)...
Am 13. Dezember 2014 um 01:34 schrieb Michael Tremer < michael.tremer@ipfire.org>:
Hi,
das mag ja rechnerisch passen und im Frequenzraum für Europa sein, aber sobald jemand mit nem Laptop vorbeikommt, wo der Hersteller mal eben World oder US in die Firmware gecodet hat, wird der feststellen, dass er unter Umständen den Kanal 13 nicht mehr sieht...
Ist zwar nicht standardkonform, aber ich habs oft genug gesehen und würde es daher in der Praxis ignorieren, dass es Kanäle oberhalb 11 gibt.
-Michael
On Fri, 2014-12-12 at 06:39 +0100, Jan-Marten Brüggemann wrote:
Hi,
Am 11.12.2014 um 17:50 schrieb Michael Tremer:
Das Szenario kann für Installationen mit IPFire ja anders aussehen. Du hast uns zu Beginn vorgestellt, dass du ein Gebäude mit einem bestehenden Netz von APs betreust. Die stellt man ja in der Regel auf verschiedene Kanäle ein, sodass die sich nicht stören (1, 6 und 11 im 2.4GHz Band). Das verletzt dann sowieso die Richtlinie.
1,6,11 war bei 802.11b korrekt. Bei 802.11g sollte man 1,5,9,13 nutzen. Dann hat man nämlich 4 überlappungsfreie Kanäle.
Siehe hier:
https://de.wikipedia.org/wiki/Wireless_Local_Area_Network#Kanalbreiten.2C_.C...
Gruß Jan-Marten _______________________________________________ SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hallo zusammen,
wird gerade noch irgendetwas von mir gebraucht, dass wir voran kommen können?
Ich erwarte noch die letzte Fassung des JSON-Layouts, sodass es mit der Programmierung auf Seiten IPFire weitergehen kann...
-Michael
Hallo Zusammen und ein frohes neues Jahr!
Am 2014-12-22 16:52, schrieb Michael Tremer:
Ich erwarte noch die letzte Fassung des JSON-Layouts, sodass es mit der Programmierung auf Seiten IPFire weitergehen kann...
Ich habe die ausstehenden Anpassungen committed. https://github.com/ffrl/FF-IPFire/commit/44289799b815e7bef0c08976f3bca9ddcca...
Inhaltlich wird es noch Änderungen geben (neue Supernodes), diese sollten aber keinen Einfluss auf die Entwicklung haben.
Hallo,
schön, dass wir nach über einem Monat Stillstand weiterkommen können...
On Sun, 2015-01-11 at 16:13 +0100, Philip Berndroth wrote:
Hallo Zusammen und ein frohes neues Jahr!
Am 2014-12-22 16:52, schrieb Michael Tremer:
Ich erwarte noch die letzte Fassung des JSON-Layouts, sodass es mit der Programmierung auf Seiten IPFire weitergehen kann...
Ich habe die ausstehenden Anpassungen committed. https://github.com/ffrl/FF-IPFire/commit/44289799b815e7bef0c08976f3bca9ddcca...
Einige der Punkte, die wir zuletzt diskutiert haben sind ja nun gelöst.
Andere passen aber immer noch nicht:
a) Bei den Supernodes fehlt bei allen bis auf den ersten immer noch das "protocol".
b) htmode: Wie bereits erwähnt halte ich es nicht für sinnvoll das hier zu spezifizieren. Wenn, dann schon als SHOULD und nicht als MUST (nach RFC-Terminologie).
c) HT20+?
d) mesh_mcast_rate?
Das sind meinerseits immer noch offene Fragen bzgl. des JSON-Dokuments.
Inhaltlich wird es noch Änderungen geben (neue Supernodes), diese sollten aber keinen Einfluss auf die Entwicklung haben.
Nein, die Anzahl der Supernodes spielt keine Rolle für meine Aufgaben.
-Michael
Am 2015-01-12 16:48, schrieb Michael Tremer:
a) Bei den Supernodes fehlt bei allen bis auf den ersten immer noch das "protocol".
Ist nun erledigt. https://github.com/ffrl/FF-IPFire/commit/e93673cb6af58ea0e58ae18b2660b43e6f2...
Hallo Philip
Ich hoffe Du hast die "tollen Tage" gut überstanden!
Es leider wieder etwas ruhig geworden. Wie ist denn der Status auf deiner Seite?
Hast Du das Image mal testen können? http://people.ipfire.org/~ms/branches/batman/
Aktuell warten wir noch auf einige Infos Deinerseits.
Siehe hier: http://lists.ipfire.org/pipermail/sig-freifunk-de/2015-January/000050.html
Punkt a) hast Du beantwortet aber die restlichen sind leider noch offen.
Am JSON-Dokument wurden kleinere Änderungen gemacht aber von fertig kann man leider auch nicht sprechen.
Gruß Daniel
Am 11.01.2015 um 16:13 schrieb Philip Berndroth:
Hallo Zusammen und ein frohes neues Jahr!
Am 2014-12-22 16:52, schrieb Michael Tremer:
Ich erwarte noch die letzte Fassung des JSON-Layouts, sodass es mit der Programmierung auf Seiten IPFire weitergehen kann...
Ich habe die ausstehenden Anpassungen committed. https://github.com/ffrl/FF-IPFire/commit/44289799b815e7bef0c08976f3bca9ddcca...
Inhaltlich wird es noch Änderungen geben (neue Supernodes), diese sollten aber keinen Einfluss auf die Entwicklung haben.
-
Chris Bischoff -
Daniel Weismüller -
Jan-Marten Brüggemann -
Michael Tremer -
Philip Berndroth