- Dev - Freifunk Nordwest

0.7
by Jan-Tarek Butt 01 Feb '16

01 Feb '16

Hi, Ich habe gerade 0.7 Testing neu gebaut mit ein paar Änderungen. Die SSID ist wieder auf testing.nordwest.freifunk.net und testing.mesh.ffnw.de gesetzt. Zudem habe ich IEEE 802.11s erst mal raus geschmissen und die BSSID von IBSS wieder auf die Testing BSSID geändert. Somit gibt es kein meshing zwischen dem Stable Netz und dem Testing Netz zumindest auf lokaler ebene nicht. vg Tarek

1 0

Dringender Hinweis zum Einsatz von Testing-Firmware
by Clemens John 01 Feb '16

01 Feb '16

Hi, ich habe mich um einen Blogbeitrag zur aktuellen Problematik gekümmert: https://blog.nordwest.freifunk.net/wp-admin/post.php?post=1447&action=edit Es müssen noch folgende Dinge ergänzt werden: * Problembehebung per SSH * Foto von Versions-Schildchen WR841NDv10 Mag sich dem jemand annehmen? Ich würde den Beitrag gerne morgen veröffentlichen. Ich habe hinsichtlich des Testing-Channels auch unser Wiki geupdated um den Verwendungszweck des Channels klar zu stellen: https://wiki.nordwest.freifunk.net/Router/Firmware Viele Grüße Clemens

1 0

Nächste Firmware Version
by Jan-Tarek Butt 30 Jan '16

30 Jan '16

Hi zusammen, Wie wollen wir das nächste Release angehen. Wir haben bereits einige wr841v10 im Einsatz die auf der Testing Firmware laufen. Der Autoupdater läuft bei den Routern auf Stable so das die Router auf eine Firmware > 0.7 warten. Zudem haben wir das Problem das die v10 erst mit gluon v2016.1 supported werden. Mein Vorschlag wäre wir bauen 0.7 mit der Basis v2015.x und die v10 bleiben weiter in testing somit werden diese erst gegen Mitte Februar in Stable kommen. Es gab ein Vorschlag die v10 aus testing in stable zu übernehmen und das reguläre stable auf Basis von v2015.x zu belassen. Allerding fände ich eine Mischung von testing uns stable unschön. Wie seht ihr das? Wie wollen wir vor gehen?

6 29

Fwd: [batman-adv - Bug #213] (Resolved) batman-adv gets confused if multiple interfaces sharing the same macaddr are bridged to multiple VLANs on the same batX interface
by Bjoern Franke 29 Jan '16

29 Jan '16

Yay! -------- Ursprüngliche Nachricht -------- Von: redmine(a)open-mesh.org Gesendet: 29. Januar 2016 10:43:54 MEZ Betreff: [batman-adv - Bug #213] (Resolved) batman-adv gets confused if multiple interfaces sharing the same macaddr are bridged to multiple VLANs on the same batX interface Issue #213 has been updated by Simon Wunderlich. Status changed from New to Resolved This issue has been fixed with release 2015.2 ---------------------------------------- Bug #213: batman-adv gets confused if multiple interfaces sharing the same macaddr are bridged to multiple VLANs on the same batX interface https://www.open-mesh.org/issues/213#change-697 * Author: Alessandro Bolletta * Status: Resolved * Priority: Normal * Assignee: Simon Wunderlich * Category: * Target version: ---------------------------------------- How to reproduce this bug: if I create 2 VLANs on the top of a bat0 interface and then I bridge bat0.x with eth0.x and and bat0.y with eth0.y, and if eth0.x and eth0.y share the same MAC address, the batman-adv routing engine gets crazy. Infact, if I try through another host facing to bat0.x or/and bat0.y to do a batctl traceroute pointing to the MAC address of the host who shares the same MAC address, I can see that the routing path changes unexpectedly, getting right for a while and then randomly gets wrong, such as in a loop fashion. At the moment, in order to avoid this behaviour, the best workaround I found is having different MAC addresses on *every* interface bridged on a different vlan configured the same mesh cloud interface (let's assume bat0, for example). It's not so much pratical, especially for who wants to configure (and then bridge with external interfaces) many VLAN interfaces on the batman-adv mesh. I'm going to categorize it as a "bug", since it's a batman-adv related problem and I think it should be great if it could be solved. ---Files-------------------------------- batmanadv-vlan-loop-graph.pdf (386 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://hostname/my/account

2 1

hoodselector
by Jan-Tarek Butt 15 Jan '16

15 Jan '16

Hi, @Clemens: Magst du ein Feedback zu Issue #14 geben bzw. wenn es geklärt ist das issue schließen, dann könnte ich wie geplant zum Wochenende eine neue Firmware bauen zum Testen. vg Tarek

2 2

Ansible ist ein IT-Automatisierungs-Tool
by picard 14 Jan '16

14 Jan '16

Moin, wer kein interesse an "IT-Automatisierung" oder auch gennant Orchestrierung, allgemeinen Konfiguration und Administration von Computern hat, kann hier aufhören zu lesen. Vergleichbar Puppet, Chef und weitere. Wer jetzt noch Interesse hat, ich hatte davor bereits Puppet als Konfigurationsmanagement angesehen und bin dabei auf keinen grünen Zweig gekommen. Es musste sowohl am Server als auch auf den Clients zusätzlich Software installiert werden, dann war der Sprachsyntax für die Konfigurationen zu lernen. Das geht nicht einfach mal so, hier muss viel Zeit investiert werden. Nicht so bei Ansible: Der Einstieg ist denkbar einfach. Ansible wird auf einem Server installiert (am Besten über die Paketverwaltung) als Abhängigkeit gibt es nur eine funktionierende Python-Installation. Dies wird allerdings auch von der Paketverwaltung übernommen. Auf den zu verwaltenden Clients wird nur SSH benötigt. Das war es auch schon. Zudem ist der Syntax der Sprache der verwendeten Dateien einfach und gut zu lesen. Obwohl die Sprache einfach gehalten ist, lassen sich damit Konstrukte wie Variablen, bedingte Anweisungen und Schleifen verwenden. Zudem gibt es die Möglichkeit Rollen zu erstellen, die sich dann auf Server anwenden lassen. Hier nochmal meine Gründe für die Verwendung von Ansible: Sichere und einfache Verbindung über SSH Keine Clientsoftware notwendig Einfacher Sprachsyntax (YAML) Flexibilität durch die Verwendung von Variablen und Rollen Mein Ziel ist es z.b Freifunk Router mit Ansible für gewisse gegebenheiten Automatisiert einzurichten. Ich fange dann mal an zu lernen, mal sehen wann ich die ersten Freifunk Router Orchestrieren kann. http://www.admin-magazin.de/Das-Heft/2015/04/Workshop-Automatisierung-mit-A… Hast du auch interesse Ansible zu lernen? Melde dich gerne bei mir. -- Gruß pic Xmpp: picard(a)ffnw.de & picard(a)fr32k.de @ME https://wiki.nordwest.freifunk.net/picard

1 0

1043 v3
by Stefan 12 Jan '16

12 Jan '16

Moin zusammen, mittlerweile gibt es vom 1043 die Version 3. Können wir hierfür ein Image bekommen? Leider werden wohl nur noch v3 ausgeliefert. Danke Stefan

2 1

Review und Milestones für die Hoods
by Clemens John 08 Jan '16

08 Jan '16

Hi, ich habe heute Nachmittag ein (Code-)Review des aktuellen Standes bezüglich der Hoods gemacht. Den Puppet-Teil habe ich dabei allerdings ausgeklammert. Ich habe mir insbesondere die Bereiche Hoodgen, Hoodfile und Gwselector angesehen. Das sieht ja schon echt gut aus! Um den Überblick zu behalten habe ich ein Dokument mit Dokumentation zum aktuellen Stand erstellt: * https://pad.ffnw.de/p/hoods-umsetzung-v1 Ich habe außerdem für alle drei Bereiche Tickets mit Punkten angelegt, die mir aufgefallen sind. Diese habe ich in Milestones gesammelt: * Hoodgen: https://git.nordwest.freifunk.net/baranator/hoodgen/milestones/1 * Hoodfile: https://git.nordwest.freifunk.net/ffnw/packages/milestones/4 * Gwselector: https://git.nordwest.freifunk.net/ffnw/packages/milestones/3 Mir hilft das zumindest den aktuellen Stand zu verstehen. Bisschen Probleme hatte ich da noch beim Fallback-Modus des Gwselectors aber da hilft Tarek mir evtl. nochmal. Oder müssen wir uns den Fallback allgemein nochmal ansehen? Viele Grüße Clemens

2 1

gwselector
by Jan-Tarek Butt 08 Jan '16

08 Jan '16

Hi zusammen, @Tim: ich hab dich mal in den CC genommen da ich mir gerade nicht sicher bin ob du noch auch unser dev ML bist. ich habe in den letzten Wochen am gwselector geschrieben und bin aktuell an einen Punkt angekommen wo ich mir schon seid Tagen den Kopf zermartere. Aktuell gibt es ja wie im wiki beschrieben [0] den on- / offline selector. Der online selector ist relativ trivial und auch bereits größtenteils implementiert. Bei dem offline selector überlege ich schon länger wie man den implementieren sollte und bisher ist mir noch keine überzeugende Möglichkeit eingefallen. Die Variante an der ich gearbeitet hatte, scannt nach benachbarten wlans mit der identischen ESSID und übernimmt die BSSID des Nachbar WLANs mit der besten Signal quallity und das auch nur wenn es sich um ein reinen mesh Router handelt. Nun hab ich mir gedacht das es evtl. zu Problemen kommen würde wenn jetzt z.b. temporär die vpn Verbindung eines Routers ausfällt, würde der Router automatisch die bssid des Nachbar VPN Routers übernehmen. Kommt dann wieder der vpn des ersten Routers online würde somit automatisch eine loop zwischen zwei hoods entstehen. Ich bin mit gerade nicht ganz sicher wie man das vernünftig lösen kann. vg Tarek

4 11

Aufgaben für die Puppet Umstellung
by Jan-Tarek Butt 06 Jan '16

06 Jan '16

Hallo zusammen, diese Mail soll eine liste von Entwicklungsaufgaben beinhalten die in eigene Projekte gefasst werden können. Falls jemand zeit und Lust hat, sich einzelne aufgaben raus zu picken kann sich gerne melden. Projekt 1: packages für unser debian ffnw repo erstellen. Unter der Domain http://repo.ffnw.de/ führen wir ein eigenes ffnw repo. Folgende Packages werden für das repo benötigt: "fastdtop" und "fastd-statistics". Ein benötigtes python module ist "npyscreen" dazu müsste auch ein package gebaut werden. Die o.g. tools bieten den admins Unterstützung zur Fehler Analyse. link zu den tool quellen: https://github.com/ffrl/ff-tools/tree/master/fastd "batctl" Version 2015.1. Batctl ist das verwaltungs tool für Batman-adv link zu den tool quellen: https://downloads.open-mesh.org/batman/stable/sources/batctl/ Wichtig ist die version batctl 2015.1 Eine kurtze doku zum erstellen von packages findet ihr hier: https://wiki.nordwest.freifunk.net/Admin-Bereich/services-doku/packages Zitat von Bjo: Für "Wie baue ich das Paket selbst" studiere bitte die Debian- Paketerstellungsseminare 1-3 (oder auch: Wie man PKGBUILDs lieben lernt). Projekt 2: Manifest identisch dem firmware manifest für die hoodfiles ertellen. Es wird ein Makefile für das erstellen eines Manifests der hood.json datein benötigt hier ist es wichtig das ähnlich wie bei gluon auch unterschiedliche branches existieren können also z.B. stable und testing. In dem Makefile sollte dann denke ich auch noch ein json validator eingebaut sein. Beides sind aufgaben die meinerseits nach dem gwselector anstehen. Besonders das 2.Projekt ist für die Umstellung auf puppet essentiell und würde eine Verzögerung bis voraussichtlich ende Jannuar / Mitte Februar erzeugen. vg Tarek

3 3