ok, das problem war ein anderes. wenn der hoodselector losläuft, bevor
namensauflösung funktioniert hängt der sich gnadenlos auf. dies hat dann
erratisches Verhalten wie zB einfrierende shells zur Folge. könnt ihr
ausprobieren, wenn ihr mal dafür sorgt, dass unmittelbar nach dem
hochfahren, wo der router noch kein dns hat, den hoodselector manuell
startet. mit einiger wahrscheinlichkeit bleibt das ding hängen. dann ne
weitere ssh-session auf das ding aufmachen und zb mal ifconfig aufrufen
oder batctl gwl. friert alles ein. und ein tunnel wird nie aufgebaut.
habe aber schon einen patch geschrieben, der zuerst mal testet, ob
namensauflösung überhaupt funktioniert und dann erst den rest erledigt.
hier mal ein pull-request. forken im gitlab ging iwie nicht wegen
visibility level restricted (?) was muss ich tun, damit ich forken kann?
oder ist das gar nicht vorgesehen?
-------------------------------8<-------------------------------
warn: No match for commit d3a71d8259a57bf9e476438f162f9875fc1a95d7 found
at packages-lrnzo
warn: Are you sure you pushed 'HEAD' there?
The following changes since commit e83ccda778ec0d46444e685808eca9656ef52759:
Dont put a slash between hoodname and number! Also added appropriate
dns entries to our dns server. (2016-06-02 23:59:33 +0200)
are available in the git repository at:
https://github.com/lrnzo/ffnw-packages
for you to fetch changes up to d3a71d8259a57bf9e476438f162f9875fc1a95d7:
geändert: hoodselector/luasrc/hoodselector test-name ist
jetzt ffnw.de (2016-06-22 23:27:27 +0200)
----------------------------------------------------------------
Johannes Rudolph (7):
hoodselctor: Cron every 2 Minutes fixes #55
hoods.json: Add Second Peer Friesland Fixes #60
hoods.json: Add Hood Butjadingen Fixes #58
hoods.json: Add Hood Wittmund Closes #59
hoods.json: Add Dinklage Fixes #57
hoods.json: Add Lohne Fixes #56
hoods.json: Reduce size of Wittmund
lrnzo (2):
geändert: hoodselector/luasrc/hoodselector
der hoodselector läuft nur noch los, wenn
namensauflösung sicher funktioniert. Anderenfalls hängt
er sich auf und es hilft nur noch reboot ... also bei
mir zumindest.
geändert: hoodselector/luasrc/hoodselector
test-name ist jetzt ffnw.de
hoods/files/lib/ffnw/hoods/hoods.json | 113
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
hoodselector/files/usr/lib/micron.d/hoodselector | 2 +-
hoodselector/luasrc/hoodselector | 9 +++++++++
3 files changed, 122 insertions(+), 2 deletions(-)
------------------------------->8-------------------------------
den umgang mit dem git lerne ich auch noch ...
Am 19.06.2016 um 12:24 schrieb lrnzo via Nordwest:
> Hallo Leute,
>
> manche stehen ja gelegentlich vor dem Problem, dass Router (insbesondere
> Offloader) an unterschiedlchen Anschlüssen nicht oder nur so halb
> erratisch online komme. ping 8.8.8.8 geht dann zwar aber ping google.de
> nicht und viele fangen dann an, im config mode dhcp und radvd
> abzustellen und stattdessen statische v4 configs und statische
> DNS-server einzutragen. Ein anderer workaround sieht so aus, dass man
> ip-adressen von supernodes in die cofig von fastd hardcoded. Manche
> sagen auch, es sei ein Vodaphoneproblem, ich habe es aber nicht nur dort
> beobachtet.
>
> Das kann man sich möglicherweise alles sparen. Ich habe gerade mal
> versuchsweise im conigmode v6 auf WAN deaktiviert und schon läuft alles
> wie es soll: Namesauflösung, tunnelaufbau, hoodselector.
>
> kann das jemand mal bei sich reproduzieren?
>
> LG Lorenz
> _______________________________________________
> Nordwest mailing list
> Nordwest(a)lists.ffnw.de
> https://lists.ffnw.de/mailman/listinfo/nordwest
Ich habe heute eine neue Firmware gebaut. Basisdaten:
* Firmware-Version: 1.0
* Gluon-Version: v2016.1.x
* Commit ID: f6b390ca332de38f01cb8c645d383ddfca31f82b
* Download: http://firmware.ffnw.de/1.0
Folgende upstream Änderungen gab es:
ar71xx-generic
OpenMesh
MR600 (v1, v2)
MR900 (v1, v2)
OM2P (v1, v2)
OM2P-HS (v1, v2)
OM2P-LC
OM5P
OM5P-AN
Ubiquiti
Rocket M XW
TP-LINK
TL-WR841N/ND v11
Bugfixes
build: fix race condition caused by using certain make targets (like clean, images or package/*) with parallel build options without doing a full build before
build: fix package dependency issue causing “recursive dependency” warning
This dependency issue could lead to broken configurations and reportedly caused failed builds in some cases when additional (site-specific) packages were used.
build: Gluon will now build correctly with GCC 6 as host compiler
Fix configuration of batman-adv when VLANs are used on top of IBSS interfaces (regression due to netifd update in Gluon 2016.1.4)
Add back missing ath10k firmware (regression due to mac80211 update in Gluon 2016.1.4)
Gluon can now be used on all supported Ubiquiti AirMAX devices without downgrading to AirOS 5.5.x before
Gluon 2016.1.1 added support for most Ubiquiti AirMAX devices with AirOS 5.6.x without downgrading AirOS, but left some devices (at least some PicoStations and Bullets) with unwritable flash. This issue has been resolved (#687).
Add upgrade script to automatically remove whitespace from configured geolocation
The new respondd implementation included in Gluon 2016.1 is stricter about the number format than the old one and doesn’t accept trailing whitespace (so one or both coordinates are missing from the output).
The Config Mode has been fixed to strip whitespace from numeric fields in new configurations since Gluon 2016.1.1. This still left old configurations, which are now fixed by this script.
Folgende Comunnity speziffischen Änderungen gab es:
* Add hood lk-os to hoodfile
* Add hood ol to hoodfile
* Add hood lk-fri to hoodfile
* Add hood lk-st to hoodfile
* bugfix hoodselector restart bridge interface
* bugfix hoodselector wrong characters inside UCI Section-Namen
Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem
Befehl eingesehen werden:
git diff v1.0 v0.9
Die Änderungen an unseren eigenen Paketen können im Packages-Repository
mittels folgendem Befehl eingesehen werden:
git diff v1.0 v0.9
Viele Grüße
Johannes
Hey,
nachdem wir die ersten Hoods ja produktiv umgestellt haben sollten wir
uns Gedanken über die nächsten Schritte machen. Ich hätte hier folgenden
Vorschlag:
- Hood Budjadingen (2 fastd Instanzen mit jeweils 100 Peers)
- Hood Rastede (1 oder 2 fastd Instanzen mit jeweils 100 Peers)
- Ein VM für 2 Hoods, Lohne und Dinklage - jeder würde hier 100 Peers
bekommen. Die VM könnte auf srv16
Von Budjadingen wird es auch Geld für einen Server geben - das kläre ich
grade mit Matthias Schulz ab.
Eine weitere Hood für Rastede mit 2 fastd Instanzen für 200 Router.
Meinungen oder Einwände?
Die serverseitige Einrichtung würde ich dann wohl erledigen ;)
Stefan
Hi,
ich werde am Montag (morgen) die Supernodes vom Testmaster auf den
Prodkuktivmaster puppet.ffnw.de umziehen. Der Master ist soweit vorbereitet
und getestet.
Falls jemand Einwände hat bitte ich um einen Alternativvorschlag mit Zeitplan
zum Umzug.
Viele Grüße
Clemens
moin,
was passiert eigentlich, wenn man auf nem router automatische _und_
statische Koordinaten einstellt? wäre es nicht sinnvoller, wenn sich im
config mode diese beiden häkchen gegenseitig ausschließen?
lg lorenz
Hi,
ich hab die neue Webseite mal überflogen und nen Haufen issues aufgemacht.
https://git.nordwest.freifunk.net/ffnw/web/issues
Generell sollten die links noch mal alle überprüft werden einige von dehnen sind tot.
Zudem scheinen in der Kategorie -> Firmware -> kompilieren und angrenzende. zitierte Kommandos falsch dar zustellen.
vg
Tarek
Hallo,
wenn ich das richtig verstehe, guck die funktion ja in originator-table
und gibt true zurück, wenn sie irgendwo den string mesh-vpn findet. Aber
wird auch der Wert last-seen berücksichtigt?
beispiel: Knoten hat vpn verbindung, der letzte originator-frame ist
keine 5 sekunden alt. directVPN() -> TRUE. alles io. jetzt verliert der
knoten aus $gründen seine vpn verbindung, aber in der orignator-table
werden immer noch massenweise zeilen gefunden, die den string mesh_vpn
enthalten, aber natürlich nur zombies sind. directVPN() -> TRUE, obwohl
vpn in Wahrheit tot ist.
Oder ist das alles viel einfacher?
lg lrnzo
Hi,
das Gitlab ist nun auf dem aktuellen stabile release (8.8.2). Zudem ist in der git VM das git auf 2.8.3 from source aktualisiert.
Ein sehr nützliches feature was hinzugekommen ist, ist das man nun die build logs im RAW output kriegen kann[0].
Das ist für Fehler Analysen sehr hilfreich.
Hinzu kommt das nun die Architekturen von gluon aus dem soruce generiert werden. Somit werden die Targets dynamisch gebaut.
Kommen also neue Architekturen hinzu selektiert der CI bot diese automatisch.
Zuvor hatte der bot nur auf einen thread compiliert. Nun baut der CI bot ebenfalls dynamisch auf allen logischen cores[1].
nach folgender Formel:
(grep -c processor /proc/cpuinfo)*2
Also Anzahl der logic cores mal zwei. Zweit Prozesse pro logik core.
Referrenz[2].
Aktuell ist es noch nicht möglich mit dem make parameter V=s zu compilieren.
Der generierte log output wird mehre GB groß und überbeansprucht das gitlab somit. Dazu gibt es schon ein issue in gitlab [3].
vg
Tarek
[0] https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds/289/raw
[1] https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds/289
[2] https://github.com/FreifunkFranken/firmware/blob/master/buildscript#L219
[3] https://gitlab.com/gitlab-org/gitlab-ci/issues/421
Hi,
ich habe mich gerade kurz mit Clemens über das 1.0 Release unterhalten.
Ich hätte hier folgenden Vorschlag:
- Ich habe nun den Ganzen Puppet Code ins Gitlab rübergezogen und fixe
hier noch Kleinigkeiten
- Wir testen alle die Version 1.0 heute oder morgen und signen diese
schon entsprechend
- Am Mittwoch würden wir ein Blogpost veröffentlichen, damit die Nutzer
von dem Großen Update mitbekommen
- Donnerstag im Laufe des Tages würden wir dann den Symlink umschwenken,
sodass die Version verteilt wird
Einwände oder weitere Vorschläge? :)
Viele Grüße
Stefan
Hey zusammen,
ich mache mich ab jetzt daran die Puppet Repos ins Gitlab (sofern dies
funktioniert) umzuziehen und über unseren Puppetmaster zu deployen.
Dann haben wir später im Puppet Board eine Gute Übersicht, welche
Systeme wie deployed wurden.
VG
Stefan