[quote=„baranator, post:35, topic:8881“]
Die Router werden dann ein kleines PHP-Skript auf dem Server aufrufen, an dieses per GET die Koordinaten übergeben und als Antwort die auf der json-Datei basierend passenden Parameter (Server, Key, E/BSSID).[/quote]
Okay, ähnliches Schema, aber andere Datenbasis, wie bei uns.
Wobei: Ihr dynamisiert die site.conf, indem die peer-Infos von jenem PHP-Skript kommen? Hmm, interessanter Gedanke; man könnte statt nur ein paar Daten gleich eine site.conf übertragen … Hmm …
Anyway: Wir (Kreis Gütersloh) nutzen bestehende Dienste (hier: nominatim/OSM) für die Geo-Lokalisierung. Dies läuft ebenfalls serverbasiert, der Knoten schickt unserem Server seine Node-ID (== primäre MAC) sowie die aktuellen Geo-Koordinaten, das Skript spuckt die Ausgabe des Reverse-Geocodings aus (Straße wird für den Namensvorschlag verwendet, PLZ zwingend dem Namen vorangestellt) sowie einen Locode (wobei wir das Land weggelassen haben):
wusel@luggage:~$ wget -q -O /tmp/geoloc.out "http://setup.4830.org/geoloc.php?rgeo=me&node=e8:94:f6:52:4b:54&lat=51.8928414&lon=8.3838588"
wusel@luggage:~$ cat /tmp/geoloc.out
Content-Type: text/plain; charset=UTF-8
MAC: e8:94:f6:52:4b:54
LAT: 51.8928414
LON: 8.3838588
ADR: Schalueckstr-107
CTY: Guetersloh
ZIP: 33332
LOC: gut
Anhand des Locodes wird die jeweilige site.conf selektiert, ans Ziel kopiert und ausgewertet (Gluons upgrade-Skripte). So trennen wir schon heute die Netze im Kreis Gütersloh und an der Müritz (und geben Knoten im Stadtgebiet von Rheda-Wiedenbrück eine eigene SSID seufz). Der Plan ist, entsprechend auf Orts-/Gemeindeebene die Meshes/Netze zu trennen.
Der Poligon-Ansatz hat auch einen gewissen Charme, aber da wir die »Middleware« (geoloc.php) kontrollieren, könnte man darauf später umsteigen — oder auch so dafür sorgen, daß Gütersloh und Spexard in einem Mesh bleiben (räumliche Nähe), Gütersloh und Friedrichsdorf (eher keine Gefahr von Fensterbrett-Meshing) in getrennten Meshes landen.
Letzteres war der Grund für die Zwischenschaltung eigener Server, und die Nutzung bestehender Geocoding-Services basiert auf der Tatsache, daß das der einfachste Weg zu sein schien (Rad, erfinden). Zudem: nominatim kann man notfalls auch selbst hosten (was wir bislang noch nicht machen, aber auf der Agenda steht => Ausfallsicherheit, Unabhängigkeit von externen Diensten).
Und noch bißchen Backlog:
Dir scheint mittlerweile klar geworden zu sein, daß dem eben nicht so ist, wenn Du auf dem Knoten testest
Der (Gluon-) Knoten selbst nutzt seinen Uplink direkt:
root@33334-Knoten-8d62:~# time wget -O /dev/null http://speedtest.netcologne.de/test_100mb.bin
Connecting to speedtest.netcologne.de (194.8.194.20:80)
null 100% |*******************************| 106M 0:00:00 ETA
real 0m 9.38s
user 0m 0.33s
sys 0m 3.50s
111149056 Bytes in 9.38 Sekunden => 94.796.636 Bit/sec. Hmm, nicht ganz die 155 MBit/sec, die die Leitung hergeben sollte, aber egal. Schauen wir doch mal, wo’s lang geht:
root@33334-Knoten-8d62:~# traceroute speedtest.netcologne.de
traceroute to speedtest.netcologne.de (194.8.194.20), 30 hops max, 38 byte packets
1 192.168.253.1 (192.168.253.1) 0.044 ms 0.117 ms 0.104 ms
[...]
4 d-ed1-i.D.DE.NET.DTAG.DE (62.154.15.198) 7.980 ms d-ed1-i.D.DE.NET.DTAG.DE (62.154.15.194) 8.684 ms *
5 80.157.131.218 (80.157.131.218) 9.658 ms 9.513 ms 9.448 ms
6 core-sto2-po9.netcologne.de (81.173.192.9) 17.951 ms 19.151 ms 8.670 ms
7 swrt-sto7-vl431.netcologne.de (78.35.18.22) 8.785 ms 8.936 ms 8.937 ms
8 * * *
[...]
Tja, vom Knoten geht’s immer direkt ins Netz, nicht über die Freifunk-Infrastruktur.
Um die Performance unseres Netzes zu testen, habe ich eine Gluon-VM vor eine Linux-VM gehängt:
ffgt@testvm:~$ traceroute cachefly.cachefly.net
traceroute to cachefly.cachefly.net (205.234.175.175), 30 hops max, 60 byte packets
1 gw02.ffgt (10.255.0.12) 1.007 ms 1.143 ms 1.172 ms
2 bgp1-gw02.ospf.ffgt (10.255.145.20) 3.126 ms 3.166 ms 3.159 ms
3 100.64.0.6 (100.64.0.6) 3.375 ms 3.398 ms 3.796 ms
4 xmws-gtso-de11.nw.mediaways.net (192.251.226.202) 3.275 ms 4.208 ms 4.508 ms
5 ae1.cr-mira.gut1.he-core.de (80.237.129.49) 4.322 ms 4.374 ms 4.423 ms
6 xmws-gtso-de31-chan-2.nw.mediaways.net (195.71.9.1) 4.492 ms 2.681 ms 2.754 ms
7 et-0-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.59) 8.348 ms 8.792 ms 8.736 ms
8 et-7-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.57) 9.772 ms 9.794 ms et-0-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.59) 8.742 ms
9 vip1.G-anycast1.cachefly.net (205.234.175.175) 8.754 ms 9.514 ms 8.753 ms
Das läuft alles im RZ ab, und damit wirklich über die FF-Infrastruktur, s. o.
ffgt@testvm:~$ wget -O /dev/null http://cachefly.cachefly.net/100mb.bin
[...]
2015-11-05 00:38:55 (11.2 MB/s) - ‘/dev/null’ saved [104857600/104857600]
Warum das „nur“ knapp 100 MBit/sec sind, obwohl vom Gateway aus selber es deutlich schneller ist, ist uns aber auch noch nicht ganz klar:
root@gw02:~# wget -4 --bind-address=10.255.0.12 -O /dev/null http://cachefly.cachefly.net/100mb.bin
[...]
2015-11-05 00:39:58 (56.5 MB/s) - ‘/dev/null’ saved [104857600/104857600]
Aber, ja, wie einer meiner Oberstufen-Pauker wieder und wieder skandierte: wer viel mißt mißt Mist