ath9k/ath10k DFS testing / certification

Commit Message

Jean-Pierre TOSONI Jan. 16, 2017, 10:06 a.m. UTC

Hi Adrian,

> -----Message d'origine-----
> De : ath10k [mailto:[e-mail]] De la part de
> Adrian Chadd
> Envoyé : dimanche 15 janvier 2017 22:17
> À : ath9k-devel; [e-mail]
> Objet : ath9k/ath10k DFS testing / certification
> 
> hiya,
> 
> I'm working on a set of things that will involve DFS certification for
> ath9k/ath10k. Initially it'll be for FCC but I'll branch out to the other
> regions shortly afterwards.
> 
> I'd love to hear from anyone else who has done this and what their
> challenges were, including whether they have any local patches / tools
> that haven't yet been upstreamed.
> 
> Thanks!
> 
> 
> -adrian

For the record, a summary of our discussion last month.

We went to an independent lab with wpa_supplicant+ath10k+Compex WLE900VX
(QCA988x) for ETSI certification.
We passed for the most part, but we were rejected because the supplicant
sends probes on DFS channels.
We applied the following patch that did solve the issue at hand, but made
another issue appear:
=> the QCA firmware believes any rogue system that sends out beacons on a
DFS channel, so that
the firmware active-scans that channel, without checking for radar
signatures on its own.

So the patch solves only part of the issue.

Patch:

Process NO_IR and RADAR flags in the same manner. Do this only when channels
are prepared for a scan, in order to avoid side effects.
---
 			ch->freq = channel->center_freq;

Comments

Adrian Chadd Jan. 16, 2017, 5:42 p.m. UTC | #1

hiya,

Yeah - i was a part of that discussion. :) That's why I was pointing
out that likely I'm going to bug QCA to get this fixed when the time
is right.

So, time is right :)

Did you do DFS certification for AP/master devices, or just client?



-adrian


On 16 January 2017 at 02:06, Jean-Pierre Tosoni <[e-mail]> wrote:
> Hi Adrian,
>
>> -----Message d'origine-----
>> De : ath10k [mailto:[e-mail]] De la part de
>> Adrian Chadd
>> Envoyé : dimanche 15 janvier 2017 22:17
>> À : ath9k-devel; [e-mail]
>> Objet : ath9k/ath10k DFS testing / certification
>>
>> hiya,
>>
>> I'm working on a set of things that will involve DFS certification for
>> ath9k/ath10k. Initially it'll be for FCC but I'll branch out to the other
>> regions shortly afterwards.
>>
>> I'd love to hear from anyone else who has done this and what their
>> challenges were, including whether they have any local patches / tools
>> that haven't yet been upstreamed.
>>
>> Thanks!
>>
>>
>> -adrian
>
> For the record, a summary of our discussion last month.
>
> We went to an independent lab with wpa_supplicant+ath10k+Compex WLE900VX
> (QCA988x) for ETSI certification.
> We passed for the most part, but we were rejected because the supplicant
> sends probes on DFS channels.
> We applied the following patch that did solve the issue at hand, but made
> another issue appear:
> => the QCA firmware believes any rogue system that sends out beacons on a
> DFS channel, so that
> the firmware active-scans that channel, without checking for radar
> signatures on its own.
>
> So the patch solves only part of the issue.
>
> Patch:
>
> Process NO_IR and RADAR flags in the same manner. Do this only when channels
> are prepared for a scan, in order to avoid side effects.
> ---
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -5679,6 +5679,9 @@ ath10k_wmi_op_gen_scan_chan_list(struct
>                 ci = &cmd->chan_info[i];
>
>                 ath10k_wmi_put_wmi_channel(ci, ch);
> +
> +               if (ch->chan_radar)
> +                       ci->flags |= __cpu_to_le32(WMI_CHAN_FLAG_PASSIVE);
>         }
>
>         return skb;
> --
> 1.7.2.5
>
> Jouni Malinen suggested an equivalent, more general, form of the above,
> which seems to work as well:
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index aa545a1..758dbbd 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k
> *ar)
>                         ch->chan_radar =
>                                 !!(channel->flags & IEEE80211_CHAN_RADAR);
>
> -                       passive = channel->flags & IEEE80211_CHAN_NO_IR;
> +                       passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> +                                                   IEEE80211_CHAN_RADAR);
>                         ch->passive = passive;
>
>                         ch->freq = channel->center_freq;
>
> --
> (by Jouni Malinen)
>
>>
>> _______________________________________________
>> ath10k mailing list
>> [e-mail]
>> http://lists.infradead.org/mailman/listinfo/ath10k
>

Simon Wunderlich Jan. 24, 2017, 11:16 a.m. UTC | #2

Hi Adrian,

I've been doing DFS pre-tests back in December 2016. We did AP tests for a 
9880 based AP for ETSI and FCC region. We had two small patches for making the 
tests less painful (in hostapd and mac80211): 

 * disable CSA on incoming radar, that is keep on staying on the operating 
channels. That makes continouos testing of radar signals much easier (usually 
you test like 10 radars in a row), since we don't had to reboot the device all 
the time.
 * shorten CAC to 3 seconds, because waiting 60 seconds is also taking some 
time

All FCC tests pass, at least from the radar detection point. ETSI had a 
problem with one of the patterns. We used iperf UDP tests to generate load, 
but will probably switch to another tool in the next round (or tune it), since 
it seems to send packets too bursty, which could be the cause for the failed 
ETSI test.

Thanks for the info on the scan bug, we discovered that too, but thought we 
could fix it in mac80211 (but never really followed up). Please keep me in the 
loop when this is fixed. :)

Cheers,
     Simon

On Monday, January 16, 2017 9:42:33 AM CET Adrian Chadd wrote:
> hiya,
> 
> Yeah - i was a part of that discussion. :) That's why I was pointing
> out that likely I'm going to bug QCA to get this fixed when the time
> is right.
> 
> So, time is right :)
> 
> Did you do DFS certification for AP/master devices, or just client?
> 
> 
> 
> -adrian
> 
> On 16 January 2017 at 02:06, Jean-Pierre Tosoni <[e-mail]> wrote:
> > Hi Adrian,
> > 
> >> -----Message d'origine-----
> >> De : ath10k [mailto:[e-mail]] De la part de
> >> Adrian Chadd
> >> Envoyé : dimanche 15 janvier 2017 22:17
> >> À : ath9k-devel; [e-mail]
> >> Objet : ath9k/ath10k DFS testing / certification
> >> 
> >> hiya,
> >> 
> >> I'm working on a set of things that will involve DFS certification for
> >> ath9k/ath10k. Initially it'll be for FCC but I'll branch out to the other
> >> regions shortly afterwards.
> >> 
> >> I'd love to hear from anyone else who has done this and what their
> >> challenges were, including whether they have any local patches / tools
> >> that haven't yet been upstreamed.
> >> 
> >> Thanks!
> >> 
> >> 
> >> -adrian
> > 
> > For the record, a summary of our discussion last month.
> > 
> > We went to an independent lab with wpa_supplicant+ath10k+Compex WLE900VX
> > (QCA988x) for ETSI certification.
> > We passed for the most part, but we were rejected because the supplicant
> > sends probes on DFS channels.
> > We applied the following patch that did solve the issue at hand, but made
> > another issue appear:
> > => the QCA firmware believes any rogue system that sends out beacons on a
> > DFS channel, so that
> > the firmware active-scans that channel, without checking for radar
> > signatures on its own.
> > 
> > So the patch solves only part of the issue.
> > 
> > Patch:
> > 
> > Process NO_IR and RADAR flags in the same manner. Do this only when
> > channels are prepared for a scan, in order to avoid side effects.
> > ---
> > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > @@ -5679,6 +5679,9 @@ ath10k_wmi_op_gen_scan_chan_list(struct
> > 
> >                 ci = &cmd->chan_info[i];
> >                 
> >                 ath10k_wmi_put_wmi_channel(ci, ch);
> > 
> > +
> > +               if (ch->chan_radar)
> > +                       ci->flags |= __cpu_to_le32(WMI_CHAN_FLAG_PASSIVE);
> > 
> >         }
> >         
> >         return skb;
> > 
> > --
> > 1.7.2.5
> > 
> > Jouni Malinen suggested an equivalent, more general, form of the above,
> > which seems to work as well:
> > 
> > diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> > b/drivers/net/wireless/ath/ath10k/mac.c
> > index aa545a1..758dbbd 100644
> > --- a/drivers/net/wireless/ath/ath10k/mac.c
> > +++ b/drivers/net/wireless/ath/ath10k/mac.c
> > @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k
> > *ar)
> > 
> >                         ch->chan_radar =
> >                         
> >                                 !!(channel->flags & IEEE80211_CHAN_RADAR);
> > 
> > -                       passive = channel->flags & IEEE80211_CHAN_NO_IR;
> > +                       passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> > +                                                   IEEE80211_CHAN_RADAR);
> > 
> >                         ch->passive = passive;
> >                         
> >                         ch->freq = channel->center_freq;
> > 
> > --
> > (by Jouni Malinen)
> > 
> >> _______________________________________________
> >> ath10k mailing list
> >> [e-mail]
> >> http://lists.infradead.org/mailman/listinfo/ath10k
> 
> _______________________________________________
> ath10k mailing list
> [e-mail]
> http://lists.infradead.org/mailman/listinfo/ath10k

Jean-Pierre TOSONI Jan. 24, 2017, 2:53 p.m. UTC | #3

> -----Message d'origine-----
> De : ath10k [mailto:[e-mail]] De la part de
> Adrian Chadd
> Envoyé : lundi 16 janvier 2017 18:43
> À : Jean-Pierre Tosoni
> Cc : Cedric VONCKEN; [e-mail]
> Objet : Re: ath9k/ath10k DFS testing / certification
> 
> hiya,
> 
> Yeah - i was a part of that discussion. :) That's why I was pointing out
> that likely I'm going to bug QCA to get this fixed when the time is right.
> 
> So, time is right :)
> 
> Did you do DFS certification for AP/master devices, or just client?

We did it for both AP and client modes.
We had the same problem with IPERF than Simon, and we solved that by defining a huge packet size and IPERF would send it every now and then just enough to meet the throughput required.

Jean-Pierre

> 
> 
> 
> -adrian
> 
> 
> On 16 January 2017 at 02:06, Jean-Pierre Tosoni <[e-mail]>
> wrote:
> > Hi Adrian,
> >
> >> -----Message d'origine-----
> >> De : ath10k [mailto:[e-mail]] De la part de
> >> Adrian Chadd Envoyé : dimanche 15 janvier 2017 22:17 À : ath9k-devel;
> >> [e-mail] Objet : ath9k/ath10k DFS testing /
> >> certification
> >>
> >> hiya,
> >>
> >> I'm working on a set of things that will involve DFS certification
> >> for ath9k/ath10k. Initially it'll be for FCC but I'll branch out to
> >> the other regions shortly afterwards.
> >>
> >> I'd love to hear from anyone else who has done this and what their
> >> challenges were, including whether they have any local patches /
> >> tools that haven't yet been upstreamed.
> >>
> >> Thanks!
> >>
> >>
> >> -adrian
> >
> > For the record, a summary of our discussion last month.
> >
> > We went to an independent lab with wpa_supplicant+ath10k+Compex
> > WLE900VX
> > (QCA988x) for ETSI certification.
> > We passed for the most part, but we were rejected because the
> > supplicant sends probes on DFS channels.
> > We applied the following patch that did solve the issue at hand, but
> > made another issue appear:
> > => the QCA firmware believes any rogue system that sends out beacons
> > on a DFS channel, so that the firmware active-scans that channel,
> > without checking for radar signatures on its own.
> >
> > So the patch solves only part of the issue.
> >
> > Patch:
> >
> > Process NO_IR and RADAR flags in the same manner. Do this only when
> > channels are prepared for a scan, in order to avoid side effects.
> > ---
> > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > @@ -5679,6 +5679,9 @@ ath10k_wmi_op_gen_scan_chan_list(struct
> >                 ci = &cmd->chan_info[i];
> >
> >                 ath10k_wmi_put_wmi_channel(ci, ch);
> > +
> > +               if (ch->chan_radar)
> > +                       ci->flags |=
> > + __cpu_to_le32(WMI_CHAN_FLAG_PASSIVE);
> >         }
> >
> >         return skb;
> > --
> > 1.7.2.5
> >
> > Jouni Malinen suggested an equivalent, more general, form of the
> > above, which seems to work as well:
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> > b/drivers/net/wireless/ath/ath10k/mac.c
> > index aa545a1..758dbbd 100644
> > --- a/drivers/net/wireless/ath/ath10k/mac.c
> > +++ b/drivers/net/wireless/ath/ath10k/mac.c
> > @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct
> > ath10k
> > *ar)
> >                         ch->chan_radar =
> >                                 !!(channel->flags &
> > IEEE80211_CHAN_RADAR);
> >
> > -                       passive = channel->flags & IEEE80211_CHAN_NO_IR;
> > +                       passive = channel->flags & (IEEE80211_CHAN_NO_IR
> |
> > +
> > + IEEE80211_CHAN_RADAR);
> >                         ch->passive = passive;
> >
> >                         ch->freq = channel->center_freq;
> >
> > --
> > (by Jouni Malinen)
> >
> >>
> >> _______________________________________________
> >> ath10k mailing list
> >> [e-mail]
> >> http://lists.infradead.org/mailman/listinfo/ath10k
> >
> 
> _______________________________________________
> ath10k mailing list
> [e-mail]
> http://lists.infradead.org/mailman/listinfo/ath10k

Adrian Chadd Jan. 24, 2017, 3:05 p.m. UTC | #4

hi!


On 24 January 2017 at 03:16, Simon Wunderlich <[e-mail]> wrote:
> Hi Adrian,
>
> I've been doing DFS pre-tests back in December 2016. We did AP tests for a
> 9880 based AP for ETSI and FCC region. We had two small patches for making the
> tests less painful (in hostapd and mac80211):
>
>  * disable CSA on incoming radar, that is keep on staying on the operating
> channels. That makes continouos testing of radar signals much easier (usually
> you test like 10 radars in a row), since we don't had to reboot the device all
> the time.
>  * shorten CAC to 3 seconds, because waiting 60 seconds is also taking some
> time

Do you have those patches available somewhere?

>
> All FCC tests pass, at least from the radar detection point. ETSI had a
> problem with one of the patterns. We used iperf UDP tests to generate load,
> but will probably switch to another tool in the next round (or tune it), since
> it seems to send packets too bursty, which could be the cause for the failed
> ETSI test.

Ok. What are you using to generate radar patterns for testing?

> Thanks for the info on the scan bug, we discovered that too, but thought we
> could fix it in mac80211 (but never really followed up). Please keep me in the
> loop when this is fixed. :)

:) I'll punt this to QCA if/when the right time arises and see if
they'll fix ath10k firmware.

Thanks!



-a

Simon Wunderlich Jan. 24, 2017, 3:10 p.m. UTC | #5

Hi Adrian,

On Tuesday, January 24, 2017 7:05:58 AM CET Adrian Chadd wrote:
> hi!
> 
> On 24 January 2017 at 03:16, Simon Wunderlich <[e-mail]> wrote:
> > Hi Adrian,
> > 
> > I've been doing DFS pre-tests back in December 2016. We did AP tests for a
> > 9880 based AP for ETSI and FCC region. We had two small patches for making
> > the> 
> > tests less painful (in hostapd and mac80211):
> >  * disable CSA on incoming radar, that is keep on staying on the operating
> > 
> > channels. That makes continouos testing of radar signals much easier
> > (usually you test like 10 radars in a row), since we don't had to reboot
> > the device all the time.
> > 
> >  * shorten CAC to 3 seconds, because waiting 60 seconds is also taking
> >  some
> > 
> > time
> 
> Do you have those patches available somewhere?
> 

not sure if I can release them, so no. :)

But both were rather trivial, the first one is a change in hostapd, the latter 
in mac80211.

> > All FCC tests pass, at least from the radar detection point. ETSI had a
> > problem with one of the patterns. We used iperf UDP tests to generate
> > load,
> > but will probably switch to another tool in the next round (or tune it),
> > since it seems to send packets too bursty, which could be the cause for
> > the failed ETSI test.
> 
> Ok. What are you using to generate radar patterns for testing?
> 

We used 300k+ EUR Rohde&Schwarz equipment of the certification lab. :)

I don't have a pattern generation available at my home, but I remember 
discussions that it's possible to get something useful and cheap using SDRs 
(with cheap I mean in the <5k$ range). I believe Zefir had tried this route 
...

> > Thanks for the info on the scan bug, we discovered that too, but thought
> > we
> > could fix it in mac80211 (but never really followed up). Please keep me in
> > the loop when this is fixed. :)
> :
> :) I'll punt this to QCA if/when the right time arises and see if
> 
> they'll fix ath10k firmware.

Excellent!

     Simon

Adrian Chadd Jan. 24, 2017, 4:26 p.m. UTC | #6

On 24 January 2017 at 06:53, Jean-Pierre Tosoni <[e-mail]> wrote:
>
>> -----Message d'origine-----
>> De : ath10k [mailto:[e-mail]] De la part de
>> Adrian Chadd
>> Envoyé : lundi 16 janvier 2017 18:43
>> À : Jean-Pierre Tosoni
>> Cc : Cedric VONCKEN; [e-mail]
>> Objet : Re: ath9k/ath10k DFS testing / certification
>>
>> hiya,
>>
>> Yeah - i was a part of that discussion. :) That's why I was pointing out
>> that likely I'm going to bug QCA to get this fixed when the time is right.
>>
>> So, time is right :)
>>
>> Did you do DFS certification for AP/master devices, or just client?
>
> We did it for both AP and client modes.
> We had the same problem with IPERF than Simon, and we solved that by defining a huge packet size and IPERF would send it every now and then just enough to meet the throughput required.

The traffic duty cycle stuff was always a pain to get "right" when I
was last doing this (pre ath10k hardware.)

Is this just for your local testing, or is this something the testing
house / FCC / etc defines?

(Yes, I know about the traffic duty cycle definitions in the FCC spec
and how that changed over time, but I also remember how different
locations/labs had subtly different testing setups with different
"bursty" traffic.)



-adrian

Jean-Pierre TOSONI Jan. 24, 2017, 4:52 p.m. UTC | #7

> -----Message d'origine-----
> De : ath10k [mailto:[e-mail]] De la part de
> Adrian Chadd
> Envoyé : mardi 24 janvier 2017 17:27
> À : Jean-Pierre Tosoni
> Cc : [e-mail]; Cedric VONCKEN
> Objet : Re: ath9k/ath10k DFS testing / certification
> 
> On 24 January 2017 at 06:53, Jean-Pierre Tosoni <[e-mail]>
> wrote:
> >
> >> -----Message d'origine-----
> >> De : ath10k [mailto:[e-mail]] De la part de
> >> Adrian Chadd Envoyé : lundi 16 janvier 2017 18:43 À : Jean-Pierre
> >> Tosoni Cc : Cedric VONCKEN; [e-mail] Objet : Re:
> >> ath9k/ath10k DFS testing / certification
> >>
> >> hiya,
> >>
> >> Yeah - i was a part of that discussion. :) That's why I was pointing
> >> out that likely I'm going to bug QCA to get this fixed when the time is
> right.
> >>
> >> So, time is right :)
> >>
> >> Did you do DFS certification for AP/master devices, or just client?
> >
> > We did it for both AP and client modes.
> > We had the same problem with IPERF than Simon, and we solved that by
> defining a huge packet size and IPERF would send it every now and then
> just enough to meet the throughput required.
> 
> The traffic duty cycle stuff was always a pain to get "right" when I was
> last doing this (pre ath10k hardware.)
> 
> Is this just for your local testing, or is this something the testing
> house / FCC / etc defines?

FCC I don't know, I'm concerned with ETSI ;)
We used that at an external lab, and they verified that we complied with the
30% over 100ms requirement (see below). 

ETSI EN 301 893 defines a specific burst requirement for DFS testing, to quote it:
  "...shall consist of packet transmissions that together exceed the transmitter
  minimum activity ratio of 30 % measured over an interval of 100 ms..."

The requirement is not really picky, it could be one mega-frame after every beacon or such.
If we uses too much throughput or tightly sequenced frames, the radar signatures would be lost among the data frames.

(Other tests (not about DFS) have more stringent requirements, e.g. 10% bandwidth
over periods of 2ms)
> 
> (Yes, I know about the traffic duty cycle definitions in the FCC spec and
> how that changed over time, but I also remember how different
> locations/labs had subtly different testing setups with different "bursty"
> traffic.)
> 
We made the setup and the lab checked that it was within the norm requirements.

Jean-Pierre
> 
> 
> -adrian
> 
> _______________________________________________
> ath10k mailing list
> [e-mail]
> http://lists.infradead.org/mailman/listinfo/ath10k

Adrian Chadd Jan. 24, 2017, 5:42 p.m. UTC | #8

On 24 January 2017 at 08:52, Jean-Pierre Tosoni <[e-mail]> wrote:
>
>
>> -----Message d'origine-----
>> De : ath10k [mailto:[e-mail]] De la part de
>> Adrian Chadd
>> Envoyé : mardi 24 janvier 2017 17:27
>> À : Jean-Pierre Tosoni
>> Cc : [e-mail]; Cedric VONCKEN
>> Objet : Re: ath9k/ath10k DFS testing / certification
>>
>> On 24 January 2017 at 06:53, Jean-Pierre Tosoni <[e-mail]>
>> wrote:
>> >
>> >> -----Message d'origine-----
>> >> De : ath10k [mailto:[e-mail]] De la part de
>> >> Adrian Chadd Envoyé : lundi 16 janvier 2017 18:43 À : Jean-Pierre
>> >> Tosoni Cc : Cedric VONCKEN; [e-mail] Objet : Re:
>> >> ath9k/ath10k DFS testing / certification
>> >>
>> >> hiya,
>> >>
>> >> Yeah - i was a part of that discussion. :) That's why I was pointing
>> >> out that likely I'm going to bug QCA to get this fixed when the time is
>> right.
>> >>
>> >> So, time is right :)
>> >>
>> >> Did you do DFS certification for AP/master devices, or just client?
>> >
>> > We did it for both AP and client modes.
>> > We had the same problem with IPERF than Simon, and we solved that by
>> defining a huge packet size and IPERF would send it every now and then
>> just enough to meet the throughput required.
>>
>> The traffic duty cycle stuff was always a pain to get "right" when I was
>> last doing this (pre ath10k hardware.)
>>
>> Is this just for your local testing, or is this something the testing
>> house / FCC / etc defines?
>
> FCC I don't know, I'm concerned with ETSI ;)
> We used that at an external lab, and they verified that we complied with the
> 30% over 100ms requirement (see below).
>
> ETSI EN 301 893 defines a specific burst requirement for DFS testing, to quote it:
>   "...shall consist of packet transmissions that together exceed the transmitter
>   minimum activity ratio of 30 % measured over an interval of 100 ms..."
>
> The requirement is not really picky, it could be one mega-frame after every beacon or such.
> If we uses too much throughput or tightly sequenced frames, the radar signatures would be lost among the data frames.
>
> (Other tests (not about DFS) have more stringent requirements, e.g. 10% bandwidth
> over periods of 2ms)
>>
>> (Yes, I know about the traffic duty cycle definitions in the FCC spec and
>> how that changed over time, but I also remember how different
>> locations/labs had subtly different testing setups with different "bursty"
>> traffic.)
>>
> We made the setup and the lab checked that it was within the norm requirements.

ok!

Did you (or anyone else) tweak the quiet time configuration whilst
doing DFS master mode testing?

Maybe doing some tweaks like "maximum aggregation frame length",
"maximum burst length", "quiet time", etc could make the AP side
transmitter work without hacking on iperf, etc.

Thanks,


-adrian

Jean-Pierre TOSONI Jan. 24, 2017, 6 p.m. UTC | #9

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part de
> Adrian Chadd
> Envoyé : mardi 24 janvier 2017 18:42
> À : Jean-Pierre Tosoni
> Cc : [e-mail]; Cedric VONCKEN
> Objet : Re: ath9k/ath10k DFS testing / certification
> 
> On 24 January 2017 at 08:52, Jean-Pierre Tosoni <[e-mail]>
> wrote:
> >
> >
> >> -----Message d'origine-----
> >> De : ath10k [mailto:[e-mail]] De la part de
> >> Adrian Chadd Envoyé : mardi 24 janvier 2017 17:27 À : Jean-Pierre
> >> Tosoni Cc : [e-mail]; Cedric VONCKEN Objet : Re:
> >> ath9k/ath10k DFS testing / certification
> >>
> >> On 24 January 2017 at 06:53, Jean-Pierre Tosoni <[e-mail]>
> >> wrote:
> >> >
> >> >> -----Message d'origine-----
> >> >> De : ath10k [mailto:[e-mail]] De la part
> >> >> de Adrian Chadd Envoyé : lundi 16 janvier 2017 18:43 À :
> >> >> Jean-Pierre Tosoni Cc : Cedric VONCKEN; [e-mail]
> Objet : Re:
> >> >> ath9k/ath10k DFS testing / certification
> >> >>
> >> >> hiya,
> >> >>
> >> >> Yeah - i was a part of that discussion. :) That's why I was
> >> >> pointing out that likely I'm going to bug QCA to get this fixed
> >> >> when the time is
> >> right.
> >> >>
> >> >> So, time is right :)
> >> >>
> >> >> Did you do DFS certification for AP/master devices, or just client?
> >> >
> >> > We did it for both AP and client modes.
> >> > We had the same problem with IPERF than Simon, and we solved that
> >> > by
> >> defining a huge packet size and IPERF would send it every now and
> >> then just enough to meet the throughput required.
> >>
> >> The traffic duty cycle stuff was always a pain to get "right" when I
> >> was last doing this (pre ath10k hardware.)
> >>
> >> Is this just for your local testing, or is this something the testing
> >> house / FCC / etc defines?
> >
> > FCC I don't know, I'm concerned with ETSI ;) We used that at an
> > external lab, and they verified that we complied with the 30% over
> > 100ms requirement (see below).
> >
> > ETSI EN 301 893 defines a specific burst requirement for DFS testing, to
> quote it:
> >   "...shall consist of packet transmissions that together exceed the
> transmitter
> >   minimum activity ratio of 30 % measured over an interval of 100 ms..."
> >
> > The requirement is not really picky, it could be one mega-frame after
> every beacon or such.
> > If we uses too much throughput or tightly sequenced frames, the radar
> signatures would be lost among the data frames.
> >
> > (Other tests (not about DFS) have more stringent requirements, e.g.
> > 10% bandwidth over periods of 2ms)
> >>
> >> (Yes, I know about the traffic duty cycle definitions in the FCC spec
> >> and how that changed over time, but I also remember how different
> >> locations/labs had subtly different testing setups with different
> "bursty"
> >> traffic.)
> >>
> > We made the setup and the lab checked that it was within the norm
> requirements.
> 
> ok!
> 
> Did you (or anyone else) tweak the quiet time configuration whilst doing
> DFS master mode testing?
> 
> Maybe doing some tweaks like "maximum aggregation frame length", "maximum
> burst length", "quiet time", etc could make the AP side transmitter work
> without hacking on iperf, etc.

No, since we seldom have to conduct this test, we just made an on-site adjustment
on iperf arguments so we could pass.
> 
> Thanks,
> 
> 
> -adrian

Adrian Chadd Jan. 24, 2017, 6:14 p.m. UTC | #10

Do you remember what the iperf arguments you used were to pass the
ETSI traffic test?

thanks,


-a

Jean-Pierre TOSONI Jan. 26, 2017, 8:33 a.m. UTC | #11

Precise information was not kept on written record :-((

The arguments could depend on the 802.11 mode used. Only one configuration was tested:
802.11n+a, BW 40 MHz, 1 stream using wired antennas => we can assume the bit rate was 150 Mbps, we want 30% throughput

So, the iperf was set to UDP, 50Mbps, pktlen 30000 bytes
iperf ... -u -l 30K -b 50M
The arguments were adjusted on-site by trial and error with an analyzer displaying power vs time on the central frequency.

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part de
> Adrian Chadd
> Envoyé : mardi 24 janvier 2017 19:15
> À : Jean-Pierre Tosoni
> Cc : [e-mail]
> Objet : Re: ath9k/ath10k DFS testing / certification
> 
> Do you remember what the iperf arguments you used were to pass the ETSI
> traffic test?
> 
> thanks,
> 
> 
> -a

Patch

--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5679,6 +5679,9 @@  ath10k_wmi_op_gen_scan_chan_list(struct
 		ci = &cmd->chan_info[i];
 
 		ath10k_wmi_put_wmi_channel(ci, ch);
+
+		if (ch->chan_radar)
+			ci->flags |= __cpu_to_le32(WMI_CHAN_FLAG_PASSIVE);
 	}
 
 	return skb;
-- 
1.7.2.5

Jouni Malinen suggested an equivalent, more general, form of the above,
which seems to work as well:

diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index aa545a1..758dbbd 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2973,7 +2973,8 @@  static int ath10k_update_channel_list(struct ath10k
*ar)
 			ch->chan_radar =
 				!!(channel->flags & IEEE80211_CHAN_RADAR);
 
-			passive = channel->flags & IEEE80211_CHAN_NO_IR;
+			passive = channel->flags & (IEEE80211_CHAN_NO_IR |
+						    IEEE80211_CHAN_RADAR);
 			ch->passive = passive;