CWEng common mistakes
CWEng · Understand the traps and how to avoid them.
Treating dB, dBm, and dBi as interchangeable in link-budget math - e.g., writing '20 dBm + 3 dBi = 23 dBm EIRP' and then adding a 10 dB cable loss as '10 dBm', or halving a value by subtracting 3 dBm.
The exam reuses the same arithmetic all the way through RF, design, and troubleshooting items, and candidates memorize '3 dB = double' without anchoring it to the correct unit type; under time pressure the labels get dropped and the arithmetic silently goes wrong.
What to do instead
Drill the rule of 10s and 3s on a scratch sheet before the exam: only dB gains/losses add to dBm/dBi values, never to each other. Force yourself to write the unit on every number in a calculation and sanity-check the result (a path loss of 23 dBm is meaningless; it must be dB). Practice five quick conversions - mW↔dBm, EIRP from conducted power + gain - loss, and doubling/halving distance - until they take under 30 seconds each.
Assuming the higher-gain antenna or higher transmit power always produces a better link, and choosing it without evaluating noise floor, SNR, beamwidth, or regulatory EIRP limits.
Candidates conflate signal strength with link quality, and vendor data sheets emphasize gain. Higher gain narrows the vertical beamwidth and raises the noise the AP hears from unwanted directions, so SNR can stay flat or worsen while the RSSI number looks better.
What to do instead
Always evaluate a link as SNR (RSSI minus noise floor) plus a capacity/coverage trade-off, not RSSI alone. On any design question, check three things explicitly: the noise floor assumption, the resulting SNR against the modulation/data-rate requirement, and whether the proposed EIRP fits the regulatory domain and the AP's country-code limit. Learn the relationship between gain, beamwidth, and coverage shape so you can predict which scenario needs a wider or narrower pattern.
Applying a free-space path-loss slope of 6 dB per doubling of distance to an indoor office design, or conversely blaming 5 GHz's shorter range purely on 'higher path loss in free space.'
Textbook formulas are easier to recall than the multipath reality of indoor environments, and candidates don't separate the propagation exponent from the frequency-dependent terms, so the numbers chosen for coverage radius are wrong in one direction or the other.
What to do instead
Learn three distinct slopes and when each applies: free space (~6 dB per doubling), open office/partitioned office (~3–4 dB per doubling due to multipath), and dense/semi-open with obstructions. For frequency, be able to explain that the added 5 GHz attenuation in real buildings comes mainly from material absorption and reduced diffraction around obstacles plus narrower antenna apertures - and state the practical design consequence (more APs at lower power, not more power).
Declaring a site survey complete after producing a passive coverage heatmap, using the survey laptop's own adapter at full AP power, without validating throughput, capacity, or the uplink.
Predictive and passive surveys are fast and visually satisfying, and the tool defaults to the built-in adapter, which has better receive sensitivity than the actual clients (handhelds, IoT, voice badges) that will use the network. The resulting design passes the visual check and fails in production.
What to do instead
Define the survey scope up front by client type and application, then survey with a representative client adapter or a survey adapter calibrated to the weakest client. Always pair the passive walk with an active/throughput test per coverage area and a spectrum analysis pass, and record per-AP channel, width, and transmit power as 'as-built' documentation. Verify the design against a requirement table (RSSI, SNR, minimum data rate, number of spatial streams, secondary coverage overlap) rather than against the colour scale.
Designing for coverage only, choosing maximum channel width and maximum AP transmit power, and never computing airtime or client count per AP.
Coverage is the visible deliverable in survey tools, while airtime is invisible until the network is loaded. Wide channels (80/160 MHz) and high power feel like 'more performance' and also reduce the number of non-overlapping channels available, so the design collapses under density.
What to do instead
Do a capacity calculation before placing APs: expected clients per area, expected throughput per client, and the airtime each application consumes; then derive AP count and channel width from that budget. Favour 5 GHz/6 GHz for capacity, 20–40 MHz channels in high-density areas, and lower transmit power with more APs to shrink cells. On any design item, explicitly separate the coverage requirement from the capacity requirement and check both.
Treating an SSID as hidden or MAC filtering as an access-control measure, or assuming a configured 802.1X/WPA2-Enterprise SSID is secure once RADIUS authentication succeeds.
These settings appear in the same GUI as real security controls, and candidates conflate 'not broadcast' with 'not discoverable' and 'the client authenticated' with 'the client authenticated the network.'
What to do instead
Classify controls by what they actually do: SSID hiding and MAC filtering are obfuscation only (SSIDs appear in probe requests and associations; MACs are trivially spoofed). For enterprise SSIDs, verify the full chain - server certificate validation on the client (to prevent evil-twin/rogue RADIUS), the EAP method's inner identity handling, and whether the supplicant will fall back to a weaker method. Be able to state the specific attack each missing control enables.
Mixing up authentication and encryption, and mis-stating WPA3-specific behaviour - e.g., claiming SAE encrypts user data, that OWE requires a PSK, or that PMF is optional in WPA3.
WPA2 and WPA3 share vocabulary (PSK, 802.1X, EAP, CCMP) but change specific mechanisms, and exam items test the boundary. Candidates learn the marketing summary ('WPA3 is stronger') instead of which frame or handshake each mechanism protects.
What to do instead
Build a comparison table you can reproduce from memory: authentication (PSK/SAE, 802.1X/EAP, OWE), key management (4-way handshake, SAE's simultaneous authentication, PMF/802.11w protecting management frames), and encryption (CCMP-128, GCMP-256). Mark which are mandatory versus optional per certification (WPA3-Personal: SAE + PMF mandatory; OWE: no shared credential, unauthenticated encryption; WPA2: PMF optional/transition mode). When you see an option that credits an authentication method with confidentiality, eliminate it immediately.
Diagnosing retransmissions from a capture as interference without checking SNR, channel utilization, and whether the retries are on the uplink or downlink - or interpreting a single capture file as the whole story.
Retry counters are easy to read and interference is the most memorable cause, so it becomes the default explanation. Captures are also frequently taken on the wrong channel/width or with a monitor adapter that drops frames, and candidates reason from an incomplete trace.
What to do instead
Use a structured evidence set: channel utilization and noise floor from the AP and spectrum analyzer, per-client SNR and retry rate from the controller, and a monitor-mode capture verified for correct channel, width, and frame loss. Distinguish retries caused by low SNR (client at cell edge), by co-channel contention (high utilization, many clients), and by non-802.11 interference (energy in spectrum with no corresponding frames). Correlate the timestamp of the user complaint with the capture window before assigning a cause.
Attributing every slow-application complaint to the RF layer and skipping the wired path, DHCP, DNS, RADIUS, and WAN latency checks.
The candidate is being tested on wireless, so the instinct is to find a wireless cause; the troubleshooting clock runs and the actual bottleneck (slow RADIUS response delaying 802.1X, DHCP pool exhaustion, a congested uplink) is never examined.
What to do instead
Troubleshoot bottom-up through defined layers and document each: association and authentication timing in the capture (look at the gap between EAP-Success and the first data frame), DHCP request/offer latency, DNS resolution time, gateway and WAN round-trip, then RF metrics last. Learn the signature timings - a multi-second delay before the first data frame points to DHCP or RADIUS, not to SNR. Practise reading these events directly out of a frame capture rather than from a dashboard.
Confusing 802.11 frame classes and their behaviour in questions about reliability and QoS - e.g., assuming management frames are acknowledged the same way as data, that all data frames are individually ACKed, or that EDCA priorities guarantee bandwidth.
The MAC layer is taught as a list of frame types and access categories, so the causal chain (which frames get ACK/Block ACK, what triggers a retry, how EDCA contends) is memorized as labels rather than as behaviour, and scenario items expose the gap.
What to do instead
Map frames by function with their reliability rules: management (beacons, probe, auth, assoc - no ACK/retry in the data sense, hence the need for PMF), control (RTS/CTS, ACK, Block ACK/Block ACK Request), and data (aggregated A-MPDU/A-MSDU with Block ACK). For QoS, state that EDCA gives statistical access advantage via AIFS/contention window, not a bandwidth reservation, and know the four access categories and their typical mapping. Rehearse this by identifying frame types from a capture rather than from a diagram.