HCIP-WLAN common mistakes
HCIP-WLAN · Understand the traps and how to avoid them.
Treating CAPWAP control and data as a single tunnel with one port, and assuming the AP sends data traffic to the AC by default, so questions about split-tunnel forwarding, port numbers, and where the data path terminates are answered incorrectly.
Candidates memorize 'CAPWAP = 5246/5247' without separating the control channel (UDP 5246, DTLS-encrypted when enabled) from the data channel (UDP 5247) and without internalizing that Huawei APs default to direct forwarding (local forwarding), where service traffic exits the AP's own uplink rather than traversing the AC. The two-layer model and the forwarding-mode decision are usually glossed over in quick revision.
What to do instead
Draw the full onboarding sequence once: AP discovers AC (DHCP option 43, DNS, broadcast, static) → CAPWAP Discovery Request/Response → DTLS handshake (if configured) → Join Request/Response → Configuration Update → Data Channel establishment. Annotate each step with its transport and port, then mark on the diagram where user traffic flows for tunnel forwarding versus direct forwarding. Practise predicting, for a given SSID and VLAN design, whether the AP or the AC is the gateway-facing node and which device the client's DHCP request reaches.
Answering roaming questions by naming 802.11r as the universal fix, without distinguishing which standard solves discovery latency (802.11k), which solves pre-authentication/reassociation (802.11r), and which solves BSS transition steering (802.11v), or which combinations Huawei APs actually support.
The three amendments are learned as a bundle ('k/v/r = fast roaming') and never separated by function, so candidates cannot match a described symptom (long scan before roam, slow rekey at reassociation, sticky client) to the correct mechanism. They also miss that 802.11r requires a mobility domain and key hierarchy, so it helps only within one mobility domain.
What to do instead
Build a three-row table: 802.11k = neighbour reports and beacon measurement, shortens scanning; 802.11v = BSS Transition Management frames, lets the infrastructure suggest a target AP; 802.11r = Fast BSS Transition with PMK-R0/R1 key hierarchy, removes 802.1X reauthentication at reassociation. For each, write the symptom it fixes and its precondition (same mobility domain for 11r, client support, AC configuration). Then work scenario questions by first identifying the symptom, then selecting the mechanism.
Choosing WPA3-Enterprise or WPA2-Enterprise as the answer whenever 'security' appears, even when the scenario describes a guest network, a headless device, or a captive portal flow where Portal or MAC authentication is the correct mechanism.
Enterprise-grade 802.1X feels like the 'most secure' answer, so candidates default to it and ignore the deployment constraints in the stem: no supplicant on the client, no certificate infrastructure, a requirement for a web login page, or devices that cannot do EAP. Portal and MAC authentication are treated as legacy rather than as distinct, legitimate access-control methods.
What to do instead
Map each authentication method to its prerequisites: 802.1X needs a supplicant and a RADIUS server (and certificates for EAP-TLS/PEAP server validation); Portal needs a redirect and a portal server, works with any browser, and is common for guests; MAC authentication needs a device MAC database and suits printers and IoT. When reading a scenario, underline the constraint words (guest, no client software, temporary access, IoT) before selecting a method, and check whether the question asks for authentication, authorization, or both.
Confusing VRRP hot standby with dual-link backup and AC virtualization, so questions about which AC carries traffic after a failure, whether the backup AC is active, and how APs are distributed are answered with the wrong architecture.
All three are described as 'AC redundancy' in summaries, and candidates memorize the names without the traffic model: VRRP hot standby (one master AC active, backup idle, APs re-establish CAPWAP after failover), dual-link backup (AP maintains links to two ACs, faster switchover), and AC virtualization (multiple ACs presented as one logical AC with APs distributed across members). The differences in failover time and resource utilization are the actual exam points.
What to do instead
For each architecture, write four facts: how many ACs forward traffic in steady state, how the AP learns about the backup, what triggers switchover, and the approximate interruption. Then draw the topology for each and mark which link carries CAPWAP control and which carries data. Compare them side by side in one table so the trade-off (resource efficiency versus failover speed) becomes the retrieval cue rather than the name.
Treating WMM as a single on/off setting and being unable to map 802.11 user priorities to access categories (AC_VO, AC_VI, AC_BE, AC_BK), or explain how WMM interacts with CAPWAP QoS mapping and DSCP marking end to end.
WMM is studied as a checkbox in the SSID profile, so the four access categories, their EDCA parameter differences (arbitrary inter-frame space, contention window), and the mapping from 802.1p/DSCP to WMM AC are never learned. Candidates then cannot answer questions about voice quality degradation when WMM is disabled or when the CAPWAP tunnel strips priority.
What to do instead
Memorize the four access categories with their typical traffic (voice, video, best effort, background) and the ordering of contention priority. Then trace one voice packet from the wired side to the client: DSCP marking on the switch → CAPWAP QoS mapping on the AC/AP → 802.11 user priority → WMM access category → EDCA contention. Draw this chain once; most WMM questions are answered by locating where in the chain the described fault occurs.
Answering channel and power planning questions with 'use 1, 6, 11 and maximum power' regardless of band, channel width, or AP density, and ignoring co-channel interference versus adjacent-channel interference.
The 2.4 GHz non-overlapping channel set is learned as a slogan and then applied to 5 GHz scenarios, high-density halls, or 80 MHz deployments where it is wrong. Candidates also conflate co-channel interference (same channel, managed by power and density) with adjacent-channel interference (overlapping spectrum, managed by channel selection), and forget that wider channels reduce the number of non-overlapping channels.
What to do instead
Separate the bands explicitly: 2.4 GHz uses 20 MHz with the 1/6/11 pattern; 5 GHz has many non-overlapping channels and supports 40/80 MHz but the wider the channel the fewer available. For each interference type, state the cause and the mitigation (co-channel: lower power, add APs, adjust density; adjacent: choose non-overlapping channels, avoid 40 MHz in dense 2.4 GHz). Practise with a stated AP count and band, and compute how many channels remain at each width before choosing.
Reading a troubleshooting scenario and immediately naming a configuration fix without first establishing which layer is failing, so questions describing an AP that never joins the AC are answered with radio or roaming fixes.
Candidates pattern-match on keywords ('AP offline', 'client cannot connect') without walking the layered path: physical/link, IP reachability, DHCP and option 43, CAPWAP discovery, DTLS, join, configuration, then radio. Because the fault domains overlap, the first plausible-sounding cause is chosen instead of the one consistent with the evidence given.
What to do instead
Adopt a fixed diagnostic order and apply it to every scenario: is the AP powered and linked? Does it obtain an IP? Can it reach the AC address? Is discovery configured (option 43/DNS/static)? Does the CAPWAP join complete? Then check licence, configuration, and radio. Use the evidence in the stem (AP shows an IP but never appears on the AC, AP appears but clients fail) to eliminate layers before selecting an answer, and state the eliminated layers in your reasoning.
Mixing up 802.11 management, control, and data frame types and their subtypes, and being unable to say which frames are sent before association (beacon, probe request/response, authentication, association request/response) versus after (data, QoS data, block ack, action frames).
Frame types are memorized as a list rather than as a sequence, so candidates cannot place a frame in the association timeline or recognize that 802.11k/v/r mechanisms ride on action frames. Questions that describe a capture or a failure at a specific stage then become guesswork.
What to do instead
Write the association timeline in order and label each frame type and subtype at each step: beacon/probe → authentication → association → 4-way handshake (EAPoL) → data. Add a separate branch for action frames used by radio measurement (11k), BSS transition (11v), and FT (11r). When a question cites a frame name, locate it on this timeline before answering; the position usually determines the correct diagnosis.
Assuming 802.11ax/802.11ac features such as MU-MIMO, OFDMA, or higher-order modulation apply uniformly to all clients and bands, and answering PHY questions without checking the band, channel width, and spatial stream assumptions in the stem.
Generation names are learned as marketing labels ('Wi-Fi 6 is faster') without the conditions: OFDMA and MU-MIMO require AP and client support and favourable SNR; 160 MHz channels exist only in 5/6 GHz; higher MCS requires higher SNR and more spatial streams. Candidates then pick the theoretical peak rate for a scenario where the stated conditions do not permit it.
What to do instead
For each PHY generation, record the band, maximum channel width, modulation, and the conditions for its headline features. When a rate or feature question appears, extract the stated band, width, stream count, and SNR first, then eliminate options that violate those constraints. Practise estimating relative throughput from MCS, width, and streams rather than recalling a single peak number.
Treating PKI and certificates as a single 'install a certificate' step, without distinguishing the CA, the server certificate on the RADIUS/portal server, and the client certificate, or knowing which EAP methods require which certificates and what validation failure looks like.
Certificate topics are skipped as 'not really WLAN', so candidates cannot say that PEAP/EAP-TTLS validate the server certificate while EAP-TLS requires client certificates too, or that an expired or untrusted CA chain causes authentication failures that look like credential errors. This also undermines answers on Portal HTTPS and AC management-plane security.
What to do instead
Draw the PKI chain: root CA → intermediate (if any) → server certificate on RADIUS/portal, and separately the client certificate for EAP-TLS. For each EAP method, note whether server certificate validation is mandatory and whether a client certificate is needed. Then list the common failure signatures (expired certificate, hostname mismatch, untrusted CA, missing client cert) and the log evidence each produces, so certificate questions are answered from the chain rather than from memory of a single step.