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