FIY
-------- Forwarded Message --------
Subject: [gluon] [ANNOUNCE] Gluon v2016.2.4
Date: Mon, 13 Mar 2017 15:41:34 +0100
From: Matthias Schiffer <mschiffer(a)universe-factory.net>
To: gluon(a)luebeck.freifunk.net
CC: Freifunk Firmware Entwicklung <firmware-devel(a)freifunk.net>, WLANware <wlanware(a)freifunk.net>
Gluon v2016.2.4 is out, this time we have
- fixed batman-adv (15) being unable to transmit packets of some specific
sizes
- fixed a regression in Gluon v2016.2.3 causing high loads in meshes with
many router advertisements
- switched to a working mirror after the ftp.all.kernel.org
discontinuation
and more.
Find the complete release notes at:
http://gluon.readthedocs.io/en/v2016.2.4/releases/v2016.2.4.html
-- NeoRaider
Ich würde lo(c/k)al.nordwest.freifunk.net sagen
Mit freundlichen Grüßen
Jens Ellerbrock
--------------------
Freifunk Nordwest e.V. Website
Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten)
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------Von: Malte Modler via Dev <dev(a)lists.ffnw.de> Datum: 13.03.17 12:01 (GMT+01:00) An: dev(a)lists.ffnw.de Cc: Malte Modler <mail(a)malte-modler.de> Betreff: Re: [Dev] Offline-SSID
no-uplink.nordwest.freifunk.net
Hallo zusammen,
da nun vermehrt Entwicklungen von mehren Personen beigesteuert und
betrieben werden würde ich gerne die Struktur ein wenig anpassen.
Der master branch ist bereits ein protected branch. Das bedeutet
developer stellen an den master branch einen merge request. Der
voreilt bei der Variante ist das es das Revieren von code wesentlich
angenehmer gestaltet. Über die inline Kommentare kann man dann wunderbar
über Änderungen und Verbesserungen schreiben.
Ich habe gerade die Konfiguration dafür im Projekt angepasst und würde
das so probieren wollen um einen besser geordneten Entwicklungsprozess
zu erzielen und das maintanen zu vereinfachen.
Dazu habe ich alle den Status Developer zu geordnet. Was letztlich dazu
führ das automatisch merge requests gegen den master gestellt werden,
sobald man was puscht in den master puschen möchte. Es sollte sich dadurch
für niemanden was ändern und alle sollten wie vorher auch gewohnt am code
arbeiten können.
Falls jemand ein Problem fest stellt was in der jetzigen Konfiguration
jemanden an der Entwicklung behindert. Gerne hier drauf melden damit wir
schauen können wo genau das Problem besteht und ob evtl. mehrere betroffen
sind.
Schöne Grüße und happy coding zusammen :)
Tarek
Hallo zusammen,
nachdem wir einige Stunden debuggt haben, konnten wir eine Lösung für
das Next Node Problem finden.
Unter node.ffnw ist nun als Client die Statuspage des Routes erreichbar.
Dieser DNS Eintrag läst auf die v6 Adresse (fd74:fdaa:9dc4::127) auf.
Das Problem im Bereich v4 ist, dass 10.18.0.127 außerhalb der Hoods
liegt und deshalb nicht erreichbar ist.
Im nexten Schritt sollten wir die Next Node v4 aus der siteconf
entfernen, denn diese ist nun unnötig.
Viel Spaß :-)
VG
Stefan
Moin
habe gerade das hier produziert:
root@whv-rheinstrasse140-1:~# hoodselector
No VPN connection found
Testing neighboring adhoc networks for batman advanced gw connection.
The following wireless networks have been found:
0 2437 02:CA:FF:EE:BA:BE testing.mesh.ffnw
0 5220 02:CA:FF:EE:BA:BE testing.mesh.ffnw
33 2437 02:00:0A:12:E8:00 testing.mesh.ffnw
39 5220 02:00:0A:12:E8:00 testing.mesh.ffnw
After filtering we will test the following wireless networks:
0 5220 02:CA:FF:EE:BA:BE testing.mesh.ffnw
33 2437 02:00:0A:12:E8:00 testing.mesh.ffnw
39 5220 02:00:0A:12:E8:00 testing.mesh.ffnw
Prepare configuration for testing wireless networks...
VPN stopped.
Testing 02:CA:FF:EE:BA:BE...
command failed: Device or resource busy (-16)
Hallo, in unserer site.conf steht ja derzeit folgendes:
next_node = {
ip4 = '10.18.0.127',
ip6 = 'fd74:fdaa:9dc4:127',
mac = '16:41:95:40:f7:dc',
},
und in der site.mk taucht auch eine Zeile mit gluon-next-node auf.
Eigentlich sollte das betreffende Interface local-node@br-client also
die passenden Adressen enthalten. In der Realität hat man aber nach
Eingabe von 'ip a s' nur das hier:
10: local-node@br-client: mtu 1500 qdisc noqueue
link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
inet6 fe80::1441:95ff:fe40:f7dc/64 scope link
valid_lft forever preferred_lft forever
und nun fiel mir gerade auf, dass die v6 Adresse in der site.conf gar
keine 128 bit lang ist sondern nur 64. Da fehlt imho ein :: und es müßte
eigentlich
next_node = {
ip4 = '10.18.0.127',
ip6 = 'fd74:fdaa:9dc4::127',
mac = '16:41:95:40:f7:dc',
},
in der site.conf heißen. Vielleicht war dieser kleine Fehler der Grund
dafür, dass bei uns immer die next-node Adresse nicht funktionierte ?!
Bin gespannt
Lorenz
Hallo Leute,
es kommt manchmal vor, dass ich den hoodselector vorübergehend
deaktivieren muss. Das mache ich immer, indem ich den cronjob in der
/usr/lib/micron.d/hoodselector auskommentiere. Allerdings hilft das in
der aktuellen stable 20170222 nicht, da es scheinbar lt Stefan noch
einen zweiten cronjob irgendwo gibt. Ist das Absicht?
lg lorenz
root@FF-OL-Bültmann-uplink:~# hoodselector
VPN connection found.
Position found.
Set hood "ol"
Hood set by VPN mode.
Interface mesh_wan enabled.
Interface mesh_lan enabled.
root@FF-OL-Bültmann-uplink:~# uci show network | grep auto
network.wan.auto='1'
network.mesh_wan.auto='0'
network.mesh_lan.auto='1'
lg lronz
