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