ath9k/ath10k DFS testing / certification
jp.tosoni at acksys.fr
Tue Jan 24 06:53:53 PST 2017
> -----Message d'origine-----
> De : ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
> Adrian Chadd
> Envoyé : lundi 16 janvier 2017 18:43
> À : Jean-Pierre Tosoni
> Cc : Cedric VONCKEN; ath10k at lists.infradead.org
> Objet : Re: ath9k/ath10k DFS testing / certification
> 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.
> On 16 January 2017 at 02:06, Jean-Pierre Tosoni <jp.tosoni at acksys.fr>
> > Hi Adrian,
> >> -----Message d'origine-----
> >> De : ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
> >> Adrian Chadd Envoyé : dimanche 15 janvier 2017 22:17 À : ath9k-devel;
> >> ath10k at 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;
> > --
> > 22.214.171.124
> > 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 at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/ath10k
> ath10k mailing list
> ath10k at lists.infradead.org
More information about the ath10k