CWNA common mistakes
CWNA · Understand the traps and how to avoid them.
Adds or subtracts dBm values arithmetically (e.g., treating 20 dBm + 3 dBm as 23 dBm of total radiated power) and converts dBm to mW by simple proportion instead of using the logarithmic rules.
The 10s and 3s rules are memorized as trivia rather than internalized, and under time pressure candidates fall back on linear arithmetic that feels intuitive.
What to do instead
Drill until automatic: +3 dB = 2x power, +10 dB = 10x power, +6 dB = 4x. Rule to write on scratch paper: never add two dBm figures; convert both to mW, add the mW, then convert back. Work 20 timed conversion problems covering 0, 3, 6, 10, 13, 20, 23, 30 dBm.
Recommends a high-gain antenna to 'boost' signal in a small or odd-shaped area without sketching the resulting beamwidth, and uses dBd and dBi interchangeably in link-budget math.
Gain is mentally modeled as an amplifier that makes the signal stronger everywhere, and the two gain references look like the same unit on a data sheet.
What to do instead
Before choosing an antenna, draw both the azimuth and elevation patterns on the floor plan and mark where the narrower beam leaves coverage holes or nulls. Memorize dBd = dBi - 2.15 and always normalize a data sheet to one reference before comparing products.
Assumes any PoE switch port will power any access point, and sizes switch power budgets without accounting for PoE class, cable length losses, or the difference between 802.3af, 802.3at, and 802.3bt.
PoE is treated as a checkbox ('the switch does PoE') rather than a per-port power and heat budget, and vendor marketing blurs the class boundaries.
What to do instead
For every AP model, look up its actual maximum draw, map it to the correct PoE class, then compute total budget = per-port allocation x port count plus cable loss on long runs. Keep a one-page table of the three PoE types with their wattage at the PSE and at the PD.
Derives AP count from square footage and a coverage radius alone, then presents a design with no capacity calculation, no channel reuse plan, and no statement of target client device types.
Coverage is easy to visualize and capacity is abstract; candidates reproduce the 'one AP per X square feet' shortcut instead of separating coverage design from capacity design.
What to do instead
Produce two independent numbers: APs for coverage (from the RF budget and attenuation survey) and APs for capacity (from expected concurrent clients, device mix, and per-client airtime). Use the larger figure, then assign a non-overlapping channel plan (1/6/11 in 2.4 GHz; a documented 5 GHz reuse pattern) and state the assumed client mix.
Attributes responsibilities to the wrong organization - crediting the IEEE with Wi-Fi certification or the Wi-Fi Alliance with writing 802.11 amendments - and misstates amendment-to-generation mappings such as which amendment corresponds to Wi-Fi 6.
The two bodies are learned together as a pair, and amendment numbers are memorized without a structure tying them to a generation name or a defining feature.
What to do instead
Build a two-column mapping table and rewrite it from memory weekly: IEEE writes the 802.11 amendments; the Wi-Fi Alliance certifies products and owns the generation names (802.11n = Wi-Fi 4, 802.11ac = Wi-Fi 5, 802.11ax = Wi-Fi 6/6E, 802.11be = Wi-Fi 7). For each amendment, add one defining feature (e.g., ax = OFDMA, ac = 5 GHz only, n = MIMO).
Uses SSID, BSSID, and ESS interchangeably - for example stating that the BSSID changes when a client roams between APs in the same network, or that the SSID uniquely identifies a single radio.
All three appear in the same association and roaming discussions, so they get collapsed into 'the network name' unless the candidate has actively separated them.
What to do instead
Write the definitions in one sentence each and apply them to a concrete roaming scenario: SSID = logical network name; BSSID = MAC of an individual radio (changes on roam); BSS = one AP plus its clients; ESS = multiple BSSs joined by a distribution system. Verify the SSID/BSSID distinction by looking at a real scan output.
Presents SSID hiding, MAC address filtering, or WEP as effective security controls, and confuses WPA2-Personal (PSK) with WPA2-Enterprise (802.1X/EAP), often placing 802.1X authentication on the wrong side of the 4-way handshake.
Older study habits and legacy 'best practice' advice persist, and the handshake sequence is memorized as a list rather than as an authentication-then-key-derivation flow.
What to do instead
For each control, state the specific attack that defeats it (SSID hiding: probe response/beacon analysis; MAC filtering: MAC spoofing; WEP: IV weakness). Draw the WPA2-Enterprise flow end to end - 802.1X/EAP authentication first, then the 4-way handshake deriving the PTK - and label where the PMK, PTK, and GTK appear.
Jumps straight to RF-layer remedies (replacing APs, changing channels, adding an antenna) when a user reports poor performance, without first confirming association state, IP configuration, DHCP, and whether the problem is isolated to one client.
RF is the most familiar and most dramatic explanation, and the exam's RF-heavy weighting encourages seeing every symptom as a signal problem.
What to do instead
Adopt and rehearse a documented layered sequence: physical/link (associated? RSSI/SNR?) - layer 2 (VLAN, authentication, retries) - layer 3 (DHCP lease, gateway, DNS) - application. Practise by writing the first five diagnostic steps for a single 'slow Wi-Fi' ticket before naming any RF fix.
Runs a validation survey with a laptop's built-in adapter rather than a representative client device, at standing height only, in an empty building, and treats the resulting heat map as proof the design meets requirements.
The built-in adapter is the tool at hand, and the survey is treated as a measurement exercise rather than a model of real client behaviour including asymmetric transmit power.
What to do instead
Match the survey radio and antenna to the weakest expected client, survey with the building furnished and populated where possible, take readings at seated and standing heights, and explicitly record uplink as well as downlink since client transmit power is typically the limiting factor. State the requirement threshold the survey is being validated against.
Uses 40, 80, or 160 MHz channels by default throughout a design and ignores that each doubling of channel width raises the noise floor by 3 dB and halves the number of available non-overlapping channels.
Wider channels are marketed as faster and the throughput number on the data sheet is quoted at the widest width, so width is chosen for peak rate rather than for reuse in a multi-AP environment.
What to do instead
Tie channel width to the band and the reuse requirement: 20 MHz in 2.4 GHz, and in 5 GHz reserve wide channels for high-density-isolated or low-AP-count areas. For each design, count the non-overlapping channels available at the chosen width before committing, and state the resulting noise-floor change.