* ath9k/ath10k DFS testing / certification @ 2017-01-15 21:17 Adrian Chadd 2017-01-16 10:06 ` Jean-Pierre Tosoni 2017-01-18 10:26 ` Jean-Pierre Tosoni 0 siblings, 2 replies; 14+ messages in thread From: Adrian Chadd @ 2017-01-15 21:17 UTC (permalink / raw) To: ath9k-devel, ath10k 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ath9k/ath10k DFS testing / certification 2017-01-15 21:17 ath9k/ath10k DFS testing / certification Adrian Chadd @ 2017-01-16 10:06 ` Jean-Pierre Tosoni 2017-01-16 17:42 ` Adrian Chadd 2017-01-18 10:26 ` Jean-Pierre Tosoni 1 sibling, 1 reply; 14+ messages in thread From: Jean-Pierre Tosoni @ 2017-01-16 10:06 UTC (permalink / raw) To: 'Adrian Chadd', ath10k; +Cc: Cedric VONCKEN Hi Adrian, > -----Message d'origine----- > De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de > Adrian Chadd > Envoyé : dimanche 15 janvier 2017 22:17 > À : ath9k-devel; ath10k@lists.infradead.org > 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 > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: ath9k/ath10k DFS testing / certification 2017-01-16 10:06 ` Jean-Pierre Tosoni @ 2017-01-16 17:42 ` Adrian Chadd 2017-01-24 11:16 ` Simon Wunderlich 2017-01-24 14:53 ` Jean-Pierre Tosoni 0 siblings, 2 replies; 14+ messages in thread From: Adrian Chadd @ 2017-01-16 17:42 UTC (permalink / raw) To: Jean-Pierre Tosoni; +Cc: Cedric VONCKEN, ath10k 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 <jp.tosoni@acksys.fr> wrote: > Hi Adrian, > >> -----Message d'origine----- >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de >> Adrian Chadd >> Envoyé : dimanche 15 janvier 2017 22:17 >> À : ath9k-devel; ath10k@lists.infradead.org >> 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 >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ath9k/ath10k DFS testing / certification 2017-01-16 17:42 ` Adrian Chadd @ 2017-01-24 11:16 ` Simon Wunderlich 2017-01-24 15:05 ` Adrian Chadd 2017-01-24 14:53 ` Jean-Pierre Tosoni 1 sibling, 1 reply; 14+ messages in thread From: Simon Wunderlich @ 2017-01-24 11:16 UTC (permalink / raw) To: ath10k; +Cc: Jean-Pierre Tosoni, Adrian Chadd, Cedric VONCKEN [-- Attachment #1.1: Type: text/plain, Size: 5048 bytes --] 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 <jp.tosoni@acksys.fr> wrote: > > Hi Adrian, > > > >> -----Message d'origine----- > >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de > >> Adrian Chadd > >> Envoyé : dimanche 15 janvier 2017 22:17 > >> À : ath9k-devel; ath10k@lists.infradead.org > >> 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 > >> ath10k@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/ath10k > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ath9k/ath10k DFS testing / certification 2017-01-24 11:16 ` Simon Wunderlich @ 2017-01-24 15:05 ` Adrian Chadd 2017-01-24 15:10 ` Simon Wunderlich 0 siblings, 1 reply; 14+ messages in thread From: Adrian Chadd @ 2017-01-24 15:05 UTC (permalink / raw) To: Simon Wunderlich; +Cc: Jean-Pierre Tosoni, Cedric VONCKEN, ath10k hi! On 24 January 2017 at 03:16, Simon Wunderlich <sw@simonwunderlich.de> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ath9k/ath10k DFS testing / certification 2017-01-24 15:05 ` Adrian Chadd @ 2017-01-24 15:10 ` Simon Wunderlich 0 siblings, 0 replies; 14+ messages in thread From: Simon Wunderlich @ 2017-01-24 15:10 UTC (permalink / raw) To: Adrian Chadd; +Cc: Jean-Pierre Tosoni, Cedric VONCKEN, ath10k [-- Attachment #1.1: Type: text/plain, Size: 2004 bytes --] 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 <sw@simonwunderlich.de> 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 [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ath9k/ath10k DFS testing / certification 2017-01-16 17:42 ` Adrian Chadd 2017-01-24 11:16 ` Simon Wunderlich @ 2017-01-24 14:53 ` Jean-Pierre Tosoni 2017-01-24 16:26 ` Adrian Chadd 1 sibling, 1 reply; 14+ messages in thread From: Jean-Pierre Tosoni @ 2017-01-24 14:53 UTC (permalink / raw) To: 'Adrian Chadd'; +Cc: ath10k, Cedric VONCKEN > -----Message d'origine----- > De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de > Adrian Chadd > Envoyé : lundi 16 janvier 2017 18:43 > À : Jean-Pierre Tosoni > Cc : Cedric VONCKEN; ath10k@lists.infradead.org > 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 <jp.tosoni@acksys.fr> > wrote: > > Hi Adrian, > > > >> -----Message d'origine----- > >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de > >> Adrian Chadd Envoyé : dimanche 15 janvier 2017 22:17 À : ath9k-devel; > >> ath10k@lists.infradead.org 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 > >> ath10k@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/ath10k > > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ath9k/ath10k DFS testing / certification 2017-01-24 14:53 ` Jean-Pierre Tosoni @ 2017-01-24 16:26 ` Adrian Chadd 2017-01-24 16:52 ` Jean-Pierre Tosoni 0 siblings, 1 reply; 14+ messages in thread From: Adrian Chadd @ 2017-01-24 16:26 UTC (permalink / raw) To: Jean-Pierre Tosoni; +Cc: ath10k, Cedric VONCKEN On 24 January 2017 at 06:53, Jean-Pierre Tosoni <jp.tosoni@acksys.fr> wrote: > >> -----Message d'origine----- >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de >> Adrian Chadd >> Envoyé : lundi 16 janvier 2017 18:43 >> À : Jean-Pierre Tosoni >> Cc : Cedric VONCKEN; ath10k@lists.infradead.org >> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ath9k/ath10k DFS testing / certification 2017-01-24 16:26 ` Adrian Chadd @ 2017-01-24 16:52 ` Jean-Pierre Tosoni 2017-01-24 17:42 ` Adrian Chadd 0 siblings, 1 reply; 14+ messages in thread From: Jean-Pierre Tosoni @ 2017-01-24 16:52 UTC (permalink / raw) To: 'Adrian Chadd'; +Cc: Cedric VONCKEN, ath10k > -----Message d'origine----- > De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de > Adrian Chadd > Envoyé : mardi 24 janvier 2017 17:27 > À : Jean-Pierre Tosoni > Cc : ath10k@lists.infradead.org; Cedric VONCKEN > Objet : Re: ath9k/ath10k DFS testing / certification > > On 24 January 2017 at 06:53, Jean-Pierre Tosoni <jp.tosoni@acksys.fr> > wrote: > > > >> -----Message d'origine----- > >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de > >> Adrian Chadd Envoyé : lundi 16 janvier 2017 18:43 À : Jean-Pierre > >> Tosoni Cc : Cedric VONCKEN; ath10k@lists.infradead.org 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 > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ath9k/ath10k DFS testing / certification 2017-01-24 16:52 ` Jean-Pierre Tosoni @ 2017-01-24 17:42 ` Adrian Chadd 2017-01-24 18:00 ` Jean-Pierre Tosoni 0 siblings, 1 reply; 14+ messages in thread From: Adrian Chadd @ 2017-01-24 17:42 UTC (permalink / raw) To: Jean-Pierre Tosoni; +Cc: Cedric VONCKEN, ath10k On 24 January 2017 at 08:52, Jean-Pierre Tosoni <jp.tosoni@acksys.fr> wrote: > > >> -----Message d'origine----- >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de >> Adrian Chadd >> Envoyé : mardi 24 janvier 2017 17:27 >> À : Jean-Pierre Tosoni >> Cc : ath10k@lists.infradead.org; Cedric VONCKEN >> Objet : Re: ath9k/ath10k DFS testing / certification >> >> On 24 January 2017 at 06:53, Jean-Pierre Tosoni <jp.tosoni@acksys.fr> >> wrote: >> > >> >> -----Message d'origine----- >> >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de >> >> Adrian Chadd Envoyé : lundi 16 janvier 2017 18:43 À : Jean-Pierre >> >> Tosoni Cc : Cedric VONCKEN; ath10k@lists.infradead.org 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ath9k/ath10k DFS testing / certification 2017-01-24 17:42 ` Adrian Chadd @ 2017-01-24 18:00 ` Jean-Pierre Tosoni 2017-01-24 18:14 ` Adrian Chadd 0 siblings, 1 reply; 14+ messages in thread From: Jean-Pierre Tosoni @ 2017-01-24 18:00 UTC (permalink / raw) To: 'Adrian Chadd'; +Cc: ath10k > -----Message d'origine----- > De : adrian.chadd@gmail.com [mailto:adrian.chadd@gmail.com] De la part de > Adrian Chadd > Envoyé : mardi 24 janvier 2017 18:42 > À : Jean-Pierre Tosoni > Cc : ath10k@lists.infradead.org; Cedric VONCKEN > Objet : Re: ath9k/ath10k DFS testing / certification > > On 24 January 2017 at 08:52, Jean-Pierre Tosoni <jp.tosoni@acksys.fr> > wrote: > > > > > >> -----Message d'origine----- > >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de > >> Adrian Chadd Envoyé : mardi 24 janvier 2017 17:27 À : Jean-Pierre > >> Tosoni Cc : ath10k@lists.infradead.org; Cedric VONCKEN Objet : Re: > >> ath9k/ath10k DFS testing / certification > >> > >> On 24 January 2017 at 06:53, Jean-Pierre Tosoni <jp.tosoni@acksys.fr> > >> wrote: > >> > > >> >> -----Message d'origine----- > >> >> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part > >> >> de Adrian Chadd Envoyé : lundi 16 janvier 2017 18:43 À : > >> >> Jean-Pierre Tosoni Cc : Cedric VONCKEN; ath10k@lists.infradead.org > 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ath9k/ath10k DFS testing / certification 2017-01-24 18:00 ` Jean-Pierre Tosoni @ 2017-01-24 18:14 ` Adrian Chadd 2017-01-26 8:33 ` Jean-Pierre Tosoni 0 siblings, 1 reply; 14+ messages in thread From: Adrian Chadd @ 2017-01-24 18:14 UTC (permalink / raw) To: Jean-Pierre Tosoni; +Cc: ath10k Do you remember what the iperf arguments you used were to pass the ETSI traffic test? thanks, -a _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ath9k/ath10k DFS testing / certification 2017-01-24 18:14 ` Adrian Chadd @ 2017-01-26 8:33 ` Jean-Pierre Tosoni 0 siblings, 0 replies; 14+ messages in thread From: Jean-Pierre Tosoni @ 2017-01-26 8:33 UTC (permalink / raw) To: 'Adrian Chadd'; +Cc: ath10k 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 : adrian.chadd@gmail.com [mailto:adrian.chadd@gmail.com] De la part de > Adrian Chadd > Envoyé : mardi 24 janvier 2017 19:15 > À : Jean-Pierre Tosoni > Cc : ath10k@lists.infradead.org > 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ath9k/ath10k DFS testing / certification 2017-01-15 21:17 ath9k/ath10k DFS testing / certification Adrian Chadd 2017-01-16 10:06 ` Jean-Pierre Tosoni @ 2017-01-18 10:26 ` Jean-Pierre Tosoni 1 sibling, 0 replies; 14+ messages in thread From: Jean-Pierre Tosoni @ 2017-01-18 10:26 UTC (permalink / raw) To: 'Adrian Chadd', 'ath9k-devel', linux-wireless Hi Adrian, Also, about ath9k: I don't know if it's relevant to you, but we had the same problem of NO_IR/RADAR mismatch in ath9k. We fixed this in mac80211 layer at that time. Here is the patch. We didn't send it upstream since We have no experience with other chipsets, and we didn't know whether it would be generic enough. --- a/net/mac80211/scan.c +++ b/net/mac80211/scan.c @@ -598,7 +598,7 @@ static int __ieee80211_start_scan(struct ieee80211_hw_config(local, 0); if ((req->channels[0]->flags & - IEEE80211_CHAN_NO_IR) || + (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR)) || !req->n_ssids) { next_delay = IEEE80211_PASSIVE_CHANNEL_TIME; } else { @@ -646,7 +646,7 @@ ieee80211_scan_get_channel_time(struct i * TODO: channel switching also consumes quite some time, * add that delay as well to get a better estimation */ - if (chan->flags & IEEE80211_CHAN_NO_IR) + if (chan->flags & (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR)) return IEEE80211_PASSIVE_CHANNEL_TIME; return local->scan_req->probe_delay_ticks + local->scan_req->max_channel_time_ticks; } @@ -810,7 +810,7 @@ static void ieee80211_scan_state_set_cha * * In any case, it is not necessary for a passive scan. */ - if (chan->flags & IEEE80211_CHAN_NO_IR || !scan_req->n_ssids) { + if (chan->flags & (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR) || !scan_req->n_ssids) { *next_delay = IEEE80211_PASSIVE_CHANNEL_TIME; local->next_scan_state = SCAN_DECISION; return; -- Diff -u > -----Message d'origine----- > De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de > Adrian Chadd > Envoyé : dimanche 15 janvier 2017 22:17 > À : ath9k-devel; ath10k@lists.infradead.org > 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 > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-01-26 9:24 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-15 21:17 ath9k/ath10k DFS testing / certification Adrian Chadd 2017-01-16 10:06 ` Jean-Pierre Tosoni 2017-01-16 17:42 ` Adrian Chadd 2017-01-24 11:16 ` Simon Wunderlich 2017-01-24 15:05 ` Adrian Chadd 2017-01-24 15:10 ` Simon Wunderlich 2017-01-24 14:53 ` Jean-Pierre Tosoni 2017-01-24 16:26 ` Adrian Chadd 2017-01-24 16:52 ` Jean-Pierre Tosoni 2017-01-24 17:42 ` Adrian Chadd 2017-01-24 18:00 ` Jean-Pierre Tosoni 2017-01-24 18:14 ` Adrian Chadd 2017-01-26 8:33 ` Jean-Pierre Tosoni 2017-01-18 10:26 ` Jean-Pierre Tosoni
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.