Meraki Wireless Dashboard API - Suddenly starts returning "400 Bad Request" after working for years

[mmsnyder]

A script I've had in production to change the PSK on a specific SSID weekly, and which has been working flawlessly week-in week-out for over 3 years, suddenly stopped working over the weekend, returning a "400: Bad Request" message, indicating some issue with the json or parameters. The script is powershell, using the Invoke-RestMethod cmdlet.

Has something changed in the ability to set a PSK on an SSID, or something in the API preventing my PUT statement from working any longer? Relevant code snippets below.

$randomkey = 'PSK'

$api_key = '************************************************'

function Put-GuestWiFiPSK {

$header = @{

"X-Cisco-Meraki-API-Key" = "$api_key"
"Content-Type" = 'application/json'

}

$api = @{

"endpoint" = 'https://n***.meraki.com/api/v0'

}

$psk = @{

"number" = "2"
"name" = "******** WiFi Network"
"splashPage" = "Click-through splash page"
"ssidAdminAccessible" = "False"
"authMode" = "psk"
"psk" = "$randomkey"
"encryptionMode" = "wpa"
"wpaEncryptionMode" = "WPA1 and WPA2"
"ipAssignmentMode" = "Bridge mode"
"defaultVlanId" = "421"
"walledGardenEnabled" = "False"
"minBitrate" = "1"
"bandSelection" = "Dual band operation"
"perClientBandwidthLimitUp" = "0"
"perClientBandwidthLimitDown" = "0"

}

$json = $psk | ConvertTo-Json

$api.url = '/organizations/********/networks/****************/ssids/2'

$uri = $api.endpoint + $api.url

$request = Invoke-RestMethod -Method PUT -Uri $uri -Headers $header -Body $json

return $request

}

[mmsnyder]

As an addition, I just did a try-catch and got more info back from the error. The specific error it's giving is: "{WPA encryption mode is incompatible with association type.}".

Again, this appeared from nowhere - nothing else has changed in the script or SSID/network configuration.

[SoCalRacer]

Try adding

"visible" = "true",
"availableOnAllAps" = "false",

[mmsnyder · Accepted solution]

Thanks so much for the reply, that's a great tip as per the documentation it does seem to want all parameters to be specified in the PUT. Unfortunately, specifying all the values, including the ones you mentioned, didn't solve the issue.

I did however strike upon a solution: I'd been specifying "wpaEncryptionMode = WPA1 and WPA2". This had always been in the script, never rejected or caused an issue. Removing it entirely allowed the script to finally run with the other parameters the same; encryptionMode = wpa, authmode = psk, etc. No matter what I changed wpaEncryptionMode to, it continued to fail until I just removed it entirely.