wir programmieren gerade auch an etwas, was automatisch die Koordinaten bestimmt. Also über die WLANs in der Nähe, sowas ähnliches hatte ich auch mal in eurer Firmware gesehen. Zumindest vermute ich, dass es so geht.
Wir wollten uns dazu eigentlich mal euren Quellcode anschauen, aber das Repo ist nicht öffentlich:
unser git ist gerade offline. Einsehbar ist der Code auf jedenfall
Aktuell nutzen wir http://www.openwifi.su für die Positionsbestimmung. Das Ganze steigt und fällt allerdings auch mit der Datenabdeckung. Auf dieser Seite wird das regelmäßig aktuallisiert: http://owm.vreeken.net/map/
Zum sammel von Daten kann man die Android App nutzen. Das Steht alles auf der http://www.openwifi.su Webseite.
Mittlerweile funkltioniert es ganz gut, wenn denn Daten und WLAN Netzte vorhanden sind, dort wo der Router aufgestellt ist.
Wir sind aktuell auch im engen Kontakt mit den Betreibern von http://www.openwifi.su um das Projekt zu erweitern. Aktuell ist Doku noch mangelware. Wir arbeiten dran
Ich finde das Ergebnis auf der Map nicht so überzeugend, um es vorsichtig zu formulieren?
https://www.wigle.net/ liefert vermutlich nicht deutlich besser und selbst der Service von Mozilla ist eher dürftig nach meiner Beobachtung.
Will sagen: So schlecht, dass es einem eigentlich nur die Karte ruiniert.
Okay, das geht hier nicht in die Richtung, die ich wollte.
Wir wollen die Knoten nicht auf der Karte einblenden. Das kann nach wie vor entweder manuell erfolgen oder sie sind eben nicht drauf, aus welchen Gründen auch immer, die wir respektieren möchten.
Worum es geht, ist, die Knoten bei der Netzsegmentierung einzuteilen. Aus Datenschutzgründen soll das auf den Knoten selbst passieren und wir bekommen als Ergebnis lediglich die Nummer des Polygons, in dem der Knoten liegt. Das kann dann in den Firmwareserver übertragen werden und die passende Firmware ausgeliefert werden.
Soweit so gut. Wir schreiben das ganze in Lua und der Algorithmus für die Polygone steht soweit. Was noch fehlt ist die Abfrage zu machen, wo der Knoten steht. Dazu möchten wir gerne einfach Google nutzen. Die haben wohl die größte Datenbank und wenn man Daten abfragt, bekommen sie auch keine Daten, die sie vorher noch nicht hatten.
Das funktioniert allerdings über eine Post-Abfrage. Curl ist nicht installiert und das verkrüppelte Wget auf den Routern kann kein POST. Daher hätte es mich interessiert, wie das bei eurem Paket gemacht wurde.
Vermutlich werden wir aber in den sauren Apfel beißen und die 13 K große Lua-Bibliothek nehmen, die POST-Abfragen kann.
Es sei denn, jemand hat eine Idee, wie man mit Hausmitteln auf Gluon eine Post-Abfrage macht.
in dem gluon-banner script von mir ist das geoguess script
das holt sich via einer wget und einem Proxy aus dem mozilla Datenbestand die geocoordinaten…
#!/bin/sh
wget -qO- "$(i=0;echo -n "http://openfreiburg.de/freifunk/geoguess.php?";for line in $(iwinfo phy0 scan |grep -o -E '([0-9a-fA-F]{2}[:]){5}[0-9a-fA-F]{2}') ; do if [ $i != 0 ] ; then echo -n "&"; fi; echo -n "mac"$i"="$line; let i++; done)"
Die Idee ist das die nahen anderen AccessPoints mit ihrer MAC als Liste abgefragt werden.
<?php
function IsValid($mac)
{
return (preg_match('/([a-fA-F0-9]{2}[:|\-]?){6}$/', $mac) == 1);
}
# validate and append all macs
foreach($_GET as $mac=>$val)
{ if(IsValid($val)) { $full .= "{\\\"macAddress\\\": \\\"$val\\\"}," ; } };
# remove last ","
$full = rtrim($full, ",");
# substr($full,0,-1);
system("wget -qO- \"https://location.services.mozilla.com/v1/geolocate?key=test\" --post-data=\"{ \\\"wifiAccessPoints\\\": [$full],\\\"considerIp\\\": \\\"false\\\"}\" ");
?>
damit bekommst du dann so eine Ausgabe wie :
# beispiel vom laptop (angepasstes wget)
$ geoguess
{"location": {"lat": 48.0191097, "lng": 7.8173728}, "accuracy": 20.2240507}
das kannst du benutzen um zum Beispiel geocoordinaten einzutragen , dazu gäbe is in dem gluon-banner auch miniscripte für lat (latitude) lon(longitude) alt(höhe) location(aktivieren) @MPW mit diesen Beispielen solltet ihr etwas bauen können was passt.
Läuft soweit gut, das muss jetzt noch als Gluonpaket verpackt werden. Da hab ich mich noch gar nicht mit beschäftigt, aber das wird machbar sein.
@PowerPan, Frage bzgl. des Hoodselectors. Wenn ich das richtig sehe, wird da nur der VPN-Zugang getauscht? Ein echter siteselector sit das nicht oder? Bei uns ändert sich dann auch der Name des Meschnetzes etc.
Wir wollen jetzt quasi erstmal, dass die passende Domäne an uns zurück geliefert wird und dann können wir nochmal drüber schauen, bevor ggfs. die falsche Domäne ausgeliefert wird.
das könnt ihr ja an euere Bedürfnisse noch anpassen.
Dafür müsst ihr nur das hood file mit den nötigen Parametern ergänzen und dem Teil im Hoodselector erweitern bei dem auch die VPN EInsteluugen gesetzt werden mit den zusätzlichen Infos
Unsere Knoteneinrichtung bedingt seit längerem eine Koordinatenangabe. Diese kann durch einen »educated guess« erleichtert werden (Abgleich der WLANs via Google-API), ansonsten gibt man jene halt über die Karte (ffmap-d3 mit eingenem maptile-Backend) oder direkt ein.
Das Mapping Knoten<>Aufstellgebiet läuft servergestützt: der Knoten schickt die Koordinaten an einen zentralen Server, jener gibt den sog. »locode« zurück, anhand des »locode« sucht der Knoten die passende site.conf-Datei und nutzt fortan jene. Somit decken wir mit einer Firmware beliebige Gebiete ab, haben aber eben auch einen zentralen Service, der funktionieren muß. (Mittlerweile läuft ein eigener Nominatim-Server zu diesem Zwecke, mit Fallback auf öffentliche Services.) Und, klar, alles läuft über plain-HTTP und GET, weil mehr geht auf 4MB-Knoten halt nicht.
Da Nominatim erwähnt wurde: eine case-Schleife matcht vom Ortsnamen auf einen locode:
$unlocode="xxx";
switch($cityname) {
case "Guetersloh":
$unlocode="gut";
break;
case "Rheda-Wiedenbrueck":
$unlocode="gto";
break;
case "Rietberg":
$unlocode="gto"; # rig
break;
case "Harsewinkel":
$unlocode=$ver>1?"gt8":"gto"; # hsl
break;
case "Herzebrock-Clarholz":
$unlocode="gto"; # hzc - chz
break;
case "Langenberg":
$unlocode="gto"; # lbb
break;
case "Steinhagen":
$unlocode=$ver>1?"gt8":"gto"; # sgn
break;
case "Verl":
$unlocode="gto"; # vrl
break;
case "Halle Westf.":
$unlocode=$ver>1?"gt8":"gto"; # hae
break;
case "Halle Westfalen":
$unlocode=$ver>1?"gt8":"gto"; # hae
break;
case "Schlosz Holte-Stukenbrock":
$unlocode="gto"; # shs
break;
case "Werther":
$unlocode=$ver>1?"gt8":"gto"; # wxr
break;
case "Borgholzhausen":
$unlocode=$ver>1?"gt8":"gto"; # bha
break;
default:
$unlocode="zzz";
if($zipcode > 17100 && $zipcode < 17300) {
$unlocode="wrz";
}
if($state == "Mecklenburg-Vorpommern") {
$unlocode="wrz";
}
if($zipcode > 33300 && $zipcode < 34000) {
$unlocode="gut";
}
if($state == "Nordrhein-Westfalen") {
$unlocode=$ver>1?"gt8":"gto";
}
break;
}
return($unlocode);
Dadurch können wir servergesteuert zuordnen; wer wozu gehört. Aktuell teilen wir in Stadt GT (gut), Nordkreis (zukünftig gt8) und Südkreis (gto); warum GT drei UN/LOCODEs zugewiesen bekommen hat, entzieht sich meiner Kenntnis, aber es ist durchaus praktisch
Ja kann man auch so lösen. Allerdings bist du von einem zentralen Dienst auf einem der Server abhänhig.
Unsere Hoodselector hat diese Abhängigkeit nicht.
Für den Fall das keine Koordinaten vorhanden sind, oder die angebenen Koordinaten in keiner Hood sind. Haben wir eine „default“ Hood für alle die sich nirgendwo zuornden können.
Diese Porblematik betrifft nur die VPN Uplink Knoten.
Mesh Knoten suchen sich dann die Hood anhand der BSSID. Ist keine bekannte Hood bssid vorhanden sucht der Knoten nach einem in unserem Fall Netzwerk mit dem Namen „mesh.ffnw“/ bzw automatisiert nach der Mesh BSSID aus /etc/config/wireless und verbindet sich damit und sucht dann per Autoupdater nach einen updaet
