Wash: How to Discover WPS-Enabled Routers Before You Test Them

Before you ever point Reaver or Bully at a target, you need to know two things: is WPS even enabled on this access point, and is it currently locked out from previous attempts? That’s exactly what Wash does, and it’s honestly a tool people skip past too quickly on their way to the “exciting” attack tools — even though skipping it is how you waste hours attacking a router that was never vulnerable to begin with.

Wash ships as part of the Reaver project, and I treat it as the mandatory first step of any WPS-focused assessment. This article covers what it does, how it reads WPS information elements from beacon frames, installation, full command syntax, and how I use it before every WPS test.

What Is Wash?

Wash is a WPS scanning utility bundled with the Reaver suite. It passively listens to 802.11 beacon and probe response frames and parses the WPS Information Element (IE) that WPS-capable access points broadcast. From that IE, Wash can tell you:

• Whether WPS is enabled at all.
• The WPS version in use (1.0 or 2.0).
• Whether the AP is currently locked (i.e., has triggered its own anti-brute-force lockout).
• The vendor/manufacturer, channel, and signal strength.

This lets you triage a whole list of nearby access points in seconds and immediately know which ones are even worth pointing Reaver or Bully at.

How It Works Internally

Every WPS-enabled AP includes a vendor-specific Information Element in its 802.11 beacon and probe response frames, defined by the Wi-Fi Alliance’s WPS specification. This IE contains structured TLV (type-length-value) fields describing WPS state, version, device name, and manufacturer.

Wash simply puts your adapter into monitor mode listening mode (it doesn’t need to inject anything — it’s fully passive) and parses these TLV fields out of every beacon it sees, presenting them in a clean table. Because it’s passive, running Wash carries essentially zero risk of disrupting a network — it’s pure reconnaissance.

Installation

Wash comes bundled with Reaver on Kali Linux:

sudo apt update
sudo apt install reaver -y

Confirm it’s available:

wash --help

Expected output:

Wash 1.6.6 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner

If it’s not bundled with your Reaver package, build from source:

git clone https://github.com/t6x/reaver-wps-fork-t6x.git
cd reaver-wps-fork-t6x/wash
./configure
make
sudo make install

Prerequisites

Your adapter must be in monitor mode:

sudo airmon-ng check kill
sudo airmon-ng start wlan0

Basic Usage and Syntax

sudo wash -i wlan0mon

Typical output:

Wash v1.6.6 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner

BSSID              Ch  dBm  WPS  Lck  Vendor    ESSID
-----------------------------------------------------------------------------
AA:BB:CC:DD:EE:FF   6  -42  1.0  No   Ralink    LabRouter
11:22:33:44:55:66  11  -61  2.0  Yes  Broadcom  NeighborNet
77:88:99:AA:BB:CC   1  -75  N/A  N/A  --        OldOfficeAP

Reading this table:

• WPS column shows the WPS spec version (1.0/2.0) if enabled, or N/A if WPS isn’t supported at all.
• Lck column shows Yes if the AP has entered a lockout state from repeated failed PIN attempts — meaning a Reaver/Bully attack would fail until it clears.
• Networks like OldOfficeAP above simply don’t support WPS and aren’t candidates for this attack class at all.

Scanning on a Specific Channel

To reduce scan time and focus on a known channel:

sudo wash -i wlan0mon -c 6

Writing Results to a File

sudo wash -i wlan0mon -o wash_results.txt

Scanning From an Existing Capture File

If you already have a .cap file from airodump-ng, Wash can parse WPS data from it directly instead of live-scanning:

wash -f capture-01.cap

This is particularly useful when you’ve already done a broad passive capture with Kismet or airodump-ng and don’t want to key up the radio again.

Real-World Use Cases (Authorized Testing Only)

1. Triage Before a WPS Assessment On every wireless engagement I run, Wash is the very first command after monitor mode is up. It tells me in seconds which in-scope APs even have WPS enabled, saving hours of pointless Reaver runs against networks that were never exposed to begin with.

2. Verifying Remediation After recommending a client disable WPS, I re-run Wash during a follow-up assessment to confirm the setting actually took effect and isn’t still broadcasting the WPS IE.

3. Lockout State Monitoring During an active Reaver/Bully test, I periodically re-run Wash in a separate terminal to check whether the target AP has entered a lockout state, so I know when to pause the attack rather than keep hammering a locked router pointlessly.

Workflow and Tool Integration

• Reaver / Bully — Wash is the recon step that feeds directly into these; use its BSSID/channel output as input.
• airodump-ng — for broader non-WPS-specific recon; Wash can also parse airodump-ng’s saved .cap files after the fact.
• Kismet — a long-running Kismet passive capture can later be fed into Wash for offline WPS analysis without needing a second live scan.

Performance Optimization

• Lock Wash to a single channel (-c) when you already know your target’s channel from a prior Kismet or airodump-ng scan — this avoids unnecessary hopping and speeds up detection.
• For offline analysis of large existing capture files, use -f instead of a live scan to save time and avoid re-keying the radio.

Troubleshooting

• No APs showing up at all: confirm your interface is genuinely in monitor mode (iwconfig) and that no other process (NetworkManager) has reclaimed it.
• WPS column always shows N/A for a router you know supports WPS: some routers only include the WPS IE in probe responses, not beacons — try triggering a probe request or wait longer for Wash to catch a probe response cycle.
• Inconsistent results between runs: signal strength and beacon timing can cause missed WPS IEs on weak signals; move closer or use a higher-gain antenna for testing.

Common Mistakes

• Skipping Wash entirely and jumping straight to Reaver, wasting time on routers with WPS disabled or already locked out.
• Misreading the “Lck” column and assuming a locked AP is simply un-attackable forever — most lockouts are temporary and clear after a set period.
• Running Wash on a live capture file expecting real-time results — remember -f mode is a static, one-time parse of whatever’s in that file.

Best Practices

• Always run Wash before any active WPS attack tool as standard practice.
• Re-check lockout status periodically during a long Reaver/Bully session rather than assuming the AP is still open.
• Save Wash output (-o) as part of your engagement documentation — it’s useful evidence of which devices were WPS-enabled during testing.

Practical Lab Example

1. Enable WPS on your own test router.
2. Put your adapter into monitor mode.
3. Run sudo wash -i wlan0mon and confirm your router appears with WPS: 1.0 or 2.0 and Lck: No.
4. Disable WPS on the router and re-run Wash — confirm it now shows N/A or disappears from WPS-capable listings.
5. Optionally, capture a .cap file with airodump-ng first, then run wash -f yourcapture.cap to confirm offline parsing works identically.

FAQ

Does Wash attack or attempt to crack anything? No. Wash is purely passive reconnaissance — it only reads beacon/probe information, it never sends attack traffic.

Is running Wash risky or detectable? Since it’s fully passive, it carries essentially no risk of disruption and is very difficult to detect, unlike active tools like Reaver.

Can Wash tell me the actual WPS PIN? No — it only reports whether WPS is enabled and its lockout state, not any credential material.

Why does an AP show WPS enabled but Reaver still fails? This usually means the AP has entered a lockout state, or the vendor’s WPS implementation has quirks that Reaver doesn’t handle well — check Wash’s Lck column and consider trying Bully instead.

Summary

Wash is a small, unglamorous tool that saves enormous amounts of time in any authorized WPS assessment. By passively reading the WPS Information Element out of beacon frames, it tells you exactly which access points are even worth testing and whether they’re currently locked — turning what could be hours of blind Reaver attempts into a focused, evidence-based test plan.

References

• GitHub repository (bundled with Reaver): https://github.com/t6x/reaver-wps-fork-t6x
• Man page: man wash
• Wi-Fi Alliance WPS specification overview: https://www.wi-fi.org/discover-wi-fi/wi-fi-protected-setup