Hello,
how is it possible to configure a preferred frequency when using DFS?
Let's say I have a channel-list containing 5500, 5540, 5580. I want to prefer 5580 as first choice because there are no other APs around, but I still want to include the other frequencies in case of DFS events. How can I achieve this?
The order of the entries in the channel-list doesn't matter, and defining a frequency instead of auto doesn't make any difference, either.
RouterOS nearly almost picks the lowest frequency 5500, which is suboptimal in my case because there are some other APs running on that frequency.
I can force frequency 5580 by deactivating all other frequencies in the channel-list, but than the AP goes completely off in case of a DFS event because it has no backup channels.
In my opinion there must be a way to configure a channel-list in order of preference when using DFS.

In the thread about v6.37rc, uldis said that the AP will start scanning at the defined frequency and only fall back to channel-list if there is a radar detected on the frequency (http://forum.mikrotik.com/viewtopic.php ... 25#p549765).

If in the 'frequency' field you had frequency that is in the radar frequency range then AP will start to look for radar in that specified frequency. If the radar is not detected then it will continue use that frequency. If a radar is detected, it will use the scan-list setting to look for a new frequency in the frequency list. If it selects a radar frequency range, it will start detecting the radar and if no radar is found it will start to work there.

But unfortunately this doesn't seem to be the case for me. It always starts at the lowest frequency within my channel-list.
Or is this kind of preferred frequency only a new feature of v6.37rc?

regards,
David

In my opinion there must be a way to configure a channel-list in order of preference when using DFS.

Be careful, DFS is mandated by regulations and personal opinions on how it should work are not relevant when the regulations tell otherwise...
I'm not sure that channel lists are even allowed when having (mandatory) DFS. TranZeo once told me they are not allowed, but Ubiquiti
still has them in their more restricted firmware version. We'll have to see what MikroTik will be going to.

I'm not sure that channel lists are even allowed when having (mandatory) DFS.

Interesting, I am not aware of this yet. And from a logical point of view, I wouldn't understand why excluding certain channels (which basically is the idea behind a scan-list) should be in conflict with DFS regulatories. The only downside would be that the AP went offline if there should be no "clean" channels left within my (limited) scan-list). From my experience scan-lists are a vital feature to exclude "bad channels" with interference, or enforce the use of outdoor channels.

I just upgraded one of my APs to v6.37rc12, and it now looks like the preferred frequency feature is actually working like described. If I set frequency=auto, it starts scanning with the lowest frequency again. If I set frequency=5580, it starts detecting radar on that frequency and then finally starts running service on that frequency (if no radar detected); with still having the other frequencys as fall-back in my scan-list. From a practical point of view that's a good improvement. So you can now have a preferred frequency, but the AP will jump to any random frequency (within scan-list) if radar is detected, because there is still no ordered channel-list. In my opinion an ordered scan-list would be better. Indeed entries within scan-list can be ordered with WinBox, but RouterOS doesn't care about it. Though the question remains, how to bring the AP back to the preferred frequency, if it once had to move away due to radar-detect? As a workaround a scheduled script during night which disables and re-enables the wireless interface could do that to trigger a re-scan starting on the preferred frequency.

Of course some more information from MikroTik would be nice. Just saying "we now enforce DFS=radar-detect" with v6.37 is a bit poor. I hope that some best practice guidelines or more detailed descriptions in the Wiki will follow. And last but not least it's hard to tell how exactly this all complies with regulatories.

In my opinion there must be a way to configure a channel-list in order of preference when using DFS.

Be careful, DFS is mandated by regulations and personal opinions on how it should work are not relevant when the regulations tell otherwise...
I'm not sure that channel lists are even allowed when having (mandatory) DFS. TranZeo once told me they are not allowed, but Ubiquiti
still has them in their more restricted firmware version. We'll have to see what MikroTik will be going to.

At least you need the possibility to block channels. Esp. the channels with 5 minutes channel check at the start or channels where you know they are unusable.
Most Vendors have problems implementing dfs as they are not good in handling the channel scan and recognition of radar patterns. To do a good job equipment
needs a second card to listen/scan channels in background. In case of a radar detection or a mandatory recheck of the channel you dont want to pause for 2 minutes (60s AP
scan and 60s CPE scan).

At least you need the possibility to block channels. Esp. the channels with 5 minutes channel check at the start or channels where you know they are unusable.
Most Vendors have problems implementing dfs as they are not good in handling the channel scan and recognition of radar patterns.

I agree with you but as I mentioned, I once requested TranZeo to have a feature to disable certain channels for selection by DFS as we
already know there would be radar detected there and it would skip again, causing more downtime than necessary, but the reply was
that this was not allowed by the regulatory bodies. I am not certain if this is the real truth, or that they only use it as a quick way to
wave away feature requests that cause work for them. However, I would not be surprised when the regulatory bodies try to make sure
that there is as little configurability as possible to avoid operators to work around the DFS.
(e.g. user knows there is radar on one freq, sometimes radar on another freq that is usually clear, then he puts those 2 freqs in the
allowed channel list and effectively defeats the DFS)

At least you need the possibility to block channels. Esp. the channels with 5 minutes channel check at the start or channels where you know they are unusable.
Most Vendors have problems implementing dfs as they are not good in handling the channel scan and recognition of radar patterns.

I agree with you but as I mentioned, I once requested TranZeo to have a feature to disable certain channels for selection by DFS as we
already know there would be radar detected there and it would skip again, causing more downtime than necessary, but the reply was
that this was not allowed by the regulatory bodies. I am not certain if this is the real truth, or that they only use it as a quick way to
wave away feature requests that cause work for them. However, I would not be surprised when the regulatory bodies try to make sure
that there is as little configurability as possible to avoid operators to work around the DFS.
(e.g. user knows there is radar on one freq, sometimes radar on another freq that is usually clear, then he puts those 2 freqs in the
allowed channel list and effectively defeats the DFS)

There are locations e.g. near Radar Stations where you have to block the channels used by them. The automatic detection may not recognize them due to antenna pattern. So I dont believe that a channel blocking mechanism offends regulations.