Dann gehe ich davon aus, dass keine Tests diesbezüglich gemacht wurden und dieser Thread daher mitnichten „beendet“ erklärt werden sollte.
Tritt/trat das mit 5ghz broken bei jedem dfs Event auf? reicht es also ein dfs event abzuwarten und zu schauen, ob dfs dann noch läuft? (oder eher mehrere?)
Soll man einmal mit einmal ohne eulenfunk check testen oder den einfach drin lassen (tut’s weh wenn der drin ist?)
Wir (4830) nutzen den einen oder anderen SSID-Changer seit Jahren, ohne /lib/gluon/eulenfunk-hotfix/check_hostapd.sh, und hier sind keine solchen Fehler bekannt?
Ich wüsste jetzt nicht, wo ich spontan eure site.conf nachschauen kann, ob ihr 5GHz auf DFS-Kanälen macht.
Trat bei uns halt nur dort auf, wenn wifi-restart gemacht wurde (wegen SSID-Wechsel) während gerade DFS-wait lief. Dann blieb ein hostapd als (faktischer) Zombie übrig und der nächste hostapd mochte irgendwie nimmer richtig.
Kann aber auch sein, dass in Gluon21+ inzwischen ein besserer Mechanismus für den SSID-Wechsel ist als den kompletten Wifistack neu durchzustarten.
Bislang nicht; wollten wir, aber da seit OpenWrt 19.07 meshing auf DFS-Kanälen karpott ist, ist das absehbar eher müßig.
Danke.
also euer Default 5GHz Kanal liegt auf Kanal 52+?
oder nur für im Falle, dass ihr die Geräte Outdoor verwendet (outdoor mode)?
Ach, ist dfs-wait auf non-dfs-Kanälen gefixed, sofern das ein Bug war?
Um auf die Frage zu antworten: Nein.
interessant, ich werd mir das bei Zeiten mal ansehen (wann dfs events in Gluon gezündet werden)
Kann aber dauern 