- Dev - Freifunk Nordwest

Meshviewer & ffmap-backend merger
by Stefan 04 Feb '16

04 Feb '16

Hi zusammen, ich habe mit heute einmal daran gesetzt einen Meshviewer zu bauen, der die Daten aus mehreren nodes.json bekommt. Ein entsprechenden ffmap-backend Merger habe ich auch gebaut. Soweite funktioniert alles und ein Meshviewer mit weiteren Funktionen wie z.B - Filter nach Gateway - Bessere Darstellung des Meshes ist jetzt unter http://meshviewer.dev.ffnw.de/ zu finden. Ich werde mich die Tage noch dran setzen weitere Funktionen einzubauen, die manchen aus dem Netmon fehlen. Auch in diesem Bereich sind wir jetzt einen großen Schritt in Richtung Hoods gegangen. Jetzt werden schon die Daten aus dem NordWest Netz und unserem Event Netz in Osnabrück gemerged. --- Viele Grüße Stefan

2 1

Re: [Dev] Changelog 0.6.3
by Jan-Tarek Butt 03 Feb '16

03 Feb '16

Moin, Dadurch schaltest du doch den autolocator wieder standardmäßig ein. Richtig, er war somit quasi nie per default Disabeld. Finde ich persönlich nicht gut, da immer noch viele Router mit autolocator falsch positioniert sind! Das stimmt. Ich weiß inzwischen auch was genau das Problem ist. Ich hatte Clemens dazu bereits gesondert eine Mail geschrieben und schreibe sie gleich noch auf die dev Liste. Das standard mäßige abschalten des geolocators ist nicht so gut da sonst niemand Koordinaten in die Router einträgt und die brauchen wir für die Hoods. Ich arbeite bereits an einer Möglichen alternative. Geoclue in Kombination mit dem Mozila location service Gruß Tarek

1 0

Roadmap für Februar
by Jan-Tarek Butt 01 Feb '16

01 Feb '16

Hi, Ich habe mir in den letzten tagen über die kommenden Releases Gedanken gemacht. Ich plane im Februar 6 Firmware zu Releasen. Aktuell haben wir Stable 0.6.2 mit der basis gluon v2015.1.x und Testing 0.7 mit der basis gluon master. (0.6.2)gluon2015.1.x (0.7)gluon master | /| | / | | / | | / | | / | | / | (0.6.3)gluon2015.1.x / | | / | | / | | / | | / | | / | | / | (0.7.1)gluon master | | \ | | \ | | \ | | \ | (0.7.2)gluon2015.1.x \ | | \ | | \ | | \ | (0.7.3)gluon2015.1.x \ | | \ | | (0.7.2)gluon master | | * | (0.8)gluon master | * Firmware (Stable) 0.6.3 zur basis gluon2015.1.x kriegt einen gepatchten autoupdater der, falls die basis gluon2015.1.x ist, die Firmware Version 0.7.1 ignoriert wird. Firmware (Stable) 0.7.1 zur basis gluon master kriegt ebenfalls einen gepatchten autoupdater der, eine zeitliche Verzögerung beim updaten zwischen VPN Routern und reinen Mesh Routern erzeugt. Zusätzlich wird der update branch von stable auf testing umgebogen. Firmware (Stable) 0.7.2 zur basis gluon2015.1.x. Der gepatchte Autoupdater wird entfernt. Dazu wird der Hoodselector mit eingebaut. Firmware (Testing) 0.7.2 zur basis gluon master. Der gepatchte Autoupdater wird entfernt. Stable u. Testing Netz trennen Firmware (Testing) 0.8 zur basis gluon master Hoodselector ausrollen Firmware (Stable) 0.7.3 zur basis gluon2015.1.x Ausrollen der ersten hood vg Tarek

2 2

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