- Dev - Freifunk Nordwest

Geschäfts- / Projektkreditangebot
by Nucleus Business Loans 20 Nov '18

20 Nov '18

-- Grüße Herr / Frau. Ich bin Berater Bernard Held, und ich bringe Ihnen gute Nachrichten von Nucleus Business Darlehen Rendering-Service aus dem Vereinigten Königreich. Nucleus Commercial Finance hat einen Meilenstein von 750 Millionen Pfund mit dem bisher größten Darlehen angekündigt. Nucleus führt innerhalb von einer Woche eine sehr schnelle Darlehensrücknahme für Geschäft, Projekt, Bau, Marketing, Autokauf und viel mehr bei 1,3% durch. Wenn Sie daran interessiert sind, Erkenntnisse für Ihren Wunschzweck zu erhalten, empfehlen wir Ihnen, Ihre Bewerbungsdetails unten für weitere Details anzugeben. Vollständiger Name:.......... Land:.......... Darlehensbetrag: .......... Darlehensdauer: .......... Der Grund für den Kredit:.......... Telefon:.......... Wir warten so bald wie möglich auf die Bestätigung Ihrer Darlehensdetails, damit wir Ihnen weitere Informationen senden können. Bernard Held Kreditagent / Berater

1 0

Hoodselector fehler?
by Lorenz Wenner 21 Oct '18

21 Oct '18

oh gucke mal! root@ff-os-ameos-Knollstrasse31-P2-nds1284:~# cat /tmp/hoodselector_error Command failed: Not found Failed to parse json data: unexpected end of data Command failed: Not found Command failed: Not found Command failed: Not found Command failed: Not found Failed to parse json data: unexpected end of data ifconfig: SIOCGIFFLAGS: No such device ifconfig: SIOCGIFFLAGS: No such device Command failed: Not found Failed to parse json data: unexpected end of data /usr/bin/lua: /usr/sbin/hoodselector:110: attempt to index local 'a' (a nil value) stack traceback: /usr/sbin/hoodselector:110: in function 'h' /usr/sbin/hoodselector:181: in function 'r' /usr/sbin/hoodselector:481: in main chunk [C]: ? LG Lorenz

3 5

täglicher hoodkurschluss default02 <-> Delmenhorst
by lrnzo 18 Oct '18

18 Oct '18

moin Leute, derzeit klingelt täglch um 5:15 mein Wecker und ich gucke dann ob folgender cronjob 10 5 * * * /root/cronjob-blockfastd.sh mit cat /root/cronjob-blockfastd.sh #!/bin/bash while [[ $(batctl -m bat-default gwl | grep -c MB) -eq 0 ]];do sleep 1;done;/home/lrnzo/block.sh und cat /home/lrnzo/block.sh #!/bin/bash for i in $(/sbin/ifconfig | grep -oP "bat-[0-9a-z]*"); do for j in $(sudo batctl -m "$i" gwl | grep MB | grep -oE '([a-f0-9]{2}:){5}[a-f0-9]{2}' | tail -1); do #for j in 56:3d:f9:ec:ca:37 ba:23:d0:12:e1:af; do if [[ $(echo "$j" | tee mac-addr | grep -cE '([a-f0-9]{2}:){5}[a-f0-9]{2}') -eq 1 ]];then echo "MAC: $(cat mac-addr)" addr=$(/home/lrnzo/fastdlook.py "$j") if [[ $(echo "$addr" | tee ip-addr | grep -cE '([0-9]+\.){3}[0-9]+') -eq 1 ]];then echo "IP: $(cat ip-addr)" echo "die Anschluss-IP $(cat ip-addr) zur Tunnel-MAC $(cat mac-addr) wird geblockt" iptables -A INPUT -s $addr -j DROP iptables -L INPUT | grep DROP fi fi done done den täglich neu auftretenden Kurzschluss gekillt hat. Schuld ist irgendein Router mit der fastd-MAC 8e:83:b2:79:67:3f. Immer gegen 5:10 gibt es für diesen von EWE eine frische Anschluss-ip. ich kann zwar mit ps aux | grep cron root 389 0.0 0.1 29664 2916 ? Ss Okt07 0:02 /usr/sbin/cron -f root 2865 0.0 0.0 4288 720 ? Ss 05:10 0:00 /bin/sh -c /root/cronjob-blockfastd.sh root 2866 0.1 0.1 11184 2944 ? S 05:10 0:01 /bin/bash /root/cronjob-blockfastd.sh sehen, dass der cronjob selber gestartet wird. allerdings sollten sie ja laut code gerade nicht mehr laufen und die Dateien /root/ip-addr /root/mac-addr haben immer noch den timestamp meiner letzten manuellen Ausführung von /root/cronjob-blockfastd.sh. Der Output davon sah heute zB so aus: root@default02:~# ./cronjob-blockfastd.sh MAC: 8e:83:b2:79:67:3f IP: 91.97.13.199 die Anschluss-IP 91.97.13.199 zur Tunnel-MAC 8e:83:b2:79:67:3f wird geblockt DROP icmp -- anywhere anywhere icmp router-advertisement DROP udp -- anywhere anywhere udp spt:bootps dpt:bootpc DROP icmp -- anywhere anywhere icmp router-advertisement DROP udp -- anywhere anywhere udp spt:bootps dpt:bootpc DROP all -- host-091-097-013-199.ewe-ip-backbone.de anywhere läuft also. nur eben nicht per cronjob. Weiß jemand wieso? habe nämlich auf diese Nummer mit dem Wecker um kurz nach 5 dauerhaft keinen Bock. Ja, man sollte natürlich noch in den code einbauen, dass er die zuletzt automatisch geblockte ip zu der aktuelle gefundenen fastd-MAC wieder freigibt. Mach ich irgendwann. LG Lorenz

4 8

Re: Änderung der Voreingestellten Karte
by Stefan Dunkel 18 Oct '18

18 Oct '18

Hi, ich hab hier mal die OpenStreetMap als Standart gesetzt, da es hier schon mehrfach Wünsche gab. VG Stefan Am 28.09.2018 um 17:21 schrieb Thomas Engelmeyer via Dev: > > Hallo zusammen, wäre es schwierig bei der map.ffnw.de die > Voreinstellung auf die zweite Karte zu ändern, so das > „OpenStreetMap.Hot“ Standard wird. > > Hintergrund ist der, wenn in Openstreetmap etwas geändert wird, > schlägt es nach ca. 2 bis 5 min sofort bei „OpenStreetMap.Hot“ durch > und die Map ist wieder aktuell! > > Bei „Freifunk Regensburg Tag“ ist seit Beginn dieser Kartennutzung > keinerlei Änderung durchgeschlagen! > > Wenn möglich bitte den Standard abändern! > > MfG > Thomas > > > _______________________________________________ > Dev mailing list -- dev(a)lists.ffnw.de > To unsubscribe send an email to dev-leave(a)lists.ffnw.de

1 0

Re: täglicher hoodkurschluss default02 <-> Delmenhorst
by Simon Kurka 16 Oct '18

16 Oct '18

Nicht in der common.yml. puppet-fastd repo in files/blacklist.json Stefan Dunkel <stefan(a)osnabrueck.freifunk.net> schrieb am Di., 16. Okt. 2018, 13:01: > Ich nicht :D > Wir haben die blacklist erstellen lassen, jedoch nie definiert wo diese > liegt. > > Von meinem iPhone gesendet > > Am 16.10.2018 um 12:59 schrieb Simon Kurka <simon.kurka(a)ffnw.de>: > > Kann ich mir kaum vorstellen und hätte das gerne nachgesehen, aber das git > gibt einen 503. > > Wer hat da wie dran herumgespielt? > > Stefan Dunkel via Dev <dev(a)lists.ffnw.de> schrieb am Di., 16. Okt. 2018, > 12:57: > >> Hi, >> >> nope, das hatten wir damals nicht so implementiert... >> >> Ich überlege mir was. >> >> >> Von meinem iPhone gesendet >> >> Am 16.10.2018 um 12:45 schrieb Simon Kurka via Dev <dev(a)lists.ffnw.de>: >> >> Müsste über die common.yml im puppet-data repo gehen. >> >> lrnzo via Dev <dev(a)lists.ffnw.de> schrieb am Di., 16. Okt. 2018, 12:44: >> >>> Moin, >>> >>> hatte heute früh testweise mal die /etc/fastd/blacklist.json auf >>> default02.sn.ffnw.de um einen Eintrag für den Kurzschlussrouter mit MAC >>> 8e:83:b2:79:67:3f und key 4ff1ae9a58fe95290290eb4d7826c91675fe1614990472 >>> erweitert, allerdings hat vermutlich puppet meine Änderung wieder >>> rückgängig gemacht. Wie kann der genannte key dauerhaft geblacklisted >>> werden? >>> >>> LG Lorenz >>> _______________________________________________ >>> Dev mailing list -- dev(a)lists.ffnw.de >>> To unsubscribe send an email to dev-leave(a)lists.ffnw.de >>> >> _______________________________________________ >> Dev mailing list -- dev(a)lists.ffnw.de >> To unsubscribe send an email to dev-leave(a)lists.ffnw.de >> >> _______________________________________________ >> Dev mailing list -- dev(a)lists.ffnw.de >> To unsubscribe send an email to dev-leave(a)lists.ffnw.de >> >

1 0

Featureidee verschwundene meshRouter
by lrnzo 25 Sep '18

25 Sep '18

moin :) mir kommt gerade folgende grobe Idee: es gibt im Netz Router, die in Funkreichweite zu Routern stehen, welche nicht mehr meshen können. Ein aktuelles Beispiel ist dieser hier: https://map.ffnw.de/#/de/map/60e327c7417a. der Router funkt nur über ibss, während alle Nachbarn nur noch 802.11s sprechen. Wenn der Techniker nicht informiert wäre, würde der Router einfach von der map verschwinden und sich zu den mittlerweile über 1400 auf https://map.ffnw.de/friedhof/ gesellen. Wäre es nicht ein cooles features, wenn die Router zB einmal täglich ihre Umgebung nach nicht mehr meshenden Nachbarn absuchen und darüber berichten? der oben genannte Router ist nämlich noch via "iwinfo radio0 scan | grep -B1 mesh" sichtbar. LG Lorenz

2 1

Kernelpanic & rebootschleife bei update von 20170822
by lrnzo 25 Sep '18

25 Sep '18

Hallo Leute, bis zu firmware 20170822 hat der autoupdater seine files immer von autoupdate.ffnw gezogen. mit der genannten Version hatten wir das dann umgestellt auf autoupdate-lede.ffnw in den letzten Tagen habe ich mich ein wenig mit der Suche nach alten Routern befasst. Dort, wo ich per ssh hinkomme, habe ich for i in $(wifi status | grep -m 1 -oE "radio.");do iwinfo $i scan | grep -i -C2 mesh;done gemacht, um nodes zu finden, die noch ibss-only sind. Im nächstens schritt wurde der Router, von dem aus gescannt wurde auf die version 20180225 downgegradet, weil das die letzte ist, wo ibss + 802.11s drauf laufen. dadurch kamen dann die ibss-only auch wieder online und konnten sich per autoupdater ein neues image ziehen. allerdings sind ausnahmslos alle, die in version <= 20170822 angetroffen wurde jetzt offline. Ich glaube es liegt daran, dass sie den Schritt von 20170822 auf 20180413 nicht packen. habe genau diesen einmal mit virtualbox durchgespielt und siehe da: kernelpanic & rebootschleife sind das Resultat. ch war mal so frei, und habe einen entsprechenden screenshot angehängt Das ist blöd. kriegen wir das irgendwie gefixt? LG Lorenz

2 2

Sign Request 20180709
by Jan-Tarek Butt 23 Sep '18

23 Sep '18

Moin zusammen, Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20180709 * Gluon-Version: v2017.1.x * Commit ID: e968a225be0efafbd2d4638d0bd530e2d4e841f3 * Download-fastd: https://firmware.ffnw.de/fastd/20180709 * Download-l2tp: https://firmware.ffnw.de/l2tp/20170709 Folgende Gluon spezifischen Änderungen gab es: * modules: update LEDE efb6ca189641 base-files: /lib/functions.sh: ignore errors in insert_modules b5ba01a0d3f6 fstools: update to latest lede-17.01 branch a9b607740273 kernel: bump kernel 4.4 to 4.4.126 for 17.01 09d95e44fc3d mbedtls: change libmbedcrypto.so soversion back to 0 4673a0bffc89 kernel: mtd: bcm47xxpart: improve handling TRX partition size eed9d40133fe ar71xx: Ubiquiti Airmax M: add relocate-kernel to invalidate cache 23a638ebd1fd brcm47xx: backport upstream patches for Netgear WNR1000 V3 999bb66b20b0 kernel: add missing in6_dev_put_clear call to an ipv6 network patch 81573ea25924 kernel: bump kernel 4.4 to 4.4.129 for 17.01 afa887388766 gcc: gcc 6.3.0 fix comparison between pointer and integer * gluon-core: remove DNS cache feature * gluon-core: ensure kernel.core_pattern is set * Backport ar71xx: Ubiquiti UniFi AC MESH * ar71xx-tiny: add support for TP-Link TL-WR940N v5 * ar71xx: add support for TP-Link Archer C7 v4 * ar71xx-tiny: add support for TP-Link TL-WR940N v6 * ar71xx: add support for GL.iNet GL-AR750 * batman-adv: Fix best gw refcnt after netlink dump * batman-adv: Add maint patches between v2017.2 and 2018.1-maint 2018-06-03 * gluon-config-mode-contact-info: provide enhancements for german, english and french translation to comply with DSGVO * batman-adv: add patches from 2018.1-maint 2018-06-12 Mehr und detailliertere Informationen findet ihr hier: https://github.com/freifunk-gluon/gluon/compare/d06427d469230c457ab2b8fc827… Folgende Communnity spezifischen Änderungen gab es: package repo: Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20180413..… siteconf repo: * drop pkg ffnw-netdevice-watchdoog due to upstream fixes * add version number in autoupdater url to ensure every older firmware version will update first to the last gluon v2017.1.x before getting newer. Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20180413..… Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signier… Schöne Grüße Tarek

4 16

Fwd: [ANNOUNCE] Gluon v2018.1.1
by Lorenz Wenner 23 Sep '18

23 Sep '18

FYI -------- Weitergeleitete Nachricht -------- Betreff: [gluon] [ANNOUNCE] Gluon v2018.1.1 Datum: Tue, 28 Aug 2018 21:10:28 +0200 Von: Matthias Schiffer <mschiffer(a)universe-factory.net> An: gluon(a)luebeck.freifunk.net Kopie (CC): Freifunk Firmware Entwicklung <firmware-devel(a)freifunk.net>, WLANware <wlanware(a)freifunk.net> We've have just released Gluon v2018.1.1. This new version fixes a critical regression in the autoupdater that was introduced in Gluon v2018.1, and that could lead to configuration loss in certain configurations. For deployments that are still using a version before v2018.1, we recommend upgrading directly to v2018.1.1. Another regression introduced in v2018.1 and fixed in v2018.1.1 could lead to the IPv4 next-node address of Gluon nodes to become unreachable, which is especially critical in setups that set the clients' DNS resolver to the next-node address via DHCP. As always, the full release notes can be found on Read the Docs: https://gluon.readthedocs.io/en/v2018.1.x/releases/v2018.1.1.html -- NeoRaider

1 0

Please reply to continue
by Ama Abubakar 13 Aug '18

13 Aug '18

My name is Mrs Ama Abubakar,I have been suffering from ovarian cancer disease and I want to entrust this project of helping the less privileged into your hands. I have 1.9 Million US Dollars in a bank in Burkina Faso which I want to entrust into your hands to use in helping the orphanage home in your country, but you must assure me you will take only 40% of the total money and give the rest 60% to the orphanage home. You are free to contact me through amaabubakarr1(a)gmail.com for more details. Regards, Mrs Ama Abubakar.

1 0