June 2016 - Dev - Freifunk Nordwest

next-node fehler in site.conf?
by lrnzo 10 Mar '17

10 Mar '17

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

1 1

Lösung des Hood vs. Kabelmesh Problems
by Simon Kurka 19 Jul '16

19 Jul '16

Hallöle, mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft. Ich habe es noch nicht zu Ende gedacht!! Stichwort VLAN. Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird? Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden. Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält. Auf VLAN 0 könnte man Meta-Daten austauschen, entweder um a) das einheitliche Verhalten des Kabelmeshes sicherzustellen b) ein Layer 3 Routing durch das Kabelmesh zu fahren, z. B. indem die betreffenden Nodes am OSPF Verkehr teilnehmen, o. Ä. Die VLAN-Trennung könnte uns schon jetzt Sicherheit vor Verbinden zweier Hoods bringen, ohne das Kabelmesh gänzlich abzuschalten. Ansonsten, wie gesagt, nur ein kurzer Gedankenblitz, den ich sehr reizvoll finde :) -- Viele Grüße, Simon

7 10

Fehlende Abdeckung OpenWifi
by Johannes Rudolph 28 Jun '16

28 Jun '16

Hallo zusammen, ich habe mich ja schon intensiver mit dem Geolocator beschäftigt und auch ein paar Verbesserungen in die Firmware eingebaut. Aktuell sitzen auf Grund von IP reverse Geocoding einige viele Router in Hesen auf Lat 51 Lng 9. Dieses wird in der Firmware mittlwerweile abgefangen. Router die dort positioniert sind bleiben so lange bis sie etwas WLAN Netzwerke empfangen die auch irgendwann mal bei OpenWifi vorhanden sind oder bis die Koordinaten manuell angepasst werden. Vielleicht sollte wir dadrüber nachdenken ob wir nicht allen Routern mit Autolocator eine bestimmte Position zuweisen, wenn für sie keine Position ermittelbar ist. Dann könnte man in regelmäßigen Abständen automatisiert in den Router listen danach suchen und an die Kontakt eMailadressen, insofern diese vorhanden sind mail verschicken mit dem Hinweis der fehlerhaften Position und mit den 2 Lösungvorschlägen (WLANS scannen mit App / Position manuell im Router eintragen) Die GPS Koordinate ist vor allem, da wir nun auch Hoods haben sehr wichtig für die richtige Wahl des Gateway Servers. Wünsche Meinungen Kommentare und Kritik ist erwünscht ;) Gruß Johannes

1 0

Re: [Dev] [Nordwest] offloader dns problem und einfaches workaround
by lrnzo 24 Jun '16

24 Jun '16

ok, das problem war ein anderes. wenn der hoodselector losläuft, bevor namensauflösung funktioniert hängt der sich gnadenlos auf. dies hat dann erratisches Verhalten wie zB einfrierende shells zur Folge. könnt ihr ausprobieren, wenn ihr mal dafür sorgt, dass unmittelbar nach dem hochfahren, wo der router noch kein dns hat, den hoodselector manuell startet. mit einiger wahrscheinlichkeit bleibt das ding hängen. dann ne weitere ssh-session auf das ding aufmachen und zb mal ifconfig aufrufen oder batctl gwl. friert alles ein. und ein tunnel wird nie aufgebaut. habe aber schon einen patch geschrieben, der zuerst mal testet, ob namensauflösung überhaupt funktioniert und dann erst den rest erledigt. hier mal ein pull-request. forken im gitlab ging iwie nicht wegen visibility level restricted (?) was muss ich tun, damit ich forken kann? oder ist das gar nicht vorgesehen? -------------------------------8<------------------------------- warn: No match for commit d3a71d8259a57bf9e476438f162f9875fc1a95d7 found at packages-lrnzo warn: Are you sure you pushed 'HEAD' there? The following changes since commit e83ccda778ec0d46444e685808eca9656ef52759: Dont put a slash between hoodname and number! Also added appropriate dns entries to our dns server. (2016-06-02 23:59:33 +0200) are available in the git repository at: https://github.com/lrnzo/ffnw-packages for you to fetch changes up to d3a71d8259a57bf9e476438f162f9875fc1a95d7: geändert: hoodselector/luasrc/hoodselector test-name ist jetzt ffnw.de (2016-06-22 23:27:27 +0200) ---------------------------------------------------------------- Johannes Rudolph (7): hoodselctor: Cron every 2 Minutes fixes #55 hoods.json: Add Second Peer Friesland Fixes #60 hoods.json: Add Hood Butjadingen Fixes #58 hoods.json: Add Hood Wittmund Closes #59 hoods.json: Add Dinklage Fixes #57 hoods.json: Add Lohne Fixes #56 hoods.json: Reduce size of Wittmund lrnzo (2): geändert: hoodselector/luasrc/hoodselector der hoodselector läuft nur noch los, wenn namensauflösung sicher funktioniert. Anderenfalls hängt er sich auf und es hilft nur noch reboot ... also bei mir zumindest. geändert: hoodselector/luasrc/hoodselector test-name ist jetzt ffnw.de hoods/files/lib/ffnw/hoods/hoods.json | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- hoodselector/files/usr/lib/micron.d/hoodselector | 2 +- hoodselector/luasrc/hoodselector | 9 +++++++++ 3 files changed, 122 insertions(+), 2 deletions(-) ------------------------------->8------------------------------- den umgang mit dem git lerne ich auch noch ... Am 19.06.2016 um 12:24 schrieb lrnzo via Nordwest: > Hallo Leute, > > manche stehen ja gelegentlich vor dem Problem, dass Router (insbesondere > Offloader) an unterschiedlchen Anschlüssen nicht oder nur so halb > erratisch online komme. ping 8.8.8.8 geht dann zwar aber ping google.de > nicht und viele fangen dann an, im config mode dhcp und radvd > abzustellen und stattdessen statische v4 configs und statische > DNS-server einzutragen. Ein anderer workaround sieht so aus, dass man > ip-adressen von supernodes in die cofig von fastd hardcoded. Manche > sagen auch, es sei ein Vodaphoneproblem, ich habe es aber nicht nur dort > beobachtet. > > Das kann man sich möglicherweise alles sparen. Ich habe gerade mal > versuchsweise im conigmode v6 auf WAN deaktiviert und schon läuft alles > wie es soll: Namesauflösung, tunnelaufbau, hoodselector. > > kann das jemand mal bei sich reproduzieren? > > LG Lorenz > _______________________________________________ > Nordwest mailing list > Nordwest(a)lists.ffnw.de > https://lists.ffnw.de/mailman/listinfo/nordwest

2 3

Sign Request 1.0
by Johannes Rudolph 18 Jun '16

18 Jun '16

Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 1.0 * Gluon-Version: v2016.1.x * Commit ID: f6b390ca332de38f01cb8c645d383ddfca31f82b * Download: http://firmware.ffnw.de/1.0 Folgende upstream Änderungen gab es: ar71xx-generic OpenMesh MR600 (v1, v2) MR900 (v1, v2) OM2P (v1, v2) OM2P-HS (v1, v2) OM2P-LC OM5P OM5P-AN Ubiquiti Rocket M XW TP-LINK TL-WR841N/ND v11 Bugfixes build: fix race condition caused by using certain make targets (like clean, images or package/*) with parallel build options without doing a full build before build: fix package dependency issue causing “recursive dependency” warning This dependency issue could lead to broken configurations and reportedly caused failed builds in some cases when additional (site-specific) packages were used. build: Gluon will now build correctly with GCC 6 as host compiler Fix configuration of batman-adv when VLANs are used on top of IBSS interfaces (regression due to netifd update in Gluon 2016.1.4) Add back missing ath10k firmware (regression due to mac80211 update in Gluon 2016.1.4) Gluon can now be used on all supported Ubiquiti AirMAX devices without downgrading to AirOS 5.5.x before Gluon 2016.1.1 added support for most Ubiquiti AirMAX devices with AirOS 5.6.x without downgrading AirOS, but left some devices (at least some PicoStations and Bullets) with unwritable flash. This issue has been resolved (#687). Add upgrade script to automatically remove whitespace from configured geolocation The new respondd implementation included in Gluon 2016.1 is stricter about the number format than the old one and doesn’t accept trailing whitespace (so one or both coordinates are missing from the output). The Config Mode has been fixed to strip whitespace from numeric fields in new configurations since Gluon 2016.1.1. This still left old configurations, which are now fixed by this script. Folgende Comunnity speziffischen Änderungen gab es: * Add hood lk-os to hoodfile * Add hood ol to hoodfile * Add hood lk-fri to hoodfile * Add hood lk-st to hoodfile * bugfix hoodselector restart bridge interface * bugfix hoodselector wrong characters inside UCI Section-Namen Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden: git diff v1.0 v0.9 Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: git diff v1.0 v0.9 Viele Grüße Johannes

4 5

Planungen nächste Hoods
by Stefan 06 Jun '16

06 Jun '16

Hey, nachdem wir die ersten Hoods ja produktiv umgestellt haben sollten wir uns Gedanken über die nächsten Schritte machen. Ich hätte hier folgenden Vorschlag: - Hood Budjadingen (2 fastd Instanzen mit jeweils 100 Peers) - Hood Rastede (1 oder 2 fastd Instanzen mit jeweils 100 Peers) - Ein VM für 2 Hoods, Lohne und Dinklage - jeder würde hier 100 Peers bekommen. Die VM könnte auf srv16 Von Budjadingen wird es auch Geld für einen Server geben - das kläre ich grade mit Matthias Schulz ab. Eine weitere Hood für Rastede mit 2 fastd Instanzen für 200 Router. Meinungen oder Einwände? Die serverseitige Einrichtung würde ich dann wohl erledigen ;) Stefan

3 4

Umzug der Supernodes nach puppet.ffnw.de
by Clemens John 06 Jun '16

06 Jun '16

Hi, ich werde am Montag (morgen) die Supernodes vom Testmaster auf den Prodkuktivmaster puppet.ffnw.de umziehen. Der Master ist soweit vorbereitet und getestet. Falls jemand Einwände hat bitte ich um einen Alternativvorschlag mit Zeitplan zum Umzug. Viele Grüße Clemens

4 9

automatische vs statische Koordinaten
by lrnzo 04 Jun '16

04 Jun '16

moin, was passiert eigentlich, wenn man auf nem router automatische _und_ statische Koordinaten einstellt? wäre es nicht sinnvoller, wenn sich im config mode diese beiden häkchen gegenseitig ausschließen? lg lorenz

2 1

Neue webseite
by Jan-Tarek Butt 04 Jun '16

04 Jun '16

Hi, ich hab die neue Webseite mal überflogen und nen Haufen issues aufgemacht. https://git.nordwest.freifunk.net/ffnw/web/issues Generell sollten die links noch mal alle überprüft werden einige von dehnen sind tot. Zudem scheinen in der Kategorie -> Firmware -> kompilieren und angrenzende. zitierte Kommandos falsch dar zustellen. vg Tarek

1 0

hoodselector: falsch positives Ergebnis bei function directVPN() ?
by lrnzo 02 Jun '16

02 Jun '16

Hallo, wenn ich das richtig verstehe, guck die funktion ja in originator-table und gibt true zurück, wenn sie irgendwo den string mesh-vpn findet. Aber wird auch der Wert last-seen berücksichtigt? beispiel: Knoten hat vpn verbindung, der letzte originator-frame ist keine 5 sekunden alt. directVPN() -> TRUE. alles io. jetzt verliert der knoten aus $gründen seine vpn verbindung, aber in der orignator-table werden immer noch massenweise zeilen gefunden, die den string mesh_vpn enthalten, aber natürlich nur zombies sind. directVPN() -> TRUE, obwohl vpn in Wahrheit tot ist. Oder ist das alles viel einfacher? lg lrnzo

2 1