March 2016 - Dev - Freifunk Nordwest

Hood Mesh BSSID
by Johannes Rudolph 22 May '16

22 May '16

Moin, in abspreache mit Stefan bastel ich gerade am ersten Hoodfile. Ich bin über den Punkt Mesh BSSID gestolpert. Aktuell ist diese bei uns "02:CA:FF:EE:BA:BE" und für die Default Hood kann diese auch so bleiben. Kann ich einfach nach freidünken für Hoods andere BSSID vergeben, oder gibt es da vorgaben die ich noch nicht kenne`?! Ansonsten mach ich einfach: 02:CA:FF:EE:BA:BE -> Default Hood 02:CA:FF:EE:BA:B0 -> Hood Osnabrück 02:CA:FF:EE:BA:B1 -> Hood Butjardingen/Friesland/Wilhelmshaven/Wittmund und die später folgenden Hoods werden weiter hochgezählt. 02:CA:FF:EE:BA:B2 02:CA:FF:EE:BA:B3 02:CA:FF:EE:BA:B4 02:CA:FF:EE:BA:B5 02:CA:FF:EE:BA:B6 02:CA:FF:EE:BA:B7 02:CA:FF:EE:BA:B8 02:CA:FF:EE:BA:B9 Meinungen / Wünsche / Kritik / Lob / Tadel / Zustimmung / Ablehnung?! Keine Reaktion deute ich mal als Zustimmung Gruß Johannes

4 7

MTU detection
by Tim Leerhoff 05 Apr '16

05 Apr '16

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

5 12

[Fwd: [WLANware] [ANNOUNCE] Gluon v2016.1.3]
by Bjoern Franke 01 Apr '16

01 Apr '16

-- xmpp bjo(a)schafweide.org

3 3

ecdsakey
by Jan-Tarek Butt 31 Mar '16

31 Mar '16

Moin, git diff 0.8 master diff --git a/site.conf b/site.conf index 0c13daa..3139a53 100644 --- a/site.conf +++ b/site.conf @@ -24,12 +24,12 @@ channel = 6, htmode = 'HT40+', ap = { - ssid = 'nordwest.freifunk.net', + ssid = 'testing.nordwest.freifunk.net', }, ibss = { - ssid = 'mesh.ffnw', - bssid = '02:CA:FF:EE:BA:BF', + ssid = 'testing.mesh.ffnw', + bssid = '02:CA:FF:EE:BA:BE', mcast_rate = 12000, }, @@ -42,12 +42,12 @@ channel = 44, htmode = 'HT40+', ap = { - ssid = 'nordwest.freifunk.net', + ssid = 'testing.nordwest.freifunk.net', }, ibss = { - ssid = 'mesh.ffnw', - bssid = '02:CA:FF:EE:BA:BF', + ssid = 'testing.mesh.ffnw', + bssid = '02:CA:FF:EE:BA:BE', mcast_rate = 12000, }, @@ -127,6 +127,7 @@ '1f45d9be8a07cc2b6fcc384c71685fc0895a54be0d884aa4637c93ec4f36d970', --stefan6 '36dff98a686a15d7fb129fe98df7977c7d53919aa512b825356bd8d638fca534', --PowerPan '13f022eb0704007a58a6a68952feaa5a91af4015db46f13bf3eb676a06e926f2', --fkr + 'cc2e9b38ebe37613aa05bde6c0543a97a72940b1eee9f8ab89236e804cf0a3ff', --lethexa }, }, testing = { @@ -145,6 +146,7 @@ '36dff98a686a15d7fb129fe98df7977c7d53919aa512b825356bd8d638fca534', --PowerPan '13f022eb0704007a58a6a68952feaa5a91af4015db46f13bf3eb676a06e926f2', --fkr 'f89880c62f6975facbffa582f6a7078a63102477f1770f429f4e6e2a1ac7506f', --runner02.ffnw.de + 'cc2e9b38ebe37613aa05bde6c0543a97a72940b1eee9f8ab89236e804cf0a3ff', --lethexa }, }, }, Ich wollte mal fragen wem der key mit dem Kommentar lethexa gehört. Gruß Tarek

2 2

Vorgehen Hood Umstellung
by Stefan 31 Mar '16

31 Mar '16

Hey zusammen, in den vergangenen Tagen hat sich bei den Hoods sehr viel im Hintergrund getan - mittlerweile haben wir eine Firmware gebaut - als Testing natürlich - mit der sich die Router ohne Probleme im neuen Hood-Netz verbinden und Clients dort alles machen können. Den Source für die einzelnen Module werden Simon und ich heute nocheinmal updaten und auf Gitlab rüberziehen. Die Puppet Module sind soweit fertiggeschrieben und funktioniert - im nächsten Schritt sollten wir alle auf einen Nenner kommen, wie wir das Netz gut & strukutiert umstellen können. Ich hatte mir hier schon meine Gedanken gemacht und mit dem ein oder anderen kurz gesprochen. Mein Vorschlag wäre folgender: Wir würden srv08 & srv03 als eigenständige Hoods vorbereiten, Wittmund und Oldenburg darauf umziehen, sodass im alten Setup etwa 200 Peers frei werden. Danach können wir jedes Gateway (srv06, 10, 11, 12) nach und nach vom Netz nehmen und auf Puppet umstellen. Dadurch hätten wir kurzerzeit 2 Netze, jedoch blieben alle Router online. Als weiteren Schritt sollten wir darüber nachdenken, den srv04 ersteinmal so online zulassen, damit sich alte Router hier weiterhin verbinden können und ein Firmware Update auf > 0.6.2 erhalten. Später wenn keinerlei Peers mehr vorhanden sind, könnte dieser auch umgezogen werden. Das dynmaische Routing mit OSPF läuft auch schon, sprich die Server erkennen ob diese einen direkten Exit zum Rheinland haben oder nicht. Ist letzteres der Fall, würde die Default Route auf den am wenigsten genutzten Exit umgestellt. Ich hoffe, dass viele meine Meinung hier teilen, denn diese Umstellung haben wir bei dem Batman 2014 > 2015 Update schon so vollzogen und das Ganze war ja vo Erfolg gekrönt. Viele Grüße, Stefan

7 28

Fwd: Merging User-Repo
by Clemens John 29 Mar '16

29 Mar '16

Hi, ich leite das mal eben auch hier weiter... ---------- Weitergeleitete Nachricht ---------- Betreff: Merging User-Repo Datum: Freitag, 18. März 2016, 21:54:30 CET Von: Clemens John <clemens.john(a)floh1111.de> An: dev(a)simon.kurka.cc, stefan(a)osnabrueck.nordwest.freifunk.net Hi Simon und Stefan, ich habe die Repos von Simon, die Stefan heute ins Gitlab gezogen hat, als Submodule im Puppet Repo hinzugefügt und das Data Repo gemerged. Das Network Repo habe ich komplett ersetzt. Beim User-Repo treten allerdings Konflikte auf, bei denen ich nicht genau weiß, was am sinnvollsten ist. Simon wenn du dort einmal nachsehen könntest wäre das super. Der Master von diesem Repo: https://git.nordwest.freifunk.net/ffnw-puppet/ puppet-user-new soll in den Master dieses Repos: https:// git.nordwest.freifunk.net/ffnw-puppet/puppet-user gemerged werden. Der passende Merge dazu geht folgendermaßen: # git clone --recursive git@git.nordwest.freifunk.net:ffnw-puppet/puppet.git # cd puppet/environments/production/modules/user/ # git checkout master # git remote add simon git@git.nordwest.freifunk.net:ffnw-puppet/puppet-user- new.git # git fetch simon # git branch simon-user simon/master # git merge simon-user Referenzen: http://blog.caplin.com/2013/09/18/merging-two-git-repositories/ Beim Mergen treten allerdings Konflikte auf die du dir einmal ansehen und auflösen müsstest. Über kurze Rückmeldung würde ich mich freuen. Wenn wir damit durch sind dürften alle Repos umgezogen sein. Viele Grüße Clemens -------------------------------------------------------------

3 5

batman-adv-dkms 2016.0 verfügbar
by Bjoern Franke 27 Mar '16

27 Mar '16

Ahoi, ich habe die osterliche Zeit genutzt, um ein fpm-cook-recipe für batman-adv-dkms zu schreiben. Im Repo haben wir nun ein 2016.0-DKMS- Paket für amd64: # [freight] adding batman-adv-dkms_2016.0-2_amd64.deb to pool vg bjo -- xmpp bjo(a)schafweide.org

2 1

DNS Abfrage von router-shell
by Tim Leerhoff 25 Mar '16

25 Mar '16

Hallo Leute, ich hab man 'ne ganz blöde Frage: Wie wird bei den Routern die Namensauflösung durchgeführt ? Die resolv.conf zeigt auf localhost. Der dnsmasq scheint nichts zu tun. Wenn ich z.B. nslookup srv06.ffnw.de ausführe, bekomme ich kein Ergebnis. Server: 127.0.0.1 Address 1: 127.0.0.1 localhost nslookup: can't resolve 'srv06.ffnw.de': Name or service not known Wie wird von den fastd-servern die IP ermittelt, wenn in der Konfiguration nur der Name steht ? Irgendwas übersehe ich hier ;-) Gruß Tim

2 1

Nächste Firmware
by Stefan 25 Mar '16

25 Mar '16

Hey, ich hatte gerade schon kurz mit Tarek gesprochen. Ich fände es sinnvoll, wenn die nächste Firmware direkt die 0.9 sein würde, in der ein Autolocaterfix und der Hoodselector implementiert sein würden. Eure Meinung dazu? @Tarek: Denkst du noch an die Implementierung des site_codes, je nachdem welche Hood gewählt wurde das dieser auf die in der hood.json Datei definierten Namen geswitched wird? Dadurch können wir nachher einfacher im Monitoring nach Hoods selektieren. -- vg Stefan

3 6

Fwd: Nondeterministic image breakage [observed on TL-WR841N v5]
by Jan-Tarek Butt 25 Mar '16

25 Mar '16

Hi, der Bug zum TL-wr841n-nd-v5 ist doch nicht behoben... Möglicherweise sind auch 841 v9 und v8 betroffen. Upstream tickets: https://dev.openwrt.org/ticket/21773 https://dev.openwrt.org/ticket/21857 vg Tarek

2 4