ath10k firmware sends probes on DFS channels without radar detection

[Jean-Pierre Tosoni]

> -----Message d'origine-----
> De : Jouni Malinen [mailto:j at w1.fi]
> Envoyé : jeudi 15 décembre 2016 23:58
> À : Jean-Pierre Tosoni
> Cc : 'Ben Greear'; linux-wireless at vger.kernel.org;
> ath10k at lists.infradead.org
> Objet : Re: ath10k firmware sends probes on DFS channels without radar
> detection
> 
> On Thu, Dec 15, 2016 at 06:53:47PM +0100, Jean-Pierre Tosoni wrote:
> > > > Thanks for the suggestion, I already tried something like this in
> > > > wmi.c, with the same result:
> > > >
> > > > - Before patching the firmware scans DFS channels actively (with
> > > probes).
> > > >
> > > > - After patching, the firmware scans DFS channels passively
> > > > *until* any beacon is received on the DFS channel. When *any*
> > > > beacon is seen, the firmware decides to scan actively on its own,
> > > > without any new IR/RADAR info from the driver.
> > > >
> > > > So, your patch is required but not sufficient.
> > > >
> > > > Somehow I was able to overcome this by reloading the regulation
> > > > domain in the radio card before each scan request:
> 
> Interesting.. I'm not completely sure what could have changed the behavior
> based on beacon hint. I thought it was cfg80211, but if the simple change
> for doing NO_IR | RADAR is not sufficient, it would seem to imply that
> something else can do this. Some more debugging to do, I guess.

After some debugging I think the card firmware does this, probably due to
the lack of precise definition of NO_IR, see below.

> 
> > The distinction between NO_IR and CHAN_RADAR is not very clear to me.
> > NO_IR appears only in the world regulatory domain so it's not relevant
> here.
> 
> NO_IR is a combination of not allowing AP, IBSS, or active scanning
> without having somehow been enabled by another device. RADAR has that same
> impact and in addition, requirement for doing radar detection and DFS by a
> master device.

Ah, thanks. But then, NO_IR does not define the way for the "other device"
to enable the local device? So, depending on the interpretation, it can
render the local device unusable. OTOH RADAR defines a way which depends on
the local regulations.

> 
> > I'd say
> >  "the CHAN_RADAR flag should always make the firmware never do IR when
> > probing"
> > ...maybe, except if the channel is the operating channel. (this should
> > exclude unassociated stations)
> 
> For most cases, I'd agree that active scanning should not be used on DFS
> channels. That said, unicast Probe Request frame to the current AP while
> associated could be a reasonable exception. In addition, WPS with PBC
> depends on Probe Request frames to allow PBC session overlap detection, so
> there might be sufficient justification to allow Probe Request frame to be
> sent out for a very short duration (couple of seconds) after seeing a
> Beacon frame on the channel for such special cases.

I agree that unicast probes to the current AP should go through. It goes
with my condition "operating channel".

For WPS, I do not know it well, but I guess probes are acceptable if
1) they are not sent repeatedly over a long period of time during
unassociated state,
2) the AP uses CAC.
And here, both seem to be true.

> 
> --
> Jouni Malinen                                            PGP id EFC895FA

Regards, Jean-Pierre