So far I haven't received one AR5K_INT_RXPHY interrupt yet. Mind you we
are already setting radar to 1 too -- we do this at the end of
ath_reset() with ath5k_hw_enable_radar_alert() -- so not sure what's
going on. I do live in front of a cemetery...
You may be using an AR5210 chip?
Look at madwifi-dfs branch in madwifi.org for an example of how to
configure the pulse detector. To get radar pulse detection to work you
have to update the pulse detection configuration, disable the filtering
of PHY radar errors, and enable the radar detection. Then you should be
able to get the errors just by playing a video (such as the one provided
by the FCC) between a client and the AP. You should get enough false
positives from the pulse detector to notice. You won't get them from an
idle AP, and you are very unlikely to detect real radar (in my
experience). I work at NASA Research Park at what was formerly Moffett
Air Base. There's an airport less than 1 mile away and I've never
detected true radar.
IMPORTANT: The Atheros hardware 5212 and higher provides only pulse
detection, NOT radar detection. The 5210 stuff doesn't even provide
radar errors or pulse detection... it's supposed to be possible to use
zero-byte packets with PHYERR or something if you disable filtering of
zero byte packets, but I haven't tried it.
The driver has to match the pulses to known patterns and filter out the
noise. It has to be able to filter out excess pulses and handle missed
pulses (you can't detect radar while transmitting). That's why the
madwifi-dfs branch has been brewing for longer than you might think. The
Atheros proprietary drivers provide one implementation of matching and
the madwifi-dfs branch currently works for all short-pulse type radars,
and isn't quite ready for prime time for long pulse type radars.
BTW, there are a lot more details to DFS than getting a pulse error from
the hardware... but I'll assume you know what has to happen at the
higher levels.
For the lower level stuff, feel free to send me any questions you have
for Atheros radar detection.
- M
Anyway IMO we shouldn't handle radar detection but simply pass it down
to the upper layers, in this case mac80211. It seems for DFS this
would mean to force to change channels and blacklist the channel for
30 minutes. If this interrupt *does* prove to be very noisy we can
simply disable the AR5K_RX_FILTER_RADARERR and even AR5K_RX_FILTER_PHYERR
later. Perhaps AR5K_RX_FILTER_RADARERR should be enabled during
configure_filter() through mac80211 to indicate when we do *need* DFS.
Right now AR5K_RX_FILTER_PHYERR is enabled when mac80211 tells us
about FIF_FCSFAIL | FIF_PLCPFAIL, we also keep the current
hw settings on AR5K_PHY_ERR_FIL (AR5K_PHY_ERR_FIL_RADAR,
AR5K_PHY_ERR_FIL_OFDM or AR5K_PHY_ERR_FIL_CCK).
Comments?
Luis
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
