# Outdoor Mode in gluon2020.1.x "DFS-PRE-CAC-EXPIRED"

**URL:** <https://forum.freifunk.net/t/outdoor-mode-in-gluon2020-1-x-dfs-pre-cac-expired/22128>\
**Category:** Gluon\
**Created:** [3. Juli 2020 um 20:39 UTC](https://forum.freifunk.net/t/outdoor-mode-in-gluon2020-1-x-dfs-pre-cac-expired/22128 "2020-07-03T20:39:19Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\
**Post date:** [16. Juli 2020 um 22:52 UTC](https://forum.freifunk.net/t/outdoor-mode-in-gluon2020-1-x-dfs-pre-cac-expired/22128/19 "2020-07-16T22:52:43Z")

</div>

ein paar Tage später… mit Trial and Error und ein paar Workaround-script-Iterationen weiter, etwas mehr Klarheit:

1. der Hostapd im 2020.1.x-Gluon mag es nicht, ein SigHUP zu bekommen während er gerade DFS-Scanning macht (evtl. mag er es auch zu anderen Zeiten nicht). Ergebnis ist dann ein irgendwie undefinierter Zustand, der sich entweder äußert in
  - PID im pidfile passt nicht zur PID in der Tasklist
  - es gibt eine Meldung „DFS-PRE-CAC-EXPIRED“ und nie wieder eine weitere Meldung vom Hostapd
  - das Radio-Interface ist gemäß „wifi status“ „down“ und status „pending“, trotz vorherigem „wifi up“

Workaround?

Fork vom Offline-SSID-Script, aufruf eines check-Workaround-scripts nach dem „killall -HUP hostapd“, Zeile 174ff

> <https://github.com/eulenfunk/packages/blob/63de2320506b7b806b478e295c24eb39c4ab3273/gluon-ssid-changer/shsrc/ssid-changer.sh>

und dann das Checkscript, was  
a) mismatching PIDs (main issue) mit einem Wifi-Restart rettet  
und  
b) longer pending interfaces (script läuft auch in der Cron alle paar Minunten) erkennt und auch dann das wifi restartet.

> <https://github.com/eulenfunk/packages/blob/v2020.1.x/eulenfunk-hotfix/files/lib/gluon/eulenfunk-hotfix/check_hostapd.sh>

Falls jemand bessere Vorschläge hat (außer „Muss upstream gefixed werden, also upstream, vom upstream vom upstream“, also entweder in openwert, im Hostapd oder im Linuxkernel)

Was ich mir vorstellen könnte:

- nur das betroffene Phy neu starten
- den Lock-Zustand anders/besser erkennen
- das gerade laufende DFS-Scanning erkennen oder dem Hostapd dafür ein Locking zu verpassen (was in beide Richtungen „wirkt“). Und nein, nicht per „[swatch](https://www.tecmint.com/swatch-linux-log-file-watcher/)“ (tried, not 100% success) auf dem syslog lauschen. direkt auf dem ubus?
- den hostapd irgendwie sinnvoll patchen, dass er den Fehlerzustand selbst erkennt und restartet.

---

_[View the full topic](https://forum.freifunk.net/t/outdoor-mode-in-gluon2020-1-x-dfs-pre-cac-expired/22128)._