I’ve also had it in 5700 with a "20/40MHz XX” channel which should only go down to 5680. Here’s the logs including tonight where I was trying to get the link back at the correct place: May 28 07:12:26 w33-lnk-w1 wireless,info wlan1: radar detected on 5680000 May 28 19:30:48 w33-lnk-w1 wireless,info wlan1: radar detected on 5680000 May 28 19:36:25 w33-lnk-w1 wireless,info wlan1: radar detected on 5680000 May 28 19:36:48 w33-lnk-w1 wireless,info wlan1: radar detected on 5700000
On 28 May 2019, at 7:59 pm, Tim Warnock <timoid@timoid.org> wrote:
"Colour" radar runs between 5600 and 5650, so with a 20mhz channel and not specifying high for the other 20, theoretically you could be in that range.
Maybe try locking in high? Or move channels.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Tuesday, 28 May 2019 7:54 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi all,
I had one of my MikroTik radio links drop today and when I looked in the logs I saw this: May 28 07:12:26 w33-lnk-w1 wireless,info wlan1: radar detected on 5680000
This unit is running 6.43.16 which is the current long term. So it seems that MikroTik has gone and reinstated radar detect at some point recently. And for reference below is the config for the wireless interface, with the only change from this morning being that I’ve managed to get the link up again at the moment on 5660 Mhz. You can see I have country=australia set.
Is anyone else seeing radar detect back again? Maybe we can work out at what point it’s been put back in so that we can downgrade to below that point.
Mike, Is it possible to chase this up with them again and get them to turn off radar detect in Australia once and for all?
Cheers, Andrew
/interface wireless set [ find default-name=wlan1 ] \ adaptive-noise-immunity=ap-and-client-mode \ antenna-gain=27 \ band=5ghz-onlyac \ channel-width=20/40mhz-XX \ country=australia \ disabled=no \ frequency=5660 \ frequency-mode=regulatory-domain \ mode=ap-bridge \ mtu=1548 \ nv2-cell-radius=10 \ nv2-preshared-key=thisisnottherealpassword \ nv2-security=enabled radio-name=w33-lnk-w1 rx-chains=0,1 ssid=w33-lnk-w1 tx-chains=0,1 wireless-protocol=nv2 wmm-support=enabled wps-mode=disabled
On 19 Dec 2017, at 2:29 pm, Mike Everest <mike@duxtel.com> wrote:
I believe that DFS is intended to dynamically (and reliably) ensure equal distribution of frequency usage ;)
DFS cycle is executed on first time boot/power-up but it is technical also intended to occur on occasions of wireless re-train, such as climbing error count and/or re-try counts.
Whether or not it is a sensible or effective or efficient mechanism is open to debate ;)
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Jason Hecker (Up & Running Tech) Sent: Tuesday, 19 December 2017 2:31 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
I am wondering though, if the DFS mechanism is triggered by radar detection and we don't need radar detection then DFS is effectively ineffective so why do we need to even discuss DFS?
It would appear the lack of a requirement for radar detection makes DFS redundant down under. No?
On 19 December 2017 at 13:29, Mike Everest <mike@duxtel.com> wrote:
Hi Andrew!
Correct: 5150-5250 and 5725-5850 ranges do not require DFS - BUT DFS is optional if required. Correct: Radar detect is not required in Australia because we have an explicit reservation (5600-5650) for weather radar that is not selectable when AU regulatory domain is enabled. Correction: other 5GHz bands MUST have DFS enabled - it is NOT optional for any bands other than 5150-5250 (indoor only) and 5725-5850 :-}
Disclaimer: this is just my professional opinion on the matter - ACMA will tell you that you must make your own decision on the interpretation of the rules, and ensure that you are operating in what you consider a legally defensible manner - i.e. discuss with your lawyer experienced in Communications Law to be certain ;)
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Tuesday, 19 December 2017 12:52 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi Mike,
Just to be absolutely sure of the rules, would you mind clarifying "should be DFS only with no Radar detect for all except 5150-5250 and 5725-5850”.
I think I understand the following from this for Australia: * 5150-5250 and 5725-5850 are non-DFS and therefore fixed only. * The rest are DFS by default but can be fixed. * Radar detect isn’t used on any frequencies.
It could be good to add this it to your "Tuning outdoor wireless network performance” as well as that is already a fantastic summary page for Au power limits.
Thanks, Andrew
> On 16 Dec 2017, at 2:40 pm, Mike Everest <mike@duxtel.com> wrote: > > Hi Jason, all... > > It could mean one or both of two issues with AU regulatory domain: > > 1. DFS with radar detect enabled by default across all bands > (should be DFS only with no Radar detect for all except 5150-5250 > and > 5725-5850) 2. 900MHz band was not limited correctly to just 10 MHz > channel centred on > 922 > > I expect probably both of those since we raised them both a few > weeks ago now. > > Only testing will reveal the truth! :-} > > Cheers, Mike. > >> -----Original Message----- >> From: Public [mailto:public-bounces@talk.mikrotik.com.au] On >> Behalf Of Jason Hecker (Up & Running Tech) >> Sent: Saturday, 16 December 2017 6:56 AM >> To: MikroTik Australia Public List <public@talk.mikrotik.com.au> >> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4 >> >> Interesting in 6.41rc66 today... >> >> *) wireless - updated "UK 5.8 Fixed" and "Australia" regulatory >> domain information >> >> Mike, do you know what was updated? DFS rules? >> >> On 23 October 2017 at 12:05, Mike Everest <mike@duxtel.com> wrote: >> >>> Hi Harry, thanks for the comments! >>> >>> (have you tried subscribing to the public list? What happens >>> when you try to add a subscription?) >>> >>> That is only the LIPD class license document but it does not >>> list the relevant standards. The standards list some of the >>> ETSI specifications which according to MT include radar detect operation. >>> From MT perspective, they claim that DFS implies Radar Detect in >>> the relevant standards. I have no doubt that it DOES make that >>> link in the EU specification, but since our AU compliance >>> requirements also refer to some ETSI standard then it is >>> possible that our rules are also affected by the recent updates >>> to relevant ETSI standards simply by association and since ACMA >>> have not explicitly excluded that > revision... >>> >>> This is what I am attempting to ascertain ;) >>> >>> So far, I have not been able to find the direct relationships >>> and have been doing the rounds of some compliance folks to try >>> to get to the bottom of it all. It may take some time :-1 >>> >>> Cheers, Mike. >>> ------------------------------------------------------------ >>> ---------------- >>> -------- >>> Why Choose DuxTel for all your MikroTik needs? >>> 10 good reasons: http://duxtel.com/why_duxtel >>> ------------------------------------------------------------ >>> ---------------- >>> -------- >>> Follow our tweets for news and updates: >>> http://twitter.com/duxtel >>> >>>> -----Original Message----- >>>> From: Harry Fiotakis [mailto:Harry.Fiotakis@tasmanet.com.au] >>>> Sent: Monday, 23 October 2017 10:39 AM >>>> To: Mike Everest (mike@duxtel.com) <mike@duxtel.com> >>>> Cc: Philip Loenneker <Philip.Loenneker@tasmanet.com.au> >>>> Subject: RE: [MT-AU Public] Radar detection Chaos Since 6.40.4 >>>> >>>> Morning Mike, Phil forwarded me the latest correspondence as I >>>> still have >>> not >>>> been approved on the mailing list :( >>>> >>>> https://www.legislation.gov.au/Details/F2015L01438 >>>> (Radiocommunications (Low Interference Potential Devices) Class >>>> Licence 2015) >>>> >>>> 5250-5350 Must use DFS >>>> 5470-5600 Must use DFS >>>> 5650-5725 Must use DFS >>>> >>>> No Radar Detect required (it is not implied) >>>> >>>> We will have to seek official clarification on that if Mikrotik >>>> require >>> it, but >>>> with it forced on we are downgrading Mikrotik radios or simply >>>> not using them. >>>> >>>> >>>> Regards, >>>> >>>> Harry Fiotakis | TasmaNet >>>> 40-50 Innovation Drive, Tas 7010, Australia >>>> M: 0418 540 806 P: 1300 792 711 >>>> Email: harry.fiotakis@tasmanet.com.au >>>> >>>> >>>> -----Original Message----- >>>> From: Philip Loenneker >>>> Sent: Monday, October 23, 2017 10:30 AM >>>> To: Harry Fiotakis <Harry.Fiotakis@tasmanet.com.au> >>>> Subject: FW: [MT-AU Public] Radar detection Chaos Since 6.40.4 >>>> >>>> >>>> -----Original Message----- >>>> From: Public [mailto:public-bounces@talk.mikrotik.com.au] On >>>> Behalf Of Mike Everest >>>> Sent: Monday, 23 October 2017 9:50 AM >>>> To: 'MikroTik Australia Public List' >>>> <public@talk.mikrotik.com.au> >>>> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4 >>>> >>>> Further update on this issue, >>>> >>>> I've had a bit of correspondence with them, but they are 'fighting' > it. >>> Latest >>>> comment from them is that "ETSI standard mentions when you use >>>> DFS and those ranges you need to use the Radar-detect. Radar >>>> detect is happening only for 1 minute." >>>> >>>> The line they are taking is that since our LIPD class license >>> specification says >>>> that DFS must be enabled for the sub 5785 channels, then radar >>>> detect >>> must >>>> also be enabled. I've been trying to pore through all the >>>> relevant ACMA documentation so that I can find some definitive >>>> paragraph that clarifies >>> the >>>> situation, but so far have drawn a blank. >>>> >>>> I need someone who has some specific familiarity with the >>>> relevant rules >>> and >>>> standard that can find something that will convince them to >>>> turn it off - >>> any >>>> takers? :-} >>>> >>>> Cheers, Mike. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Public mailing list >>>> Public@talk.mikrotik.com.au >>>> http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrot >>>> ik.c >>>> o >>>> m.au >>> >>> >>> _______________________________________________ >>> Public mailing list >>> Public@talk.mikrotik.com.au >>> http://talk.mikrotik.com.au/mailman/listinfo/public_talk. mikrotik.com. >>> au >>> >> >> >> >> -- >> <https://www.upandrunningtech.com.au> >> _______________________________________________ >> Public mailing list >> Public@talk.mikrotik.com.au >> http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik >> .com >> .au > > > _______________________________________________ > Public mailing list > Public@talk.mikrotik.com.au > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
-- <https://www.upandrunningtech.com.au> _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au