- Dev - Freifunk Nordwest

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

Support für MR3420v3
by Bjoern Franke 10 Aug '18

10 Aug '18

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…

1 0

Fwd: [ANNOUNCE] Gluon v2018.1
by Jan-Tarek Butt 19 Jul '18

19 Jul '18

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

3 4

update von älteren Geräten auf v2018.1
by Jan-Tarek Butt 09 Jul '18

09 Jul '18

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

2 2

Fwd: [ANNOUNCE] Gluon v2017.1.8
by Bjoern Franke 21 Jun '18

21 Jun '18

-------- Forwarded Message -------- Subject: [gluon] [ANNOUNCE] Gluon v2017.1.8 Date: Sun, 17 Jun 2018 17:56:16 +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> A new maintenance release of Gluon is out. Gluon v2017.1.8 includes some new hardware support, and various bugfixes for batman-adv, in particular a fix for the infamous "unregister_netdevice: waiting for ... to become free." issue. This and a few other changes are described in the full release notes on Read the Docs: http://gluon.readthedocs.io/en/v2017.1.x/releases/v2017.1.8.html -- NeoRaider

3 2

ffnw repo batman-adv-dkms und batctl Paket update
by Jan-Tarek Butt 20 Jun '18

20 Jun '18

Hi zusammen, Ich habe gerade mal das batman-adv-dkms und batctl Paket geupgradet: batman-adv-dkms von v2017.3 auf v2018.1: Changelog: support latest kernels (3.2 - 4.17) coding style cleanups and refactoring documentation cleanup mark licenses clearer, change UAPI netlink header from ISC to MIT add DAT cache and multicast flags netlink support avoid redundant multicast TT entries bugs squashed: avoid spurious warnings from bat_v neigh_cmp implementation fix check of gateway availability in B.A.T.M.A.N. V fix locking for bidirectional TQ check counters remove leak of stack bits in fragmentation header priority fix packet checksum handling in receive path fix handling of large number of interfaces fix netlink dumping of gateways and BLA claims+backbones update data pointers after skb_cow() fix header size check in batadv_dbg_arp() fix skbuff rcsum on packet reroute fix multicast-via-unicast transmission with AP isolation fix packet loss for broadcasted DHCP packets to a server fix multicast packet loss with a single WANT_ALL_IPV4/6 flag batctl von v2017.3 auf v2018.1: Changelog: synchronization of batman-adv netlink and packet headers coding style cleanups and refactoring documentation cleanup mark licenses clearer, change batman-adv UAPI header from ISC to MIT add DAT cache and multicast flags netlink support disable translation support for non-unicast mac addresses bugs squashed: improve error handling for libnl related errors add checks for various allocation errors Schöne grüße Tarek

1 0

Fastd Verschlüsselung ein/aus
by Klaus Dint 09 Jun '18

09 Jun '18

Über die Config Oberfläche kann man in der Fastd-Firmware auswählen, ob der Tunnel verschlüsselt wird oder nicht. Wie kann ich dies über die Konsole ändern?

3 4

Testing Firmware für APU2
by Malte Modler 08 Jun '18

08 Jun '18

Hi, könntet ihr für folgende Harware eine Testing-Firmware bauen? https://openwrt.org/toh/pcengines/apu2 https://www.pcengines.ch/wle200nx.htm Wir haben die Hardware für Testzwekce angeschafft, und würden auch viel Rückmeldung dazu geben. Bisher haben wir die reguläre x86-64-Firmware verwendet (welche auch gut läuft), die hat aber nicht die richtigen Treiber an Bord. LG Malte

3 3

Roadmap Planung
by Jan-Tarek Butt 26 May '18

26 May '18

Hi zusammen, Ich wollte meine Ideen und Pläne gerne mal vorstellen und gemeinsam mit euren eine Roadmap erarbeiten. :) Meine Pläne für das Netz und die Firmware: 1. Hoodselector fertigstellen: Aktuell fehlen noch ein paar Zustände die in den kommenden Wochen angeschlossen sein sollten. Das betrifft hauptsächlich den BATAMAN_GATEWAY mode. Z.B. das verhalten beim zurück wechseln in die Eigene hood wenn sich ein mesh Router an eine benachbarte hood gehängt hat. Siehe dazu: https://github.com/freifunk-gluon/gluon/pull/997 2. Support für L2TP VPN. Aus dem gluon upstream soll l2tp in unsere Firmware backported werden. Das ist dank der neuen Patch Möglichkeit in unserer Firmware nun relativ einfach realisierbar. 3. Router als Batman-adv Gateways Die Idee hatte ich schon länger im Kopf bin aber bisher noch nicht wirklich dazu gekommen in der Richtung was zu machen. Im Grunde ist die Idee das, leistungsfähigere Router bsp. Archer C7 einen eigenen VPN zu exit Servern aufbauen wie z.B. IPredator, HidemyAss, Tor, usw. Paralell zu den VPN soll ein weiterer VPN fastd oder l2tp die virtuelle mesh Verbindung für das interne Netz weiter zur Verfügung stellen. Vorteile bei dieser Struktur: * Es gibt deutlich mehr Exit Nodes. * Es kommt dem Dezentralen Konzept ein Stück näher. * Unser Server backbone wird entlastet (bessere lasten Verteilung). * Evtl. Technische Lösung der VDS Nachteile: * IPv4 würde in dem Konstrukt wahrscheinlich Probleme machen. Lösung könnte hier ddhcpd sein ein zurzeit experimenteller distributed dhcp Server. 4. Prof of concept erstellen für generische Layer3 Routern zwischen hoods. Hierzu habe ich mir noch keine näheren Gedanken gemacht. Aber der Titel sollte schon aussagen worum es geht. Das sind bisher nur Ideen und Vorstellungen woraus letztlich eine Roadmap entstehen kann. Ich würde mich über feadback und/oder andere Ideen Freuen :) Schöne Grüße Tarek

1 3