Moin,
zusammen mit Stefan habe ich eine Lösung entwickelt, mit der wir im Meshviewer schnell sehen können welche Router in welcher Hood ist.
Dieses wird durch den siteCode in der site.conf gesteuert.
Die site.conf ist auch auf dem Router abgesichert und wird von respondd ausgelesen.
respondd sammelt die Daten zusammen und sendete sie an Alfred bzw im neuen Setup an den Nachfolger.
Demnach müsste die site.conf bei setzten eine Hood durch den Hoodselector angepasst werden. Ich habe dieses auch schon erfolgreich testen können.
https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/feature/SiteC…
Was haltet ihr davon? Meinungen?
Gruß
Johannes
Hi,
ich habe mir nach dem letzten Arbeitstreffen den hoodselector nochmals
angeschaut und durch gespielt.
https://pad.ffnw.de/p/hoods-testcases
(Ab den Punkt Hoodselector evaluirungsphase)
Wir haben in dem Pad vor ein paar Wochen test-cases eruiert. Es
fehlt im Grunde ein testcase wo Clemens und ich, länger drüber
diskutiert haben und uns letztlich dafür entschieden hatten diesen Fall
erst mal auszuschließen.
Aktuell ist es so, das der hoodselector, wenn er keine geo Position hat,
nach benachbarten BSSIDs von Mesh Routern scannt und anschließend die
dazu gehörige hood aus dem hoodfile holt. Wenn keine hood zu der
gescannten BSSID existiert beendet sich der hoodselector und bleibt
weiterhin in der hood die beim Durchlauf zuvor gesetzt wurde.
Wenn wir jetzt einen Mesh-Router haben und einen VPN-Router die
miteinander meshen und es wird z.B. eine neue Firmware mit neuen hoods
verteilt, kann folgendes Problem auftreten. Der VPN-Router updatet
vor dem MeshRouter und wechselt in eine andere neue Hood. Der
Mesh-Router wäre somit offline und würde kein Firmware Image bekommen.
Nun kommt ein Lösungsvorschlag den ich in einer früheren Version des
Hoodselectors schon einmal implementiert hatte.
Wenn der Hoodselector keine geo Position hat, scannt er nach
benachbarten BSSIDs von Mesh Routern um anschließend die dazu gehörige
hood aus dem hoodfile zu holt. Wenn keine hood zu der gescannten BSSID
existiert setzt der Router die gescannte BSSID mit der default Hood.
Anschließend beendet sich der hoodselector.
Problem hierbei ist das zwei Hoods über Layer2 verbunden werden könnten.
Was ein wahrscheinlichen Ausfall beider betroffenen Hoods zur folge hätte.
Mein vorchlag hier wäre also wenn eine gescannte BSSID gesetzt wird,
wird fastd abgeschaltet. Somit kann der Router nur Meshen.
Im nächsten Durchlauf würde der hoodselector dann versuchen eine
geoposition zu beziehen. Ist das nicht erfolgreich so würde der Router
prüfen ob Batman-adv GWs in Reichweite sind. Ist das der Fall beendet
sich der hoodselechtor. Ist es nicht der Fall. So würde der Router
wieder in den scann Vorgang gehen. Solange bis er Batman-adv GWs findet
oder es keine anderen BSSIDs die unterschiedlich zu eigenen sind gibt.
Kann der Hoodselector eine Geoposition ermitteln, so setzt der
Hoodselector wieder die andere Hood und BSSID, die er über die
Geoposition bezogen hatte. Die Folge wäre eine Trennung zum Restlichen
Netz.
Auch hier hatte ich schon eine mögliche Lösung implementiert. Das wenn
der Router eine Hood via Position hat, der Hoodselector prüfen soll ob
er Batman-adv GWs sieht. Wenn ja soll er die hood ganz normal setzen.
Wenn der hoodselector keine GWs findet soll die o.g. scannroutine einsetzen.
package repo:
git diff edbba3be529c0d31c0f529cbaebca6e9edff01cc
58234d27a07fa72f59c7add49da2d02cae0483bc
An dieser stell bin ich mir noch nicht ganz sicher denn es würde wenn
ich mich logisch nicht irre eine loop entstehen das. Der Router eine
bssid des nachbar Routers setzen würde mit abgeschalteten fastd. Im
nächsten Durchlauf hätte der Router ja eine batman-adv GWs und würde
somit wieder eine bestehende hood aus seinen hoodfile entnehmen. Dieses
Phänomen würde somit immer wieder wechselnd eintreten. Eine Elegante
Lösung ist mit noch nicht eingefallen. Evtl. hat jemand von euch eine
mögliche Lösung die ich noch nicht gesehen hab.
Schönen Gruß
Tarek
Hi,
@Johannes:
Ich habe gerade den commit 8c373f9987036f0fd5e024254a0539ceb3109618
rückgängig gemacht da dieser ein falschen File Format Besitz. Die Datei
wurde wohl in dos Format abgespeichert. dos nutzt die Endung CRLF
anstatt nur LF für endlines. Magst du den commit noch mal korrigieren ?
vg
Tarek
Hi,
ich habe git.ffnw.de zu Puppet hinzugefügt. sudo -s funktioniert auch wie
erwartet. Ein normales sudo fragt mich aber nach dem Passwort, das ich
natürlich nicht habe.
+++
git% sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for floh1111:
+++
Kann sich das mal jemand ansehen?
Viele Grüße
Clemens
Moin
Nach dem nun der Geolocator Fix in die Firmware eingebaut ist, sind viele Router schon besser Positioniert.
Nun tritt ein neues Phänomen auf. Viele Router (~70) sitzen auf den Koordinaten (Lat: 51 Lon: 9)
Nach einiger Recherche, danke noch mal an die junge aus Aurich konnte ich das Problem nun nachvollziehen.
Wenn man sich den Code von openwifi.su anschaut [1] sieht man zwischen Zeile 68 und 85 den Grund hierfür.
Wenn keine Netzwerke gefunden worden sind, mit der jeweiligen MAC Adresse oder die gesendeten Netzwerke nicht in der openwifi.su Datenbank sind, wird über die Anfrage IP versucht die Geokoordinate zu ermitteln. (Zeile 71)
Das Ergebnis kann man auch auf dem Router erkennen, da nun in der Antwort die Quality mit 0% angeben wird.
Ist dieses der fall, sollten die Koordinaten zukünftig nicht mehr übernommen werden, da sie die Position der Router in keinem fall widerspiegelt.
Die Zweite Methode dieses zu Verbessern, ist es die Datenbank von openwifi.su mit mehr Daten zu füttern.
Dieses kann jeder machen, der ein Android Handy benutzt. Mann kann sich hier [2] die passende App runterladen.
Ich werde das mal die Tage einbauen, wenn die die Quality der Antwort 0% beträgt, dass die Position dann nicht übernommen wird.
Wünsche Anregungen Fragen, Ergänzungen ?
Gruß
Johannes
[1]
https://sourceforge.net/p/libwlocate/code/ci/master/tree/master/web/getpos.…
[2]
https://f-droid.org/repository/browse/?fdid=com.vwp.owmap
Hallo Tarek,
ich habe die MTU-detection wie besprochen als Daemon implementiert und
würde sie jetzt gerne testen.
Kennst Du jemanden mit einem DSLite-Anschluss und genau diesem Problem,
bei dem ich mich temporär
auf dem Router einloggen (ssh) könnte ?
Gruß Tim
Hallo zusammen,
mittlerweile haben sich ein Großteil der Router auf 0.8.1 upgedatet.
Darin enthalten war eine Verbesserung des Autolocators, dieser scant die WLAN’s in der Umgebung und sendet diese an das openwifi.su Projekt. Der Server versucht dann eine Position aus den empfangenen WLAN Netzen zu ermitteln.
Auf Magische art und Weise sammeln sich gerade um die 15-20 Router irgendwo in Hessen. (51°?0,000'?N 009°?0,000’?E <http://flopp.net/?z=15&m=A:51:9:0:FF-IBB-CleverFit01>) Ich habe mal ein paar rausgesucht, die es betrifft:
DiakoniePflegeschulenOsnabrueck4
FF-OS-PP24-Westerberg-Buedchen
Loppersum-Schlossstr-Outdoor
AlterBrunselHausRechts
FF-IBB-CleverFit01 (http://map.ffnw.de/#!v:m;n:14cc206f8788)
Vielleicht können sich die Eigentümer ja mal bei mir melden. Ich hätte gerne wenn es möglich ist Zugriff auf die Router um dieses Phänomen untersuchen zu können und in naher Zukunft dieses eventuelle Problem beheben zu können.
Natürlich darf auch jeder andere, dessen Router sich dort befindet mir schreiben, ich habe einfach mal ein paar Rausgepickt aus der Masse.
Vielen Dank!
Gruß
Johannes
