Neue Firmware 2018.2.1

Fr Apr 26 19:01:04 CEST 2019

Hi Ulf,

1. Jepp, das ist in Gluon nicht vorgesehen.

2. Dokumentiert ist alles bereits im Wiki des Gluon GitHub Repository:

https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration

3. Das wäre auch eine Möglichkeit, /etc/rc.local bleibt beim Update erhalten. Wenn man dort prüfen würde, ob die Einstellungen stimmen und sie ansonsten neu setzt, sollte das klappen.

Gruß
David

> Am 26.04.2019 um 18:28 schrieb ub1x at gmx.net:
> 
> Hallo Zusammen,
> 
> bin zwar recht unbeteiligt bei dem Thema (bis jetzt - habe zwar Martin Unterstützung versprochen, warte aber noch auf seine Rückmeldung).
> 
> Aber zum Thema:
> 1. Wenn ich David richtig verstanden habe liegt das am original Firmware build (also openWRT oder Gluon) - habe ich das richtig verstannden?
> 2. Ist es möglich diese Info auf Eurem Wiki zu Veröffentlichen, damit die Informationen gesammelt vorhanden sind (habe jetzt ehrlich gesagt nicht nachgeschaut ob sie schon da sind)
> 3. Wäre ein Script das automatisch nach dem Neustart ausgeführt wird und entweder remote geladen bzw. lokal nach einem Update nicht überschrieben wird und automatisch gestartet wird eine Option?
> 
> Schönes Wochenende
> Ulf
> 
> Gesendet: Freitag, 26. April 2019 um 18:02 Uhr
> Von: "David Lutz via ff3l" <ff3l at ff3l.net>
> An: "ML [Privat]" <martin.lehmann at daheim.org>
> Cc: ff3l at ff3l.net
> Betreff: Re: Neue Firmware 2018.2.1
> Hallo Martin,
> 
> Die Diskussion kommt jetzt seit 5 Jahren immer wieder hoch ;)
> 
> Für a) gibt es eine Option, um die Änderung fix zu machen:
> 
> uci set gluon-core. at wireless[0].preserve_channels='1'uci commit gluon-core
> 
> Für das b) Problem gibt es leider immer noch keine Lösung. Schon seit geraumer Zeit soll das ganze Networking modernisiert werden. Es gibt aber einen (unsupporteten) Workaround: Statt WAN und LAN zusammenzubridgen, kannst du WAN und LAN tauschen. Damit hast du dann 4 gebridgte WAN-Ports und einen LAN-Port. Ob das in Zukunft irgendwann zu Problemen führen könnte, kann ich nicht sagen.
> 
> LAN und WAN Port tauschen
> in /etc/config/network die Worte eth0 und eth1 tauschen
> 
> beim 3600/4300er TP-Link eth0 durch eth0.1 und eth1 durch eth0.2 ersetzen
> in /lib/gluon/core/sysconfig die Dateien lan_ifname und wan_ifname anpassen (Inhalt tauschen)
> 
> cat /lib/gluon/core/sysconfig/wan_ifname
> cat /lib/gluon/core/sysconfig/lan_ifname
> echo eth0 > /lib/gluon/core/sysconfig/wan_ifname
> echo eth1 > /lib/gluon/core/sysconfig/lan_ifname
> 
> Die sauberste Lösung wäre allerdings, einen kleinen Switch zu verwenden.
> 
> Gruß
> David
> 
> Am 26.04.2019 um 17:46 schrieb ML [Privat] <martin.lehmann at daheim.org <mailto:martin.lehmann at daheim.org>>:
> 
> Hallo David,
> 
> es ist leider so, dass man inzwischen fast bei jeden Freifunk-Firmware Update manuell nacharbeiten muss,
> weil gesetzte Settings nicht beibehalten werden, sondern vom Firmware-Update überschrieben werden.
> 
> Beispiele:
> 
> a) Channel Config wurde gelöscht:
> uci set wireless.radio0.channel='xx'
> --> wird mit Channel 1 überschrieben
> 
> b) LAN-Switch-Config wurde gelöscht:
> uci set network.client.ifname='bat0'
> uci set network.wan.ifname='eth0 eth1'
> --> wird auf Default zurückgesetzt, d.h. bat0 wird mit eth1 gebridged.
> 
> In der Folge hatten wir diverse Ausfälle und Switching/MESH-Chaos.
> Wenn jemand eine Hand voll ff3l Router verwaltet, mag das "Zurücksetzen" akzeptabel sein, aber bei sehr vielen Routern geht das nicht mehr spurlos.
> 
> Die Netz-Config und WLAN-Config muss bei Firmware-Updates bitte unbedingt unberuehrt bleiben.
> 
> Wie kann man verhindern, dass "Custom Settings" im Bereich LAN/WLAN durch ein ff3l Firmware-Update in Zukunft überschrieben werden?
> 
> Viele Gruesse,
> Martin
> 
> -----Ursprüngliche Nachricht----- From: David Lutz via ff3l
> Sent: Thursday, April 25, 2019 11:12 AM
> To: ff3l at ff3l.net <mailto:ff3l at ff3l.net>
> Subject: Re: Neue Firmware 2018.2.1
> 
> Hi zusammen,
> 
> Wenn niemand etwas dagegen hat, würde ich die neue Firmware gerne im
> Laufe des Tages ausrollen.
> 
> Gruß
> 
> David
> 
> 
> Am 04.04.19 um 17:46 schrieb David Lutz via ff3l:
> Achja, hätte ich fast vergessen:
> 
> Es werden neue Geräte unterstützt:
> 
> AVM Fritz!WLAN Repeater 300E
> Nexx WT3020AD/F/H
> Gl.iNet MT300N (v2)
> Netgear R6120
> TP-Link Archer C50 (v3, v4)
> TP-Link TL-WR841N (v13)
> 
> 
> Gruß
> 
> David
> 
> 
> Am 04.04.19 um 11:52 schrieb David Lutz via ff3l:
> Hallo liebe Mitfunkende*innen/außen,
> 
> Seit etwa zwei Wochen gibt es ein neues Gluon Minor Release.
> 
> Die Firmware ist grob getestet, liegt auf dem Server bereit und ist seit
> eben für den experimental-Zweig für den Autoupdater signiert.
> 
> Version 2018.2 hat sich bei uns als stabilste Firmware seit langem
> bewährt. Trotzdem haben sich ein paar kleine Bugs eingeschlichen, die in
> diesem Release behoben sind:
> 
> So wurde bei einer Vielzahl der Geräte die IPv6-Adresse doppelt
> angezeigt und es gab auf der Statusseite teilweise falsche Anzeigewerte
> zur Speicherauslastung.
> 
> Für ein paar Geräte (GL.iNet GL-AR150/300M/750, Raspi B+) wurden die
> Imagenamen behoben, die Probleme mit dem Autoupdater verursachen können.
> 
> Bei Unifi AC Geräten wurde teils die falsche MAC-Adresse verwendet.
> 
> Bei ath10k-Geräten wurde ein Bug in der Data Rate Selection behoben,
> die teilweise eine 5GHz-Verbindung verhindert hat.
> 
> 
> Zudem habe ich in dieser Firmware die OSM-Unterstützung aktiviert, die
> es seit 2018.2 gibt (und die ich beim letzten Mal vergessen habe... 🙄).
> Man kann also, wenn man einen Knoten konfiguriert, direkt auf der
> Konfigurationsseite die Koordinaten auf einer Karte auswählen.
> Dazu ist allerdings eine Internetverbindung während der Konfiguration
> notwendig (beispielsweise per WLAN).
> 
> Ich hoffe, dass wir die Firmware in Bälde ganz ausrollen können.
> 
> Liebe Grüße
> 
> David
> 
> 
> 
> 
> 
> 
> 

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.ff3l.net/pipermail/ff3l/attachments/20190426/7c913faf/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.ff3l.net/pipermail/ff3l/attachments/20190426/7c913faf/attachment.sig>