Hallo, in unserer site.conf steht ja derzeit folgendes:
next_node = {
ip4 = '10.18.0.127',
ip6 = 'fd74:fdaa:9dc4:127',
mac = '16:41:95:40:f7:dc',
},
und in der site.mk taucht auch eine Zeile mit gluon-next-node auf.
Eigentlich sollte das betreffende Interface local-node@br-client also
die passenden Adressen enthalten. In der Realität hat man aber nach
Eingabe von 'ip a s' nur das hier:
10: local-node@br-client: mtu 1500 qdisc noqueue
link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
inet6 fe80::1441:95ff:fe40:f7dc/64 scope link
valid_lft forever preferred_lft forever
und nun fiel mir gerade auf, dass die v6 Adresse in der site.conf gar
keine 128 bit lang ist sondern nur 64. Da fehlt imho ein :: und es müßte
eigentlich
next_node = {
ip4 = '10.18.0.127',
ip6 = 'fd74:fdaa:9dc4::127',
mac = '16:41:95:40:f7:dc',
},
in der site.conf heißen. Vielleicht war dieser kleine Fehler der Grund
dafür, dass bei uns immer die next-node Adresse nicht funktionierte ?!
Bin gespannt
Lorenz
Hallo,
ich würde es begrüßen, wenn wir ab 2017 unsere Firmware Nummerierung ein
wenig Anpassen, da wir ja mehr ein Rolling Release Zyklus haben als
etwas Statisches.
Mein Vorschlag wir zählen einfach jedes Mal die Laufendenummer hoch.
Mein Vorschlag:
* 17.1
* 17.2
* 17.3
* 17.4
* ....
Und dann ab 2018
* 18.1
* 18.2
* 18.3
Ich glaube das macht mehr sin als das was wir aktuell machen
Meinugen?
gruß
Johannes
Hallo zusammen,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
* Firmware-Version: 1.2
* Gluon-Version: v2016.1.x
* Commit ID: ee597c66769a455d38467192598813e7f8411cfd
* Download: https://firmware.ffnw.de/1.2
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/ee597c...ee597c
Folgende Comunnity spezifischen Änderungen gab es:
package repo:
* logic Fehler im configmode wurden behoben
Das Dropdown menu hat, bei wiederholten ausführen des
configModes seinen zustand nicht wiederhergestellt.
Das setzen zweier uci Parameter ist durch einen Typen Fehler
nie zu Stande gekommen.
* Client seitige Javascript map im configeMode
Es wird nun vom Router aus via Javascript auf den Client eine
OSM Karte geladen, sofern der Client über eine Internet
Verbindung verfügt. Um das selektieren von statischen Geo
Koordinaten zu vereinfachen.
* hoodselector: hoodinfo Sektion in respondd wurde erstellt #63 #48
Über respondd werden nun Informationen über die aktuell
selektierte hood eines Routers verteilt.
* hoodselector: das MOLWM Protokoll wurde implementiert Mesh On Lan
/ Wan Managemend
Das MOLWM Protokoll detektiert hood Kollisionen im mesh on lan
oder mesh on wan. U.a. anhand von Vergleichungen von md5 hashes
der einzelnen hoods.
* hoodselector: Der hoodselector gibt nun returncodes bei der
Terminierung zurück.
* hoodselector: pid datei write Permission wird abgefangen
* hoodselector: Unbenutzte variablen wurden entfernt und das überlappen
von Globalen variablen wurde behoben (zum Einsatz kam luacheck)
* hoodselector: Es können nun mehrere fastd peers mit äquivalenten DNS
aber unterschiedlichen Port bestehen. #40
Das ermöglicht uns anstelle von folgenden zu schreiben:
starwars0.sn.ffnw.de 1001
starwars1.sn.ffnw.de 1010
starwars1.sn.ffnw.de 1011
Lediglich:
starwars.sn.ffnw.de 1001
starwars.sn.ffnw.de 1010
starwars.sn.ffnw.de 1011
Das reduziert somit die ganzen DNS Einträge.
* hoodselector: Im scanmode arbeitet der hoodselector nun nicht mehr mit
einen statisch festgelegten WLAN Interface, sondern scannt über alle WLAN
Interfaces die ein Gerät hat. #69
* hoodselector: Im scanmode wird nicht mehr statisch 30 sec abgewartet
um anschließend zu prüfen ob eine mesh Verbindung besteht. Es wird nun
kontinuierlich geschaut und spätesten nach einem Zeitablauf von 30 sec
fortgesetzt. #70
* hoodselector: Fehlermeldungen werden nun in ein logfile geschrieben und
können und über logread eingesehen werden. #36
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/v1.1.1...v…
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/v1.1.1...v…
Schöne Grüße
Tarek
Hi,
Ich habe den patch mal an die dev ML FWD.
vg
Tarek
-------- Forwarded Message --------
Subject: Hoodselector Parch get GeoPosition From Webservice
Date: Thu, 29 Dec 2016 22:34:23 +0100
From: Johannes Rudolph <johannes.rudolph(a)gmx.com>
To: Jan-Tarek Butt <tarek(a)ring0.de>
Moin,
als Vorbereitung für die Unit Tests die ich einbauen möchte müssen wir mal ein bisschen was segmentieren im hoodselector und besser trennen
Gruß
Johannes
From 28f0fa7aa55b732585197c261c8a242fd2d60a0c Mon Sep 17 00:00:00 2001
From: Johannes Rudolph <johannes.rudolph(a)gmx.com>
Date: Thu, 29 Dec 2016 22:30:59 +0100
Subject: [PATCH] split getGeoLocationFromWebService
---
files/usr/sbin/hoodselector | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/files/usr/sbin/hoodselector b/files/usr/sbin/hoodselector
index 072217b..a70a186 100755
--- a/files/usr/sbin/hoodselector
+++ b/files/usr/sbin/hoodselector
@@ -45,7 +45,7 @@ local function get_geolocation()
local lat = uci:get('gluon-node-info', uci:get_first('gluon-node-info', 'location'), 'latitude')
local lng = uci:get('gluon-node-info', uci:get_first('gluon-node-info', 'location'), 'longitude')
if ( lat == nil or lng == nil ) then
- for scan in io.popen(string.format("lwtrace -t 2> /dev/null"), 'r'):lines() do
+ for scan in get_geoLocationFromWebService():lines() do
if string.find(scan,"(lat)") then
local last_val = nil
for geo in string.gmatch(scan,"[^%s]+") do
@@ -66,6 +66,11 @@ local function get_geolocation()
return ret
end
+-- Get GeoPositon from Webservice
+local function get_geoLocationFromWebService()
+ return io.popen(string.format("lwtrace -t 2> /dev/null"), 'r')
+end
+
-- Return hood from the hood file based on geo position. This method
-- can return the following data:
-- * real hood if a hood could be determined for the given position
--
2.8.1
Hi,
This patch set contains the hoodselector and a hoodfile as exsample.
The hoodselector is a software that creates decentralized, semi automated
ISO OSI layer 2 network segmentation for batman-adv layer 2 routing
networks. This program reads the geobased sub-networks called hoods from
the above mentioned hoodfile. The decision of choosing the right hood is
made on following points: first, the hoodselector checks, if the router
has a VPN connection. If it has, the hoodselector then checks, if a
geoposition was set on the router. Knowing the position of the router the
hoodselector can find the right hood, because each hood is defined with
geocoordinates. If the Router doesn't have a VPN connection e.g. as a mesh
only router, the hoodselector triggers a WIFI scan and searches for
neighboured mesh routers in other hoods. If there is an other router with
a different BSSID but with the same mesh SSID, the router chooses it’s
hood based on the neighboured BSSID. Open issues can be found here[0].
cheers
Tarek
[0] https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues?label_name%…
Jan-Tarek Butt (7):
add exsample hoodfile #789
add PKG Makefile for hoodfile #789
add hoodselector respondd c file #789
add hoodselector respondd Makefile #789
add hoodselector #789
add hoodselector cron file #789
add hoodselector PKG Makefile #789
package/ffnw-hoods/Makefile | 38 ++
package/ffnw-hoods/files/lib/ffnw/hoods/hoods.json | 64 ++
package/ffnw-hoodselector/Makefile | 45 ++
.../files/usr/lib/micron.d/hoodselector | 1 +
package/ffnw-hoodselector/luasrc/hoodselector | 722 +++++++++++++++++++++
package/ffnw-hoodselector/src/Makefile | 6 +
package/ffnw-hoodselector/src/respondd.c | 119 ++++
7 files changed, 995 insertions(+)
create mode 100644 package/ffnw-hoods/Makefile
create mode 100644 package/ffnw-hoods/files/lib/ffnw/hoods/hoods.json
create mode 100644 package/ffnw-hoodselector/Makefile
create mode 100644 package/ffnw-hoodselector/files/usr/lib/micron.d/hoodselector
create mode 100755 package/ffnw-hoodselector/luasrc/hoodselector
create mode 100644 package/ffnw-hoodselector/src/Makefile
create mode 100644 package/ffnw-hoodselector/src/respondd.c
--
2.10.0
Moin,
(der Titel "Firmware Development" auf https://ffnw.de/mitmachen/kontakt/mailingslisten/ hatte mich bewogen die Mail erst an netmon-dev zu senden)
ich war Samstag beim Treffen und hab dort angekündigt, dass ich gerne behilflich bin, die map.ffnw.de zu optimieren.
Mit solchen Anwendungen habe ich täglich zu tun, da ich beruflich Software im Geo/Karten-Umfeld entwickle. Mit JavaScript/Client-Anwendungen hab ich zwar direkt nichts zu tun (dafür hab ich Kollegen :-)), aber ich kenne mich da trotzdem etwas aus.
Ich hab mit Eike schon besprochen was man bei einer neuen Anwendung berücksichtigen sollte. Hauptsächlich sollten die Daten direkt als GeoJSON geladen werden. Den Rest macht dann Leaflet schon automatisch. Das GeoJSON sollte dann auch nur die Informationen beinhalten, die tatsächlich benötigt werden (für die Karte benötigt man sicherlich nicht die Softwareversionsstände).
Ich hab die node/graph.json mal in GeoJSON umgewandelt und ne kleine Demo mit Leaflet erstellt. Sind 3.5k Nodes und 3.2k Links:
http://bogosoft.com/misc/ffnwmap/
Code ist unter:
https://gitlab.com/olt/ffnw-map-demo
Clustering könnte da auch noch eine sinnvolle Ergänzung sein:
http://leaflet.github.io/Leaflet.markercluster/example/marker-clustering-re…http://leaflet.github.io/Leaflet.markercluster/example/marker-clustering-cu…https://github.com/Leaflet/Leaflet.markercluster
Kurzfristig sollte auf map.ffnw.de im Nginx `gzip on` und `gzip_types application/json`. Das macht die Anwendung nicht schneller, die Ladezeit sollte sich aber verkürzen. Aus 4 MB JSON sollten 0.5 MB werden.
Gruß,
Olli
Moin zusammen,
ich habe gerade eben einmal den Nightly Build autoupdater gefixt.
Problem hierbei war es, dass die Verlinkung nicht sauber funktioniert hat.
Nun wird alle 15 Minuten auf dem runner02 gecheckt, ob im Nightly Build
Pfad auf dem srv01 der gleiche Stand vorhanden ist. Sollte dies nicht
der Fall sein, werden die Dateien synchronisiert.
Viele Grüße
Stefan
Hallo zusammen,
heute Abend haben Clemens und Ich ganz nebenbei den Hoodgen repariert.
Der Source ist nun lokal und der Hoodgen kann wieder genutzt werden
inkl. gültigem SSL.
https://hoodgen.ffnw.de/hoodgen.html
--
Viele Grüße
Stefan
Hi zusammen,
es kam vermehrt die frage nach Routerboards ohne WLAN auf.
Ein weiteres Kriterium waren dedizierten GBit Ports.
Der Einsatz war z.b. im Transit-Netz Bereich gefragt.
Ich habe mal ein paar Modelle Raus gesucht die ich bei
Interesse. gerne von unserem DEV Budget kaufen würde um diese
Dann in Gluon zu migrieren.
Mikrotik RouterBoard RB750GL (50€)
https://wiki.openwrt.org/toh/mikrotik/rb750gl
CPU MHz:400
FLASH:128NAND
RAM MB:64
Gbits Ports:5
Mikrotik Routerboard RB493G (200€)
CPU MHz:680/800
Ram_256MiB
Flash:128MiB 1x Micro-SD-socket
Network:9x 1000Base-T
USB:1x 2.0 unpowered
MiniPCI: 3x Type IIIA/B
Weitere HW kann Hier rausgesucht werden
https://wiki.openwrt.org/toh/mikrotik/start
vg
Tarek
Hi zusammen,
ich habe meinerseits die Entwicklung an der Nordwest Firmware sowie der Monitoring-drone und anderen Projekten auf Eis gelegt.
Um mich um den zustand der Server infra zu kümmern.
Dazu hab ich ein zwischen Milestone [0] angelegt indem ich aktuell noch issues sammle um wieder eine stabile Basis für die
Firmware Entwicklung zu schaffen.
Nachdem dieser Milestone erledigt ist, geht es meinerseits mit v1.2 weiter. geschätzter Zeitpunkt ist zwischen 02.2017 und 04.2017.
vg
Tarek
[0] https://git.nordwest.freifunk.net/ffnw-firmware/packages/milestones/16
