Difference between revisions of "RADAR"

Revision as of 12:03, 26 January 2012

DFS with ath5k

• With a view to Dynamic Frequency Selection powered by RADAR PHY errors reported to the driver.

Visualisation of RADAR activity

Visualisation app

1. Patched ath5k driver reports PHY error details to userspace via debugfs.
2. Python daemon on Linux collects details, sweeps frequency ranges on-demand, and reports details to any connected client over the network.
3. .NET GUI visualises legitimate WiFi packets and RADAR errors over frequency/time, plots histograms of pulse width, RSSI distribution, time between pulses, and draws time-series graphic to help uncover repetition rate within a sample of pulses.

Files

ath5k Linux kernel driver patch

• compat-wireless-2011-10-11.radar-h4x.patch.bz2

This is a diff against compat-wireless-2011-10-11. I had to apply some additional patches/fixes to enable it to compile against my existing kernel (2.6.26 x86):

• 022-atomic64_backport.patch is in the root directory in case you need it too (but is not applied by my driver patch).

My config.mk:

diff compat-wireless-2011-10-11.orig/config.mk compat-wireless-2011-10-11/config.mk
224c224
< # CONFIG_ATH5K_DEBUG=y
---
> CONFIG_ATH5K_DEBUG=y
615c615
< # CONFIG_ATH_DEBUG=y
---
> CONFIG_ATH_DEBUG=y

NOTE: Debug mode is necessary for the information to be passed to userland via debugfs!

Also add to fstab:

none            /sys/kernel/debug debugfs

And make sure debugfs is enabled in your kernel!

Python

Two types:

1. TCP server for GUI
2. Stand-alone for console

They have plenty of command-line arguments, so remember to check them with '-h'.

Both scripts rely on knowning how to decode the RADAR error struct passed down from the kernel. If this is different for you from the default, make sure you update these scripts!

The RADAR queue length must match the driver's one (2048 by default, can be change as command-line argument).

And

struct ath5k_radar_error {
	u32 tsf;
	u8 rssi;
	u8 width;
	u8 type;
	u8 subtype;
};

must match:

sizeof_radar_error = 4+1+1+1+1

and

item = struct.unpack("Icccc"...

(and also the way it is used by the radar_error class).

Server

• radar_server.py.bz2

Operates by default on port 5256.

All frequencies are in MHz (e.g. 5500). Sweep range can go backwards.

Simple plain-text line-based protocol:

FREQ <freq>

Thresholds (as in driver, see patch for details):

FIRPWR <pwr>
RSSI <rssi>
PHEIGHT <height>
PRSSI <rssi>
INBAND <threshold>

START [start freq: 4920:] [end freq: 6100] [freq step: 5] [sampling interval in seconds, can be floating point: 1]
STOP

To continually scan one frequency, use same start and end frequency.

To terminate (will stop active sweep):

QUIT or EXIT

or just disconnect.

Details are sent back as:

DATA <freq> <Base64 encoded list of RADAR error structs>

Stand-alone console

radar.py.bz2

Output

Monitoring RADAR detection in the console

Type:

watch -n 1 "cat /sys/kernel/debug/ieee80211/phy0/ath5k/radar"

to get:

Every 1.0s: cat /sys/kernel/debug/ieee80211/phy0/ath/radar

RADAR detection enabled:        1
RADAR PHY error filter:         0

Filter output power threshold:  44 (44)
Pulse height threshold:         28

RADAR RSSI threshold:           15
Pulse RSSI threshold:           58

In-band threshold:              9

RADAR error queue usage:        0/2048 (start: 0, overflows: 0)

RADAR errors:   0
PHY errors:     0
Other errors:   0
Frames:         0

Width:
0:              0
1-50:           0
51-100:         0
101-150:        0
151-200:        0
201-250:        0
251-254:        0
255:            0

Manually setting RADAR detection parameters

For example (adjust depending on your interface index):

echo "firpwr -60" > /sys/kernel/debug/ieee80211/phy0/ath5k/radar
echo "rssi 1" > /sys/kernel/debug/ieee80211/phy0/ath5k/radar
echo "pheight 1" > /sys/kernel/debug/ieee80211/phy0/ath5k/radar
echo "prssi 1" > /sys/kernel/debug/ieee80211/phy0/ath5k/radar
echo "inband 31" > /sys/kernel/debug/ieee80211/phy0/ath5k/radar

Spectrum Sweep

20MHz channel width

• Notice how RADAR errors are reported either side of a legitimate WiFi channel:

Counts vs. Frequency

RSSI vs. Frequency

10MHz channel width

• No WiFi operating at this channel width:

Counts vs. Time

RSSI vs. Frequency

5MHz channel width

• Some WiFi operating at this narrow channel width:

Counts vs. Frequency

RSSI vs. Frequency

Kurnell Weather RADAR

• Registered as a Bureau of Meteorology Weather RADAR: http://www-cluster.bom.gov.au/inside/oeb/radar/sydney.shtml

• Registered on RFMap:
  • 5.625 GHz (1.1 MHz bandwidth at 250 kW)

Photo taken from the air while flying down Victor One

• Following data was received on ~5500/~5600 MHz

• One can infer the rotation rate of the RADAR by examining the difference in time, especially in the 'Counts' (number of reported RADAR PHY errors) over time:

Counts vs. Time

• Average RSSI decreases a little in each 'transmission section' (separated by the pause in-between), however decrease is most noticable in the maximum value per sample-group:

RSSI vs. Time

• Not sure why the distribution of widths changes later (was this when my laptop was knocked off its perch by the wind?!):

Pulse width vs. Time

• Whatever the change above, it is also reflected here:

Time between pulses vs. Time

• 1kHz PRF
  • You can see that the five highest bins (which hold counts for the distinct times between detected RADAR pulses) have values of ~1000. The time-series plot shows the regular repetition:

Time-series plot of pulses

• 5kHz PRF
  • As above, however this time it's ~5000:

Time-series plot of pulses

• This is also reflected in the time-between-pulses histogram:

Histogram of time between pulses

ISM

• Indoors, the sweep looks quite different:
  • Notice the significant response at 5800MHz. Could this be DECT nearby?

RSSI vs. Frequency

• Examing the time-series plot of RSSI for 5800MHz clearly shows a regular, repeating group of pulses (not as apparent due to the colouring on the width plot as the pulse widths seem to be changing moreso, however the time-between pulses is identical):

Time-series plot of pulses

5140MHz

• No idea what this is, however it appears rather regular (also note the regular pauses between groups of RADAR errors):

Counts vs. Time

RSSI vs. Time

Pulse width vs. Time