<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hallo Jan,<br>
<br>
jetzt bekomme ich über GW1 die 10.24.243.156<br>
Und ich komme auch wieder darüber ins Web.<br>
<br>
<br>
Im Grafana sieht es so aus, als wäre da nicht besonders viel los
gewesen.<br>
Ziemliche Traffic-Flatline z.B. im Verhältnis zum GW4.<br>
<img src="cid:part1.tz1CeAg0.5md9D0S9@gmx.de" alt="" width="1211"
height="363"><br>
<br>
<img src="cid:part2.vCSmgARJ.UrqpiS6n@gmx.de" alt="" width="1206"
height="371"><br>
<br>
Grüße<br>
Sebastian<br>
<br>
<br>
<div class="moz-cite-prefix">Am 05.04.25 um 18:59 schrieb Jan
Scherer via freifunk-public:<br>
</div>
<blockquote type="cite"
cite="mid:439f3a6b-177a-4d4d-ba0e-f8d187b9361d@web.de">Konnte auf
Anhieb keinen Fehler bei GW1 feststellen, auch die Logs sehen
<br>
normal aus.
<br>
<br>
Starte es gerade mal neu, könnt ihr mal testen ob das Problem dann
immer
<br>
noch besteht? Bin gerade unterwegs und habe keinen Knoten zum
testen.
<br>
<br>
Grüße
<br>
<br>
Jan
<br>
<br>
Am 05.04.25 um 18:56 schrieb Sebastian Fontaine via
freifunk-public:
<br>
<blockquote type="cite">Hallo und vielen Dank für den Tipp,
<br>
<br>
habe das GW1 aus der /etc/config/tunneldigger rausgeschmissen
und jetzt
<br>
läuft freifunk wieder wie am Schnürchen.
<br>
Könnte man fast als update ausrollen, bis der wieder richtig
geht, oder?
<br>
<br>
Viele Grüße
<br>
Sebastian
<br>
<br>
<br>
<br>
Am 05.04.25 um 08:10 schrieb Peter Schley via freifunk-public:
<br>
<blockquote type="cite">Hallo zusammen,
<br>
<br>
ich konnte das Problem auf den gw1 eingrenzen.
<br>
Das Problem ist nachstellbar und tritt unabhängig von der
<br>
Firmwareversion auf. Sobald sich der Knoten mit dem GW1
verbindet,
<br>
werden keine IPv4-Adressen mehr verteilt.
<br>
<br>
Viele Grüße,
<br>
Peter
<br>
<br>
<br>
Am 03.04.2025 um 07:09 schrieb Peter Schley via
freifunk-public:
<br>
<blockquote type="cite">Hallo zusammen,
<br>
<br>
das IPv4-Problem tritt bei mir auch auf.
<br>
Situation hier:
<br>
- Offloader mit 2x vEthernet (ohne vlan-Experimente o.ä.)
<br>
- damals frisch mit 1.11.2 aufgesetzt, danach Updates (inkl.
<br>
Experimental und rc) auf 1.12.0
<br>
- nach dem Update auf 1.13.experimental (manuell per
sysupgrade)
<br>
erhalten die Clients keine IPv4-Adressen mehr. IPv6
funktioniert
<br>
augenscheinlich problemlos.
<br>
<br>
Ich prüfe das gerne noch mit frischem Setup auf Plastik.
Kann aber
<br>
noch nicht sagen, wann ich dafür Zeit finde.
<br>
<br>
Viele Grüße,
<br>
Peter
<br>
<br>
<br>
Am 01.04.2025 um 13:44 schrieb Ralf Jung via
freifunk-public:
<br>
<blockquote type="cite">Hallo allerseits,
<br>
<br>
während der Auto-updater wegen des IPv4-Problems aus ist,
kann die
<br>
Firmware hier manuell heruntergeladen werden:
<br>
<a class="moz-txt-link-rfc2396E" href="https://mgmt.saar.freifunk.net/firmware/1.13.0~exp20250325/"><https://mgmt.saar.freifunk.net/firmware/1.13.0~exp20250325/></a>
<br>
<br>
Uns ist aktuell völlig unklar, was das für ein Problem
ist, da es im
<br>
Hackerspace von selbst verschwunden ist. Also wenn das
jemand testen
<br>
könnte wäre das sehr nützlich. :)
<br>
<br>
Viele Grüße,
<br>
Ralf
<br>
<br>
On 01.04.25 13:15, Hassler, Keno via freifunk-public
wrote:
<br>
<blockquote type="cite">Hallo liebe Freifunker,
<br>
<br>
es gibt eine neue Experimental-Firmware
(1.13.0~exp20250325) auf
<br>
Basis von gluon 2023.2.4. Damit schließen wir wieder zum
aktuellen
<br>
Stand der gluon-Entwicklung auf. Zur Zeit ist der
Rollout noch
<br>
pausiert, da wir ein Problem mit DHCP vermutet haben
(Clients
<br>
bekamen keine IPv4- Adressen). Sobald wir bestätigt
haben, dass das
<br>
Problem gelöst ist, wird das Update im
Experimental-Kanal
<br>
auftauchen. Upgrade sind nur von Version 1.12 möglich;
falls eure
<br>
Knoten noch auf Version 1.11.2 laufen, müsstet ihr sie
also zuerst
<br>
auf 1.12 upgraden.
<br>
<br>
Zentrale Neuerungen sind zum einen eine modernere Basis
mit OpenWrt
<br>
23.05, Linux-Kernel 5.15, wireless-backports 6.1.24 und
batman-adv
<br>
2023.1, und zum anderen WPA3-Support für private
WLAN-Netze. Wenn
<br>
ihr eure Knoten dazu nutzt, euer privates
(verschlüsseltes) WLAN zu
<br>
erweitern, könnt ihr das jetzt auf zeitgemäßem
Sicherheitsstand
<br>
tun. Dieses Feature steht aus Platzgründen aber nur auf
Routern zur
<br>
Verfügung, die genügend Speicher haben (mindestens 7MiB
Flash und
<br>
64MiB RAM).
<br>
<br>
Neu unterstützte Geräte:
<br>
- ARM SystemReady 32/64-bit (Images für virtuelle
Maschinen auf
<br>
ARM- Systemen)
<br>
- ASUS: TUF-AX4200, RT-AX53U
<br>
- AVM: FRITZ!Repeater 1750E
<br>
- Cudy: WR3000 (v1)
<br>
- D-Link: COVR-X1860 (A1)
<br>
- Enterasys: WS-AP3715i
<br>
- Extreme Networks: WS-AP3805i
<br>
- GL.iNet: GL-XE300, GL-MT3000
<br>
- Hewlett-Packard: MSM460
<br>
- MikroTik: wAPR-2nD (wAP R)
<br>
- NETGEAR: WAX220, WNDRMAC v2, EX6130
<br>
- Sophos: AP100, AP100c, AP55, AP55c
<br>
- TP-Link: EAP615-Wall, TL-MR6400 (v5), Archer C60 (v1),
EAP225-
<br>
Outdoor v3, TL-WR2543N/ND (v1), RE200 (v4)
<br>
- Ubiquiti: Unifi 6 Plus, UniFi Swiss Army Knife Ultra
<br>
- Wavlink: WS-WN572HP3 4G
<br>
- Xiaomi: Mi Router 4A (Gigabit Edition v2)
<br>
- ZTE: MF289F
<br>
- Zyxel: NWA50AX Pro, WSM20
<br>
<br>
Nicht mehr unterstützte Geräte:
<br>
- TP-Link: RE355, RE450 (v1), RE305
<br>
- Ubiquiti: NanoBeam 5AC 19 (XC), NanoBeam M5 (XW),
NanoStation
<br>
Loco M2/M5 (XW), NanoStation M2/M5 (XW)
<br>
<br>
Wir würden uns freuen, wenn einige von euch die Firmware
testen
<br>
könnten und eventuell auftretende Probleme
zurückmeldeten.
<br>
<br>
Herzliche Grüße
<br>
Keno (für das Freifunk-Admin-Team)
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>