From peter.schley at saar.freifunk.net Mon May 19 16:00:35 2025 From: peter.schley at saar.freifunk.net (Peter Schley) Date: Mon, 19 May 2025 16:00:35 +0200 Subject: [freifunk-public] GW1 hat Huddel / Re: Neue Experimental-Firmware 1.13.0~exp20250325 In-Reply-To: <439f3a6b-177a-4d4d-ba0e-f8d187b9361d@web.de> References: <38fc4302-141e-42c4-b6f0-b6073ce4ca82@saar.freifunk.net> <285b3d47-009b-46c1-b229-da9ef4bf26fc@gmx.de> <439f3a6b-177a-4d4d-ba0e-f8d187b9361d@web.de> Message-ID: <4ed39b45-92b6-4fc4-9adf-c8b8535522e0@saar.freifunk.net> Hallo zusammen, das GW1 verteilt aktuell scheinbar wieder keine IPv4-Adressen. Ich kann leider nicht sagen, seit wann dies geschieht, aber ich kann es heute nachstellen. (FW 1.12.0, Domain St. Wendel) Gruß Peter Am 05.04.2025 um 18:59 schrieb Jan Scherer via freifunk-public: > Konnte auf Anhieb keinen Fehler bei GW1 feststellen, auch die Logs sehen > normal aus. > > Starte es gerade mal neu, könnt ihr mal testen ob das Problem dann immer > noch besteht? Bin gerade unterwegs und habe keinen Knoten zum testen. > > Grüße > > Jan > > Am 05.04.25 um 18:56 schrieb Sebastian Fontaine via freifunk-public: >> Hallo und vielen Dank für den Tipp, >> >> habe das GW1 aus der /etc/config/tunneldigger rausgeschmissen und jetzt >> läuft freifunk wieder wie am Schnürchen. >> Könnte man fast als update ausrollen, bis der wieder richtig geht, oder? >> >> Viele Grüße >> Sebastian >> >> >> >> Am 05.04.25 um 08:10 schrieb Peter Schley via freifunk-public: >>> Hallo zusammen, >>> >>> ich konnte das Problem auf den gw1 eingrenzen. >>> Das Problem ist nachstellbar und tritt unabhängig von der >>> Firmwareversion auf. Sobald sich der Knoten mit dem GW1 verbindet, >>> werden keine IPv4-Adressen mehr verteilt. >>> >>> Viele Grüße, >>> Peter >>> >>> >>> Am 03.04.2025 um 07:09 schrieb Peter Schley via freifunk-public: >>>> Hallo zusammen, >>>> >>>> das IPv4-Problem tritt bei mir auch auf. >>>> Situation hier: >>>> - Offloader mit 2x vEthernet (ohne vlan-Experimente o.ä.) >>>> - damals frisch mit 1.11.2 aufgesetzt, danach Updates (inkl. >>>> Experimental und rc) auf 1.12.0 >>>> - nach dem Update auf 1.13.experimental (manuell per sysupgrade) >>>> erhalten die Clients keine IPv4-Adressen mehr. IPv6 funktioniert >>>> augenscheinlich problemlos. >>>> >>>> Ich prüfe das gerne noch mit frischem Setup auf Plastik. Kann aber >>>> noch nicht sagen, wann ich dafür Zeit finde. >>>> >>>> Viele Grüße, >>>> Peter >>>> >>>> >>>> Am 01.04.2025 um 13:44 schrieb Ralf Jung via freifunk-public: >>>>> Hallo allerseits, >>>>> >>>>> während der Auto-updater wegen des IPv4-Problems aus ist, kann die >>>>> Firmware hier manuell heruntergeladen werden: >>>>> >>>>> >>>>> Uns ist aktuell völlig unklar, was das für ein Problem ist, da es im >>>>> Hackerspace von selbst verschwunden ist. Also wenn das jemand testen >>>>> könnte wäre das sehr nützlich. :) >>>>> >>>>> Viele Grüße, >>>>> Ralf >>>>> >>>>> On 01.04.25 13:15, Hassler, Keno via freifunk-public wrote: >>>>>> Hallo liebe Freifunker, >>>>>> >>>>>> es gibt eine neue Experimental-Firmware (1.13.0~exp20250325) auf >>>>>> Basis von gluon 2023.2.4. Damit schließen wir wieder zum aktuellen >>>>>> Stand der gluon-Entwicklung auf. Zur Zeit ist der Rollout noch >>>>>> pausiert, da wir ein Problem mit DHCP vermutet haben (Clients >>>>>> bekamen keine IPv4- Adressen). Sobald wir bestätigt haben, dass das >>>>>> Problem gelöst ist, wird das Update im Experimental-Kanal >>>>>> auftauchen. Upgrade sind nur von Version 1.12 möglich; falls eure >>>>>> Knoten noch auf Version 1.11.2 laufen, müsstet ihr sie also zuerst >>>>>> auf 1.12 upgraden. >>>>>> >>>>>> Zentrale Neuerungen sind zum einen eine modernere Basis mit OpenWrt >>>>>> 23.05, Linux-Kernel 5.15, wireless-backports 6.1.24 und batman-adv >>>>>> 2023.1, und zum anderen WPA3-Support für private WLAN-Netze. Wenn >>>>>> ihr eure Knoten dazu nutzt, euer privates (verschlüsseltes) WLAN zu >>>>>> erweitern, könnt ihr das jetzt auf zeitgemäßem Sicherheitsstand >>>>>> tun. Dieses Feature steht aus Platzgründen aber nur auf Routern zur >>>>>> Verfügung, die genügend Speicher haben (mindestens 7MiB Flash und >>>>>> 64MiB RAM). >>>>>> >>>>>> Neu unterstützte Geräte: >>>>>> - ARM SystemReady 32/64-bit (Images für virtuelle Maschinen auf >>>>>> ARM- Systemen) >>>>>> - ASUS: TUF-AX4200, RT-AX53U >>>>>> - AVM: FRITZ!Repeater 1750E >>>>>> - Cudy: WR3000 (v1) >>>>>> - D-Link: COVR-X1860 (A1) >>>>>> - Enterasys: WS-AP3715i >>>>>> - Extreme Networks: WS-AP3805i >>>>>> - GL.iNet: GL-XE300, GL-MT3000 >>>>>> - Hewlett-Packard: MSM460 >>>>>> - MikroTik: wAPR-2nD (wAP R) >>>>>> - NETGEAR: WAX220, WNDRMAC v2, EX6130 >>>>>> - Sophos: AP100, AP100c, AP55, AP55c >>>>>> - TP-Link: EAP615-Wall, TL-MR6400 (v5), Archer C60 (v1), EAP225- >>>>>> Outdoor v3, TL-WR2543N/ND (v1), RE200 (v4) >>>>>> - Ubiquiti: Unifi 6 Plus, UniFi Swiss Army Knife Ultra >>>>>> - Wavlink: WS-WN572HP3 4G >>>>>> - Xiaomi: Mi Router 4A (Gigabit Edition v2) >>>>>> - ZTE: MF289F >>>>>> - Zyxel: NWA50AX Pro, WSM20 >>>>>> >>>>>> Nicht mehr unterstützte Geräte: >>>>>> - TP-Link: RE355, RE450 (v1), RE305 >>>>>> - Ubiquiti: NanoBeam 5AC 19 (XC), NanoBeam M5 (XW), NanoStation >>>>>> Loco M2/M5 (XW), NanoStation M2/M5 (XW) >>>>>> >>>>>> Wir würden uns freuen, wenn einige von euch die Firmware testen >>>>>> könnten und eventuell auftretende Probleme zurückmeldeten. >>>>>> >>>>>> Herzliche Grüße >>>>>> Keno (für das Freifunk-Admin-Team) >>>>>> >>>>> >>>> >>> >>