July 2016 - Dev - Freifunk Nordwest

next-node fehler in site.conf?
by lrnzo 10 Mar '17

10 Mar '17

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

1 1

Puppet Entwicklungsworkflow
by Bjoern Franke 30 Jul '16

30 Jul '16

Moin, die momentane Situation bezüglich unseres Puppet-Entwicklungsworkflows stößt mir (und vermutlich auch anderen) etwas auf. Wie sieht der momentane Weg aus, um im unseren Puppet was zu entwickeln? - Auf dem Master im Production entwickeln - auf seinen Client kopieren - im git committen Wait, what? Warum machen wir das nicht "the bytemine way"? Ein dev-Branch, da entwickeln (und testen), dann per git commit ins production- Environment? Grüße bjo

4 5

[patch master] fix patching error by emty build_patches dir
by Jan-Tarek Butt 23 Jul '16

23 Jul '16

Signed-off-by: Jan-Tarek Butt <tarek(a)ring0.de> --- buildscript | 2 ++ 1 file changed, 2 insertions(+) diff --git a/buildscript b/buildscript index ae75027..53985c4 100755 --- a/buildscript +++ b/buildscript @@ -122,9 +122,11 @@ get_source() { } patch_target() { + if test "$(ls -A "$PWD""/build_patches/openwrt/")"; then for patch in "$PWD"/build_patches/openwrt/*.patch; do patch --no-backup-if-mismatch -p0 -d "$target" -i "$patch" done + fi } prepare() { -- 2.9.0

2 2

Nächste Firmware
by Jan-Tarek Butt 22 Jul '16

22 Jul '16

Hoi, der Milestone v1.1.1 ist gestern fertig geworden. Zudem ist der Milestone v1.2 auch schon zu annähend 50% fertig gestellt. Wenn niemand was dagegen hat, würde ich v1.1.1 überspringen und direkt v1.2 für einen signed request fertig machen sobald der dazugehörige Milestone fertig ist. Eike arbeitet gerade an der Abstraktion des geolocators issue #22 und ich überlege mir ein Protokolldesign für das mesh on LAN/WAN Management #63. vg Tarek

7 11

hoodselector mesh on LAN/WAN Management
by Jan-Tarek Butt 19 Jul '16

19 Jul '16

Hi, Wie ich in der Mail "Lösung des Hood vs. Kabelmesh Problems" erwähnt hatte. Der neue thread zur möglichen Lösung des mesh on LAN/WAN Problems mit dem hoodselector. Die Idee wäre auf ein separates Protokoll auszuweichen welches aushandelt ob ein mesh Konflikt besteht. Dazu könnte man per respondd checken, ob auf dem mesh-on-wan/lan eine andere Hood läuft und gegebenenfalls das betroffene Interface aus der batman-adv bridge entfernen. Sobald keine fremden hoods mehr das sind könntem die lan/wan interface wieder in die batman-adv bridge. Das könnte über einen Minütlichen cron gelöst werden. Dann könnten wir mithilfe des respondd auch bei unterschiedlichen hoods dynamisch l3 Routing generieren lassen. Diese Lösung könnte unabhängig vom hoodselector arbeiten und als eigenes package gekapselt werden. Es könnte dann sogar unabhängig von hoods relevant werden. z.B. auf Nationales Freifunk Events wenn dort verschiedene communitys zusammen kommen und dort ausversehen in ein mesh on lan/wan Netz kommen. Dann würde das package die Kollision erkennen können und das Problem automatisch beheben. vg Tarek

1 0

Lösung des Hood vs. Kabelmesh Problems
by Simon Kurka 19 Jul '16

19 Jul '16

Hallöle, mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft. Ich habe es noch nicht zu Ende gedacht!! Stichwort VLAN. Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird? Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden. Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält. Auf VLAN 0 könnte man Meta-Daten austauschen, entweder um a) das einheitliche Verhalten des Kabelmeshes sicherzustellen b) ein Layer 3 Routing durch das Kabelmesh zu fahren, z. B. indem die betreffenden Nodes am OSPF Verkehr teilnehmen, o. Ä. Die VLAN-Trennung könnte uns schon jetzt Sicherheit vor Verbinden zweier Hoods bringen, ohne das Kabelmesh gänzlich abzuschalten. Ansonsten, wie gesagt, nur ein kurzer Gedankenblitz, den ich sehr reizvoll finde :) -- Viele Grüße, Simon

7 10

Hoodübergreifendes Routing
by Jan-Tarek Butt 19 Jul '16

19 Jul '16

> das Hoodübergreifende Routing zwischen den neuen Servern funktioniert auch problemlos. > > Das einzigste was derzeit noch nicht geht: Aus der Hood in das Altnetz. Das würde ich mir.die Tage mit Simon einmal zusammen anschauen. > > Aber ich denke der Hoodinterne Traffic ist erstmal wichtiger ;) Sehr gut :) danke dir vg Tarek

2 1

Hoodübergreifendes Routing
by Stefan 19 Jul '16

19 Jul '16

Moin zusammen, das Hoodübergreifende Routing zwischen den neuen Servern funktioniert auch problemlos. Das einzigste was derzeit noch nicht geht: Aus der Hood in das Altnetz. Das würde ich mir.die Tage mit Simon einmal zusammen anschauen. Aber ich denke der Hoodinterne Traffic ist erstmal wichtiger ;) -- vg Stefan

1 0

[master and v2016.1.x] add autoupdater upgrade.d script to drop batman-adv routing tables befor sysupgrade #821
by Jan-Tarek Butt 19 Jul '16

19 Jul '16

--- .../usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100755 package/gluon-autoupdater/files/usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables diff --git a/package/gluon-autoupdater/files/usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables b/package/gluon-autoupdater/files/usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables new file mode 100755 index 0000000..e931a0e --- /dev/null +++ b/package/gluon-autoupdater/files/usr/lib/autoupdater/upgrade.d/10drop-batman-adv-routing-tables @@ -0,0 +1,6 @@ +#!/bin/sh + +. /lib/gluon/autoupdater/lib.sh + +/etc/init.d/fastd restart +wifi -- 2.9.0

3 5

[master] add second drop caches after downloarding Firmware image
by Jan-Tarek Butt 19 Jul '16

19 Jul '16

--- admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches | 4 ++++ 1 file changed, 4 insertions(+) create mode 100755 admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches diff --git a/admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches b/admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches new file mode 100755 index 0000000..814159f --- /dev/null +++ b/admin/autoupdater/files/usr/lib/autoupdater/upgrade.d/95drop_caches @@ -0,0 +1,4 @@ +#!/bin/sh + +sync +sysctl -w vm.drop_caches=3 -- 2.9.0

2 1