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
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
>>
>
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
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
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
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
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.
Moin,
ich habe bei mir einen MR3420v3 in Betrieb, für den es leider keinen
offiziellen Support gibt. Der Patch [1] von Jacek Trzcinski funktioniert
gegen 17.01, leider wurde der Patch aber nicht aufgenommen, da es einige
Kritikpunkte gab.
Ich würde den Patch gerne upstream haben, von daher die Frage an Tarek:
wie kriegt man ihn am besten gegen 18.06 rebased?
vg
bjo
[1]https://lists.openwrt.org/pipermail/openwrt-devel/2016-November/003782.ht…
Darauf hab ich die Tage über gewartet ;P
FYI
-------- Forwarded Message --------
Subject: [gluon] [ANNOUNCE] Gluon v2018.1
Date: Sun, 8 Jul 2018 21:57:32 +0200
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>
We're proud to announce a new major release of Gluon!
This release includes:
- more hardware support
- multidomain firmwares (using a single firmware image for multiple meshes)
- VXLAN encapsulation for Mesh-on-LAN/WAN (preventing accidental bridging
of separate mesh networks)
- Router Advertisement filtering (making clients use the closest IPv6
gateway as default route)
- and much more!
All these changes are described in detail on Read the Docs:
https://gluon.readthedocs.io/en/v2018.1.x/releases/v2018.1.html
Thanks to all contributors and testers who helped shape this release!
-- NeoRaider
Hallo zusammen,
in der gluon Version v2018.1 wurde das Flash Layout auf ein paar Geräten
angepasst (TP-Link CPE/WBS 210/510). Nun ist die Frage ob wir mit den update auf
v2017.1.8 die autoupdater url ändern um sicherzustellen das die o.g. Geräte
ältere Geräte vorab immer auf v2017.1.8 updaten bevor diese das Image von
v2018.1 bekommen. Das betrifft nur die o.g. Router und auch nur die Router die
in Zukunft eine ältere Version der Firmware installieren und dann via
autoupdater updaten wollen.
Meiner Meinung nach ist das vernachlässigbar, da wir hier von eine minimal
Anzahl an Geräten sprechen von dehnen auch nur Geräte betroffen sind die
entweder mit einer alten Version in der Vergangenheit geflash wurden und
irgendwann in der Zukunft wieder ans Netz kommen und via autoupdate updaten
wollen. Sowie der Fall das jemand eine alte Version auf die Geräte flasht und
dann updaten will.
Was meint ihr dazu?
vg
Tarek
