jch:

No, this is not a duplicate. FS#506 is about DFS being disabled on the reporter's hardware. On my hardware, the DFS working fine, but it's never switching back to the original channel after seeing (what it interprets as) a radar pulse.

DFS support for macVersion = 0x80, macRev = 0x2: enabled
Pulse detector statistics:
pulse events reported : 24919
invalid pulse events : 0
DFS pulses detected : 22071
Datalen discards : 0
RSSI discards : 2686
BW info discards : 162
Primary channel pulses : 23368
Secondary channel pulses : 705
Dual channel pulses : 684
Radar detector statistics (current DFS region: 2)
Pulse events processed : 22658
Radars detected : 1
Global Pool statistics:
Pool references : 14
Pulses allocated : 238
Pulses alloc error : 0
Pulses in use : 9
Seqs. allocated : 330
Seqs. alloc error : 0
Seqs. in use : 0

dlang:

that sounds like "works as designed", it detected that there is radar operating on that channel, so it won't let you use it.

The fact that the radar detection may be faulty is a different topic.

sumpfralle:

In this specific case (indoor channel 60 -> indoor channel 36) the (permanent) change is acceptable from the point of regulation and law.

Sadly this switch also happens when trying to use an outdoor channel. In this case it is not allowed to use indoor channels, but nevertheless the outdoor->indoor switch can happen due to DFS. But this is a problem common for all DFS implementation (also proprietary ones).

This topic is probably too broad for being handled within LEDE. Upstream (hostapd?) is probably the proper communication partner.

jch:

For what it's worth, I've now switched to a different channel (108), and this one sticks. (I'm still slightly puzzled by LEDE's behaviour, but the problem is solved for me.