[freifunk-public] GW1 hat Huddel / Re: Neue Experimental-Firmware 1.13.0~exp20250325

[Jan Scherer]

Hallo zusammen,

wir haben gerade versucht das IPv4 Problem nachzustellen, wir konnten
das aktuell nicht reproduzieren. Vielleicht war temporär was an GW1
kaputt, was durch den Neustart behoben wurde.

Zu der Auswahl des Gateways hat Ralf ja schon geantwortet.

Grüße

Jan

Am 05.04.25 um 19:59 schrieb Peter Schley:
> Hi,
>
> ich kann das Problem nicht mehr nachstellen; d.h. es werden
> IPv4-Adressen verteilt. Mir kommt es jedoch so vor, als dauere der
> DHCP-Handshake länger.
> Info am Rande: Das neue Gluon benutzt scheinbar immer den ersten
> Server aus der Tunneldigger-Konfiguration. Das war früher(TM) glaube
> ich anders.
>
> Grüße und ein schönes Restwochenende
> 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:
>>>>>> <https://mgmt.saar.freifunk.net/firmware/1.13.0~exp20250325/>
>>>>>>
>>>>>> 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)
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>