Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
-----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
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 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.mikrotik.com.au
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.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
I hope so MikroTik wifi is unusable in the sydney cbd we are moving to another platform. Massive shame for an otherwise good product Matt -- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Fax 1300 133 255 Level 6, 350 George Street Sydney 2000 SIP 1300137379@sip.spectrum.com.au Google Talk MattAPerkins@gmail.com PGP/GNUPG Public Key can be found at http://pgp.mit.edu */
On 16 Dec 2017, at 6:55 am, Jason Hecker (Up & Running Tech) <jason@upandrunningtech.com.au> wrote:
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.mikrotik.com.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
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.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
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.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
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.mikrotik.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.com.au
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.mikrotik.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.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
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
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
"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
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
Depends what the 'XX' means ;) If you have 20/40 Ce on 5700, then 5700 is centred on the low channel with extension above, so 5690-5730, but if you mean eC, then the centre is the high channel, so 5670 to 5710 - still outside the blocked out 5600-5650 band, but it does include the 5680 where you were detecting radar. Cheers,..
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Tuesday, 28 May 2019 8:07 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
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.mikr >>>>> ot >>>>> 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.mikrot >>> ik >>> .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.c om.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
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
Hi Mike, From the Mikrotik wiki: Channel widths with XX and XXXX extensions automatically scan for a less crowded control channel frequency based on the number of concurrent devices running in every frequency and chooses the “C” - Control channel frequency automatically. The frequency you select is in the centre of the range. So whether the control channel ends up above or below this point won’t matter too much, but with 20/40MHz XX selected you will end up using 20MHz below and above the frequency selected and therefore in this case stay above 5660. Cheers, Andrew
On 28 May 2019, at 9:50 pm, Mike Everest <mike@duxtel.com> wrote:
Depends what the 'XX' means ;)
If you have 20/40 Ce on 5700, then 5700 is centred on the low channel with extension above, so 5690-5730, but if you mean eC, then the centre is the high channel, so 5670 to 5710 - still outside the blocked out 5600-5650 band, but it does include the 5680 where you were detecting radar.
Cheers,..
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Tuesday, 28 May 2019 8:07 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
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.mikr >>>>>> ot >>>>>> 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.mikrot >>>> ik >>>> .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.c om.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
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
I stand corrected! :-D When did they add 'XXXX' for channel selection! They slipped that one past me ;-) Thanks for the lesson! :-) Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Friday, 31 May 2019 11:05 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi Mike,
From the Mikrotik wiki:
Channel widths with XX and XXXX extensions automatically scan for a less crowded control channel frequency based on the number of concurrent devices running in every frequency and chooses the “C” - Control channel frequency automatically.
The frequency you select is in the centre of the range. So whether the control channel ends up above or below this point won’t matter too much, but with 20/40MHz XX selected you will end up using 20MHz below and above the frequency selected and therefore in this case stay above 5660.
Cheers, Andrew
On 28 May 2019, at 9:50 pm, Mike Everest <mike@duxtel.com> wrote:
Depends what the 'XX' means ;)
If you have 20/40 Ce on 5700, then 5700 is centred on the low channel with extension above, so 5690-5730, but if you mean eC, then the centre is the high channel, so 5670 to 5710 - still outside the blocked out 5600-5650 band, but it does include the 5680 where you were detecting radar.
Cheers,..
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Tuesday, 28 May 2019 8:07 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
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.mi >>>>>>> kr >>>>>>> ot >>>>>>> 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.mikr >>>>> ot >>>>> ik >>>>> .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.mikrot >>> ik >>> .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 > .c > om.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.c om .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
I can’t remember. It wasn’t long ago, sometime this year I think it made it in to long-term. Their wiki page was shockingly worded in the past too and made it sound like it just created on big 40MHz channel. It wasn’t until the other day when I read the updated description that it made sense and then sounds like it’s actually really good. Andrew
On 31 May 2019, at 11:57 am, Mike Everest <mike@duxtel.com> wrote:
I stand corrected! :-D
When did they add 'XXXX' for channel selection! They slipped that one past me ;-)
Thanks for the lesson! :-)
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Friday, 31 May 2019 11:05 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi Mike,
From the Mikrotik wiki:
Channel widths with XX and XXXX extensions automatically scan for a less crowded control channel frequency based on the number of concurrent devices running in every frequency and chooses the “C” - Control channel frequency automatically.
The frequency you select is in the centre of the range. So whether the control channel ends up above or below this point won’t matter too much, but with 20/40MHz XX selected you will end up using 20MHz below and above the frequency selected and therefore in this case stay above 5660.
Cheers, Andrew
On 28 May 2019, at 9:50 pm, Mike Everest <mike@duxtel.com> wrote:
Depends what the 'XX' means ;)
If you have 20/40 Ce on 5700, then 5700 is centred on the low channel with extension above, so 5690-5730, but if you mean eC, then the centre is the high channel, so 5670 to 5710 - still outside the blocked out 5600-5650 band, but it does include the 5680 where you were detecting radar.
Cheers,..
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Tuesday, 28 May 2019 8:07 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
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.mi >>>>>>>> kr >>>>>>>> ot >>>>>>>> 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.mikr >>>>>> ot >>>>>> ik >>>>>> .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.mikrot >>>> ik >>>> .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 >> .c >> om.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.c om .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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Dont forget the Amateur 6cm band runs from 5650 to 5850 im sure to a mikrotik an FM carrier would look a hell of a lot like a radar who knows what it would think of a CW ident @ 400w I think there might even be some sat downlinks on 5825 - 5850 The implementation or radar detect has been a disaster for a few of our customers might you we did not trace it back to Amateur use it remains unknown and I spent a lot of time looking. It's been a bit of a mess i must say. Matt (VK2FLY) On 28/5/19 8:07 pm, Andrew Radke wrote:
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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */
That’s interesting. That would mean then that running in the 5470-5600 band would be much safer than running in 5650-5725 for this faulty radar detect stuff.
On 31 May 2019, at 4:21 pm, Matt Perkins <matt@spectrum.com.au> wrote:
Dont forget the Amateur 6cm band runs from 5650 to 5850 im sure to a mikrotik an FM carrier would look a hell of a lot like a radar who knows what it would think of a CW ident @ 400w I think there might even be some sat downlinks on 5825 - 5850 The implementation or radar detect has been a disaster for a few of our customers might you we did not trace it back to Amateur use it remains unknown and I spent a lot of time looking.
It's been a bit of a mess i must say.
Matt (VK2FLY)
On 28/5/19 8:07 pm, Andrew Radke wrote:
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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Yes I would say so. Here's the recommended band plan for 6cm It's a secondary service so in theory you are not suppose to cause interference however there's pretty much no way to tell you are interfering with a wifi station 1km away you cant even hear. Matt On 31/5/19 4:42 pm, Andrew Radke wrote:
That’s interesting. That would mean then that running in the 5470-5600 band would be much safer than running in 5650-5725 for this faulty radar detect stuff.
On 31 May 2019, at 4:21 pm, Matt Perkins <matt@spectrum.com.au> wrote:
Dont forget the Amateur 6cm band runs from 5650 to 5850 im sure to a mikrotik an FM carrier would look a hell of a lot like a radar who knows what it would think of a CW ident @ 400w I think there might even be some sat downlinks on 5825 - 5850 The implementation or radar detect has been a disaster for a few of our customers might you we did not trace it back to Amateur use it remains unknown and I spent a lot of time looking.
It's been a bit of a mess i must say.
Matt (VK2FLY)
On 28/5/19 8:07 pm, Andrew Radke wrote:
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
Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */
_______________________________________________ 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
-- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */
Hmm inline images dont work here's an attachment. On 31/5/19 4:52 pm, Matt Perkins wrote:
Yes I would say so. Here's the recommended band plan for 6cm It's a secondary service so in theory you are not suppose to cause interference however there's pretty much no way to tell you are interfering with a wifi station 1km away you cant even hear.
Matt
On 31/5/19 4:42 pm, Andrew Radke wrote:
That’s interesting. That would mean then that running in the 5470-5600 band would be much safer than running in 5650-5725 for this faulty radar detect stuff.
On 31 May 2019, at 4:21 pm, Matt Perkins <matt@spectrum.com.au> wrote:
Dont forget the Amateur 6cm band runs from 5650 to 5850 im sure to a mikrotik an FM carrier would look a hell of a lot like a radar who knows what it would think of a CW ident @ 400w I think there might even be some sat downlinks on 5825 - 5850 The implementation or radar detect has been a disaster for a few of our customers might you we did not trace it back to Amateur use it remains unknown and I spent a lot of time looking.
It's been a bit of a mess i must say.
Matt (VK2FLY)
On 28/5/19 8:07 pm, Andrew Radke wrote:
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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */
_______________________________________________ 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
-- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */
Haa. Third times the charm. Happy Friday everyone. https://www.dropbox.com/s/msslv77l0oisvhs/Screen%20Shot%202019-05-31%20at%20... On 31/5/19 4:57 pm, Matt Perkins wrote:
Hmm inline images dont work here's an attachment.
On 31/5/19 4:52 pm, Matt Perkins wrote:
Yes I would say so. Here's the recommended band plan for 6cm It's a secondary service so in theory you are not suppose to cause interference however there's pretty much no way to tell you are interfering with a wifi station 1km away you cant even hear.
Matt
On 31/5/19 4:42 pm, Andrew Radke wrote:
That’s interesting. That would mean then that running in the 5470-5600 band would be much safer than running in 5650-5725 for this faulty radar detect stuff.
On 31 May 2019, at 4:21 pm, Matt Perkins <matt@spectrum.com.au> wrote:
Dont forget the Amateur 6cm band runs from 5650 to 5850 im sure to a mikrotik an FM carrier would look a hell of a lot like a radar who knows what it would think of a CW ident @ 400w I think there might even be some sat downlinks on 5825 - 5850 The implementation or radar detect has been a disaster for a few of our customers might you we did not trace it back to Amateur use it remains unknown and I spent a lot of time looking.
It's been a bit of a mess i must say.
Matt (VK2FLY)
On 28/5/19 8:07 pm, Andrew Radke wrote:
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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */
_______________________________________________ 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
-- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */
Hi Andrew, 0% chance that they will turn it off. EU regulations have made it /very/ (errr) 'compelling' to force all manufacturers to hard code radar detect - i.e. they have a right to ban sales of all product by that manufacturer throughout the entire EU and even sieze product passing across any borders. It makes no difference that we don’t require it here - if it is possible for any one country to disable then it is technically possible for anyone to do so (even if it means import product from outside EU) So,... nope - not gonna happen :-( Regarding why you are detecting radar, it could be some third party radar activity, like HAM operator or backyard experimenter, or it could be nearby military operations - there are some around your way I think? Not much you can do about it other than try to work with it. Strictly speaking, across most of that band you *should* be operating with DFS anyhow, so having sporadic radar around there should be managed by the DFS. Does cause hell with customer services when backhauls are going up and down all the time, but if you try to build some redundancy into your backhaul (multiple paths etc) then it is possible to get some relatively decent stability into a 5GHz backhaul network in general. Cheers, Mike.
-----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.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.com.au
If you run without any regulatory domain it will let you do uh, questionable, things.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 28 May 2019 9:36 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi Andrew,
0% chance that they will turn it off. EU regulations have made it /very/ (errr) 'compelling' to force all manufacturers to hard code radar detect - i.e. they have a right to ban sales of all product by that manufacturer throughout the entire EU and even sieze product passing across any borders.
It makes no difference that we don’t require it here - if it is possible for any one country to disable then it is technically possible for anyone to do so (even if it means import product from outside EU) So,... nope - not gonna happen :-(
Regarding why you are detecting radar, it could be some third party radar activity, like HAM operator or backyard experimenter, or it could be nearby military operations - there are some around your way I think? Not much you can do about it other than try to work with it.
Strictly speaking, across most of that band you *should* be operating with DFS anyhow, so having sporadic radar around there should be managed by the DFS. Does cause hell with customer services when backhauls are going up and down all the time, but if you try to build some redundancy into your backhaul (multiple paths etc) then it is possible to get some relatively decent stability into a 5GHz backhaul network in general.
Cheers, Mike.
-----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.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.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Yes, but you can't turn off radar detect blow 5725 ;)
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Tim Warnock Sent: Tuesday, 28 May 2019 9:45 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
If you run without any regulatory domain it will let you do uh, questionable, things.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Tuesday, 28 May 2019 9:36 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi Andrew,
0% chance that they will turn it off. EU regulations have made it /very/ (errr) 'compelling' to force all manufacturers to hard code radar detect - i.e. they have a right to ban sales of all product by that manufacturer throughout the entire EU and even sieze product passing across any borders.
It makes no difference that we don’t require it here - if it is possible for any one country to disable then it is technically possible for anyone to do so (even if it means import product from outside EU) So,... nope - not gonna happen :-(
Regarding why you are detecting radar, it could be some third party radar activity, like HAM operator or backyard experimenter, or it could be nearby military operations - there are some around your way I think? Not much you can do about it other than try to work with it.
Strictly speaking, across most of that band you *should* be operating with DFS anyhow, so having sporadic radar around there should be managed by the DFS. Does cause hell with customer services when backhauls are going up and down all the time, but if you try to build some redundancy into your backhaul (multiple paths etc) then it is possible to get some relatively decent stability into a 5GHz backhaul network in general.
Cheers, Mike.
-----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.mi >>>>> krot >>>>> 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.mikr >>> otik >>> .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.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
Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hi Mike, There aren’t any military sites anywhere near where (other than the tiny reservists locations) we are but this link would have a town about 15km away that the AP end is pretty close to being in line to so maybe something from there. I realised afterwards that if I switched then roles of the two ends then there is nothing the AP could see other than hills and the sky. But then if the link goes down I have no access to it to change the frequency as I’m seeing it from the wrong end. And this tower has no way of getting a link from anywhere else so I’d have to add another radio link to it in a different spectrum range. This leads me to the next problem. Mikrotik only goes to 5835 MHz. So you can’t fit 3 40MHz channels in the top spectrum range starting at 5725. Others like Mimosa go to 5850. This means that with Mikrotik you can’t have a 5GHz backhaul plus two AP frequencies (with horns so they can be alternated around a tower). For now I’ll have to cope with this radar detect and hope that whatever caused it doesn’t pop up often (it’s the first time in the four months it’s been active) and look at replacing the link with a non-Mikrotik device that can use the higher end of the spectrum. As a side note to this, the ACMA LIPD class licence page (https://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class-licence... <https://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class-licences/lipd-class-licence-spectrum-acma>) lists the 5.8GHz ISM band as 5725-5875 MHz. That would leave room for 3 x 40MHz with another 20Mhz channel above them. I’d love to know if there are any options from other vendors that give access to the full spectrum (or Mike you might point out a restriction I’ve missed, like that it falls under a Fixed Licence rather than a Class Licence). Cheers, Andrew
On 28 May 2019, at 9:35 pm, Mike Everest <mike@duxtel.com> wrote:
Hi Andrew,
0% chance that they will turn it off. EU regulations have made it /very/ (errr) 'compelling' to force all manufacturers to hard code radar detect - i.e. they have a right to ban sales of all product by that manufacturer throughout the entire EU and even sieze product passing across any borders.
It makes no difference that we don’t require it here - if it is possible for any one country to disable then it is technically possible for anyone to do so (even if it means import product from outside EU) So,... nope - not gonna happen :-(
Regarding why you are detecting radar, it could be some third party radar activity, like HAM operator or backyard experimenter, or it could be nearby military operations - there are some around your way I think? Not much you can do about it other than try to work with it.
Strictly speaking, across most of that band you *should* be operating with DFS anyhow, so having sporadic radar around there should be managed by the DFS. Does cause hell with customer services when backhauls are going up and down all the time, but if you try to build some redundancy into your backhaul (multiple paths etc) then it is possible to get some relatively decent stability into a 5GHz backhaul network in general.
Cheers, Mike.
-----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.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.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hi Andrew, The correct (and current) 5.8 band is item 60 of the schedule in the LIPD specification: https://www.legislation.gov.au/Details/F2018C00500 The band is 5725 to 5850. Above 5850 is generally referred to as '6GHz band' which is available as licensed band in many countries - thus some equipment supports selection of those bands. You should NOT use them in AU without appropriate apparatus license, else you *will* be prosecuted if you cause problems for a valid licensee ;) Incidentally, since you mention that town 15Km away, there used to be a '5GHz License' available for low cost (I think it was about $50/year) that allows you to go up to something like 250W EIRP on p2p links. Not sure if it is still available as it has been a while since I looked it up - it was available for links where both ends were beyond 10Km from a population centre of up to 15000 (or was it 15Km from pop of up to 10000 - I can never remember that detail ;) Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Friday, 31 May 2019 11:37 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi Mike,
There aren’t any military sites anywhere near where (other than the tiny reservists locations) we are but this link would have a town about 15km away that the AP end is pretty close to being in line to so maybe something from there.
I realised afterwards that if I switched then roles of the two ends then there is nothing the AP could see other than hills and the sky. But then if the link goes down I have no access to it to change the frequency as I’m seeing it from the wrong end. And this tower has no way of getting a link from anywhere else so I’d have to add another radio link to it in a different spectrum range.
This leads me to the next problem. Mikrotik only goes to 5835 MHz. So you can’t fit 3 40MHz channels in the top spectrum range starting at 5725. Others like Mimosa go to 5850. This means that with Mikrotik you can’t have a 5GHz backhaul plus two AP frequencies (with horns so they can be alternated around a tower). For now I’ll have to cope with this radar detect and hope that whatever caused it doesn’t pop up often (it’s the first time in the four months it’s been active) and look at replacing the link with a non-Mikrotik device that can use the higher end of the spectrum.
As a side note to this, the ACMA LIPD class licence page (https://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class- licences/lipd-class-licence-spectrum-acma <https://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class- licences/lipd-class-licence-spectrum-acma>) lists the 5.8GHz ISM band as 5725-5875 MHz. That would leave room for 3 x 40MHz with another 20Mhz channel above them. I’d love to know if there are any options from other vendors that give access to the full spectrum (or Mike you might point out a restriction I’ve missed, like that it falls under a Fixed Licence rather than a Class Licence).
Cheers, Andrew
On 28 May 2019, at 9:35 pm, Mike Everest <mike@duxtel.com> wrote:
Hi Andrew,
0% chance that they will turn it off. EU regulations have made it /very/ (errr) 'compelling' to force all manufacturers to hard code radar detect - i.e. they have a right to ban sales of all product by that manufacturer throughout the entire EU and even sieze product passing across any borders.
It makes no difference that we don’t require it here - if it is possible for any one country to disable then it is technically possible for anyone to do so (even if it means import product from outside EU) So,... nope - not gonna happen :-(
Regarding why you are detecting radar, it could be some third party radar activity, like HAM operator or backyard experimenter, or it could be nearby military operations - there are some around your way I think? Not much you can do about it other than try to work with it.
Strictly speaking, across most of that band you *should* be operating with DFS anyhow, so having sporadic radar around there should be managed by the DFS. Does cause hell with customer services when backhauls are going up and down all the time, but if you try to build some redundancy into your backhaul (multiple paths etc) then it is possible to get some relatively decent stability into a 5GHz backhaul network in general.
Cheers, Mike.
-----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.mikr >>>>> ot >>>>> 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.mikrot >>> ik >>> .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 > .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.c om .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
Hi Mike, I did see reference to this one. It’s the "Radiofrequency spectrum fixed licences Point to point (5.8 GHz band)” at https://www.acma.gov.au/theACMA/radiofrequency-spectrum-fixed-licences#7 <https://www.acma.gov.au/theACMA/radiofrequency-spectrum-fixed-licences#7> I was wondering about it when I saw it the other day. The important points: The point to point (5.8 GHz band) licensing option is typically used to authorise fixed links with up to 200 Watts EIRP in regional and remote areas. apparatus licences may only be issued on two 20 MHz bandwidth channels centred on 5.745 and 5.785 GHz. only be licensed at locations that are outside defined capital city high and medium density areas and that are also 20 km or more from the centre of any regional city of more than 20 000 people. a special condition applies to licences that will restrict the 3 dB antenna beamwidth of transmitters to +/- 5.5° in the horizontal plane. These restrictions are intended to prevent de facto high power (that is, up to 200 Watts EIRP) point to multipoint services. no more than three point to point stations (typically hub stations) per licensee will be permitted at a site. I think this could be perfect for the backhaul links and something I’ll have to investigate. Thanks for the pointer. :-) Andrew
On 31 May 2019, at 1:24 pm, Mike Everest <mike@duxtel.com> wrote:
Hi Andrew,
The correct (and current) 5.8 band is item 60 of the schedule in the LIPD specification: https://www.legislation.gov.au/Details/F2018C00500
The band is 5725 to 5850. Above 5850 is generally referred to as '6GHz band' which is available as licensed band in many countries - thus some equipment supports selection of those bands. You should NOT use them in AU without appropriate apparatus license, else you *will* be prosecuted if you cause problems for a valid licensee ;)
Incidentally, since you mention that town 15Km away, there used to be a '5GHz License' available for low cost (I think it was about $50/year) that allows you to go up to something like 250W EIRP on p2p links. Not sure if it is still available as it has been a while since I looked it up - it was available for links where both ends were beyond 10Km from a population centre of up to 15000 (or was it 15Km from pop of up to 10000 - I can never remember that detail ;)
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Friday, 31 May 2019 11:37 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi Mike,
There aren’t any military sites anywhere near where (other than the tiny reservists locations) we are but this link would have a town about 15km away that the AP end is pretty close to being in line to so maybe something from there.
I realised afterwards that if I switched then roles of the two ends then there is nothing the AP could see other than hills and the sky. But then if the link goes down I have no access to it to change the frequency as I’m seeing it from the wrong end. And this tower has no way of getting a link from anywhere else so I’d have to add another radio link to it in a different spectrum range.
This leads me to the next problem. Mikrotik only goes to 5835 MHz. So you can’t fit 3 40MHz channels in the top spectrum range starting at 5725. Others like Mimosa go to 5850. This means that with Mikrotik you can’t have a 5GHz backhaul plus two AP frequencies (with horns so they can be alternated around a tower). For now I’ll have to cope with this radar detect and hope that whatever caused it doesn’t pop up often (it’s the first time in the four months it’s been active) and look at replacing the link with a non-Mikrotik device that can use the higher end of the spectrum.
As a side note to this, the ACMA LIPD class licence page (https://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class- licences/lipd-class-licence-spectrum-acma <https://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class- licences/lipd-class-licence-spectrum-acma>) lists the 5.8GHz ISM band as 5725-5875 MHz. That would leave room for 3 x 40MHz with another 20Mhz channel above them. I’d love to know if there are any options from other vendors that give access to the full spectrum (or Mike you might point out a restriction I’ve missed, like that it falls under a Fixed Licence rather than a Class Licence).
Cheers, Andrew
On 28 May 2019, at 9:35 pm, Mike Everest <mike@duxtel.com> wrote:
Hi Andrew,
0% chance that they will turn it off. EU regulations have made it /very/ (errr) 'compelling' to force all manufacturers to hard code radar detect - i.e. they have a right to ban sales of all product by that manufacturer throughout the entire EU and even sieze product passing across any borders.
It makes no difference that we don’t require it here - if it is possible for any one country to disable then it is technically possible for anyone to do so (even if it means import product from outside EU) So,... nope - not gonna happen :-(
Regarding why you are detecting radar, it could be some third party radar activity, like HAM operator or backyard experimenter, or it could be nearby military operations - there are some around your way I think? Not much you can do about it other than try to work with it.
Strictly speaking, across most of that band you *should* be operating with DFS anyhow, so having sporadic radar around there should be managed by the DFS. Does cause hell with customer services when backhauls are going up and down all the time, but if you try to build some redundancy into your backhaul (multiple paths etc) then it is possible to get some relatively decent stability into a 5GHz backhaul network in general.
Cheers, Mike.
-----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.mikr >>>>>> ot >>>>>> 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.mikrot >>>> ik >>>> .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 >> .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.c om .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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Yes, that looks like the same one - though they have revised some of the conditions such as distance to and size of population, applicable bands and other 'fine print' conditions that I suspect were not there before, and no mention of fee any more ;) In any case, the conditions of "no interference, no protection from interference" are still there (that has always been the same wording ;) I suspect that the fee will be very low in comparison with other apparatus licensing. Definitely worth investigation for what you are doing out there! :) Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Friday, 31 May 2019 2:11 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,
I did see reference to this one. It’s the "Radiofrequency spectrum fixed licences Point to point (5.8 GHz band)” at https://www.acma.gov.au/theACMA/radiofrequency-spectrum-fixed- licences#7 <https://www.acma.gov.au/theACMA/radiofrequency-spectrum- fixed-licences#7> I was wondering about it when I saw it the other day.
The important points: The point to point (5.8 GHz band) licensing option is typically used to authorise fixed links with up to 200 Watts EIRP in regional and remote areas. apparatus licences may only be issued on two 20 MHz bandwidth channels centred on 5.745 and 5.785 GHz. only be licensed at locations that are outside defined capital city high and medium density areas and that are also 20 km or more from the centre of any regional city of more than 20 000 people. a special condition applies to licences that will restrict the 3 dB antenna beamwidth of transmitters to +/- 5.5° in the horizontal plane. These restrictions are intended to prevent de facto high power (that is, up to 200 Watts EIRP) point to multipoint services. no more than three point to point stations (typically hub stations) per licensee will be permitted at a site.
I think this could be perfect for the backhaul links and something I’ll have to investigate.
Thanks for the pointer. :-) Andrew
On 31 May 2019, at 1:24 pm, Mike Everest <mike@duxtel.com> wrote:
Hi Andrew,
The correct (and current) 5.8 band is item 60 of the schedule in the LIPD specification: https://www.legislation.gov.au/Details/F2018C00500
The band is 5725 to 5850. Above 5850 is generally referred to as '6GHz band' which is available as licensed band in many countries - thus some equipment supports selection of those bands. You should NOT use them in AU without appropriate apparatus license, else you *will* be prosecuted if you cause problems for a valid licensee ;)
Incidentally, since you mention that town 15Km away, there used to be a '5GHz License' available for low cost (I think it was about $50/year) that allows you to go up to something like 250W EIRP on p2p links. Not sure if it is still available as it has been a while since I looked it up - it was available for links where both ends were beyond 10Km from a population centre of up to 15000 (or was it 15Km from pop of up to 10000 - I can never remember that detail ;)
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Friday, 31 May 2019 11:37 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Radar detection Chaos Since 6.40.4
Hi Mike,
There aren’t any military sites anywhere near where (other than the tiny reservists locations) we are but this link would have a town about 15km away that the AP end is pretty close to being in line to so maybe something from there.
I realised afterwards that if I switched then roles of the two ends then there is nothing the AP could see other than hills and the sky. But then if the link goes down I have no access to it to change the frequency as I’m seeing it from the wrong end. And this tower has no way of getting a link from anywhere else so I’d have to add another radio link to it in a different spectrum range.
This leads me to the next problem. Mikrotik only goes to 5835 MHz. So you can’t fit 3 40MHz channels in the top spectrum range starting at 5725. Others like Mimosa go to 5850. This means that with Mikrotik you can’t have a 5GHz backhaul plus two AP frequencies (with horns so they can be alternated around a tower). For now I’ll have to cope with this radar detect and hope that whatever caused it doesn’t pop up often (it’s the first time in the four months it’s been active) and look at replacing the link with a non-Mikrotik device that can use the higher end of the spectrum.
As a side note to this, the ACMA LIPD class licence page (https://www.acma.gov.au/Industry/Spectrum/Radiocomms- licensing/Class - licences/lipd-class-licence-spectrum-acma <https://www.acma.gov.au/Industry/Spectrum/Radiocomms- licensing/Class - licences/lipd-class-licence-spectrum-acma>) lists the 5.8GHz ISM band as 5725-5875 MHz. That would leave room for 3 x 40MHz with another 20Mhz channel above them. I’d love to know if there are any options from other vendors that give access to the full spectrum (or Mike you might point out a restriction I’ve missed, like that it falls under a Fixed Licence rather than a Class Licence).
Cheers, Andrew
On 28 May 2019, at 9:35 pm, Mike Everest <mike@duxtel.com> wrote:
Hi Andrew,
0% chance that they will turn it off. EU regulations have made it /very/ (errr) 'compelling' to force all manufacturers to hard code radar detect - i.e. they have a right to ban sales of all product by that manufacturer throughout the entire EU and even sieze product passing across any borders.
It makes no difference that we don’t require it here - if it is possible for any one country to disable then it is technically possible for anyone to do so (even if it means import product from outside EU) So,... nope - not gonna happen :-(
Regarding why you are detecting radar, it could be some third party radar activity, like HAM operator or backyard experimenter, or it could be nearby military operations - there are some around your way I think? Not much you can do about it other than try to work with it.
Strictly speaking, across most of that band you *should* be operating with DFS anyhow, so having sporadic radar around there should be managed by the DFS. Does cause hell with customer services when backhauls are going up and down all the time, but if you try to build some redundancy into your backhaul (multiple paths etc) then it is possible to get some relatively decent stability into a 5GHz backhaul network in general.
Cheers, Mike.
-----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.mi >>>>>>> kr >>>>>>> ot >>>>>>> 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.mikr >>>>> ot >>>>> ik >>>>> .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.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 > .c > om > .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.c om .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
participants (5)
-
Andrew Radke -
Jason Hecker (Up & Running Tech) -
Matt Perkins -
Mike Everest -
Tim Warnock