Wireless LAN and WLC Scenarios

The API call requires an authentication token that is missing or expired.

Why it fails: A missing or expired token yields 401 Unauthorized, not 400 Bad Request; the request would be rejected before payload validation. Token handling is the correct focus when the API returns authentication failures rather than syntax errors.

The MAC address format is incorrect (e.g., lowercase vs uppercase).

Why it fails: DNA Center accepts MAC addresses in multiple case formats, so casing alone does not trigger 400 Bad Request; the error indicates a missing or invalid required field. Format normalisation matters when integrating with APIs that enforce strict regex validation on identifiers.

The user making the API call does not have sufficient privileges.

Why it fails: Insufficient privileges return 401 Unauthorized or 403 Forbidden, not 400 Bad Request, which signals malformed request syntax or payload. Privilege checks are the right diagnosis when the API rejects valid JSON with an authorisation status code.

WEP

Why it fails: WEP's RC4 stream cipher with static, reusable keys is trivially cracked, so it cannot meet a 2023 enterprise standard. It tempts as the original 802.11 privacy mechanism, and would only be relevant for legacy hardware that cannot negotiate anything newer.

TKIP

Why it fails: TKIP was a firmware patch for WEP-era hardware, retaining RC4 and adding per-packet key mixing; it is deprecated and broken. It tempts because it shipped with WPA and improved on WEP, so it would suffice only for legacy devices lacking AES-capable radios.

WPA2

Why it fails: WPA2's AES-CCMP is strong, but WPA3, mandatory since 2020, adds SAE and forward secrecy, making it the 2023 enterprise recommendation. It tempts because WPA2 remains widely deployed and secure, and would be the answer for networks without WPA3-capable hardware.

Channel 3

Why it fails: Channel 3 overlaps channels 1 and 6 because each 2.4 GHz channel spans roughly 22 MHz while centre frequencies are only 5 MHz apart. Only 1, 6 and 11 are non-overlapping. Channel 3 would be chosen only where deliberate partial overlap with adjacent cells is acceptable.

Channel 12

Why it fails: Channel 12 overlaps channel 11 and sits outside the US regulatory range, so it is not a non-overlapping 2.4 GHz channel. Only 1, 6 and 11 avoid mutual overlap. Channel 12 is usable in regions permitting channels 12–13, where it may reduce interference from neighbouring 1/6/11 networks.

Channel 9

Why it fails: Channel 9 sits between channels 7 and 11, so its 22 MHz-wide signal overlaps both neighbours in the 2.4 GHz band. Only channels 1, 6 and 11 are conventionally non-overlapping there. Channel 9 would be usable where overlapping co-channel interference is tolerable, such as a single-AP home deployment.

The API key does not have permission to claim devices.

Why it fails: The stem states the API key has full organisation access, so a permission gap contradicts the given facts. Insufficient API key scope is a common cause of Meraki claim failures, and would be correct if the key were restricted to read-only or a single network.

The serial numbers contain a typo.

Why it fails: The stem states the serial numbers are correct and unused, so a typo contradicts the given facts. Checking serial transcription is a sensible first step when claims fail, and would be the cause if the values had been mistyped during data entry.

The devices are not Meraki MR or MS models.

Why it fails: The error text names serial validity or prior claim, and the stem confirms the devices are MR access points and MS switches. Verifying model compatibility is worthwhile when claiming mixed hardware, and would be the cause if unsupported device types were submitted.

Better range through walls

Why it fails: 5 GHz signals penetrate walls poorly, so range through obstacles is reduced. It is tempting because 5 GHz delivers higher throughput and less interference; better wall penetration belongs to 2.4 GHz, which the stem contrasts against.

Larger coverage area

Why it fails: Larger coverage area describes 2.4 GHz, not 5 GHz: lower frequencies attenuate less through walls and obstacles, so 2.4 GHz reaches further. The 5 GHz band's shorter wavelengths limit range but deliver higher throughput and far more non-overlapping channels, which is what reduces interference. Choosing 5 GHz for coverage would be backwards.

Higher compatibility with older devices

Why it fails: Older devices often support only 2.4 GHz, so 5 GHz reduces compatibility. It is tempting because 5 GHz is newer and faster; backward compatibility is a 2.4 GHz strength, the opposite of the advantage sought here.

Pagination is handled automatically by the client library; no action required

Why it fails: Not all clients handle pagination automatically; developers must implement it.

The 'page' query parameter is used to specify page number

Why it fails: Meraki does not use a page number; it uses cursor-based pagination.

The Link header contains a 'last' URL for the final page

Why it fails: The Link header typically includes 'next' and 'prev', not 'last'.

Re-run the same API call and ignore the 200 response

Why it fails: The 200 OK confirms the design-level POST succeeded, so repeating it cannot clear the failed provisioning state. Re-running is tempting because idempotent API retries fix transient errors, and that would be correct had the failure occurred during the API call itself rather than at provisioning.

Delete the SSID and recreate it with a different name

Why it fails: The name is not the cause; the design record already exists and provisioning failed on its own merits. Recreating is tempting because duplicate-name conflicts do block SSID creation, and that would be correct if the API had returned a conflict error rather than 200 OK.

Wait for the next scheduled provisioning cycle

Why it fails: Provisioning Failed is a terminal error state, not a pending queue item, so no scheduled cycle will retry it. Waiting is tempting because DNA Center does run periodic provisioning, and that would be correct if the SSID showed a pending or in-progress status instead.

Provide username and password in the Authorization header with Basic auth

Why it fails: Basic auth with username and password is not the Meraki Dashboard API's supported mechanism for automated requests; the API expects a per-user API key sent in the X-Cisco-Meraki-API-Key header. It is tempting because Basic auth is a familiar HTTP standard, but it is not how Meraki authenticates dashboard API calls.

Use OAuth2 client credentials grant and pass a bearer token

Why it fails: Meraki Dashboard API requests are authenticated with a per-user API key in the X-Cisco-Meraki-API-Key header, not an OAuth2 bearer token. It is tempting because OAuth2 client credentials is a standard machine-to-machine pattern, but Meraki's dashboard does not issue tokens through that grant.

Generate a JSON Web Token (JWT) signed with a shared secret

Why it fails: The Meraki Dashboard API does not accept self-signed JWTs with a shared secret; it authenticates requests using a per-user API key in the X-Cisco-Meraki-API-Key header. It is tempting because JWTs are common for stateless API auth elsewhere, but Meraki's dashboard does not implement that scheme.

The network ID is incorrect.

Why it fails: A wrong network ID returns HTTP 404 Not Found rather than 200 with an empty array, so the endpoint itself would fail before any SSID listing. It tempts because ID mistakes are common in Meraki API calls, and correcting the ID is right when the response indicates the network does not exist.

The API key is invalid.

Why it fails: An invalid API key returns HTTP 401 Unauthorized, not 200 with an empty array, so authentication cannot explain this response. It tempts because key problems are a frequent Meraki API issue, and rotating or regenerating keys is the right fix when calls are rejected outright.

The request body is malformed.

Why it fails: A GET request to list SSIDs carries no body, so a malformed body cannot cause an empty array; malformed bodies matter for POST/PUT payloads, where they trigger 400 errors. It tempts because request-body validation is a common API failure, but here the 200 status confirms the call itself succeeded.

PUT /dna/intent/api/v1/client-health

Why it fails: PUT is a write method; the Intent API exposes client health as a read-only resource, so PUT against client-health is rejected. It is tempting because the path itself is the correct client-health endpoint, and PUT is used elsewhere in DNA Center for updates, but retrieving a health score requires GET.

GET /api/v1/health

Why it fails: The path omits the required /dna/intent/api prefix and the client-health resource, so it does not resolve to the DNA Center Intent API. It is tempting because a short health endpoint looks plausible, but the correct call is GET /dna/intent/api/v1/client-health with query filters.

POST /dna/intent/api/v1/client-detail

Why it fails: POST to client-detail returns per-client detail rather than an aggregate health score, and POST is not the retrieval method for client health. It is tempting because client-detail sounds health-related, but the health score comes from GET /dna/intent/api/v1/client-health, not a detail lookup.

2.4 GHz

Why it fails: 802.11ac operates only in the 5 GHz band; 2.4 GHz is used by 802.11b/g/n and cannot deliver the wider channels and higher modulation that ac specifies. It is tempting because 2.4 GHz gives greater range, and it would be correct for a legacy 802.11n deployment prioritising coverage over throughput.

6 GHz

Why it fails: 6 GHz operation belongs to Wi-Fi 6E and 802.11ax, not 802.11ac, which has no channels defined in that band. It is tempting because 6 GHz offers cleaner spectrum and wider channels, and it would be correct for a Wi-Fi 6E deployment seeking additional capacity.

Both 2.4 GHz and 5 GHz

Why it fails: 802.11ac operates only in the 5 GHz band; 2.4 GHz support belongs to 802.11n and earlier, so claiming both bands misstates the standard's channel plan. The dual-band answer tempts because most 802.11ac clients are dual-band radios, but the amendment itself defines 5 GHz VHT operation exclusively.

POST

Why it fails: POST creates a new resource; Meraki's SSID update endpoint expects PUT to replace the existing SSID configuration. POST is tempting because it does submit data in the request body, and would be correct when creating a new SSID or invoking action endpoints that are not idempotent.

DELETE

Why it fails: DELETE removes the target resource rather than modifying its settings, so it cannot update SSID parameters. It is tempting because it is a write method that changes server state, and would be correct when decommissioning an SSID or removing an object from the Meraki dashboard.

GET

Why it fails: GET is a safe, read-only method that retrieves the current SSID configuration without altering it. It is tempting because you must first read the SSID to know its current values, and would be correct for that retrieval step before issuing the modifying request.