Dev March 2016

dev@lists.ffnw.de

18 participants
38 discussions

by Johannes Rudolph

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

8 years, 11 months

MTU detection

by Tim Leerhoff

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

9 years

[Fwd: [WLANware] [ANNOUNCE] Gluon v2016.1.3]

by Bjoern Franke

-- xmpp bjo(a)schafweide.org

9 years

ecdsakey

by Jan-Tarek Butt

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

9 years

Vorgehen Hood Umstellung

by Stefan

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

9 years

Fwd: Merging User-Repo

by Clemens John

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 -------------------------------------------------------------

9 years, 1 month

batman-adv-dkms 2016.0 verfügbar

by Bjoern Franke

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

9 years, 1 month

DNS Abfrage von router-shell

by Tim Leerhoff

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

9 years, 1 month

Nächste Firmware

by Stefan

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

9 years, 1 month

Fwd: Nondeterministic image breakage [observed on TL-WR841N v5]

by Jan-Tarek Butt

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

9 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev March 2016