vSZ - command "set scg ip" not allowed in AP script
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2019 01:56 AM
Hi all,
we need to change IP address of our vSZ-H, which is hosted on our own public cloud infrastructure.
Though we are pretty confident that we did it well in the past, declaring FQDN instead of IP address in "set scg ip" command, we want to make sure that all of our APs are correctly configured before going live with new IP address.
APs are distributed over many customers, thus DHCP 43 is not an option.
We would like to push an AP script command, as suggested in the following KB article: https://support.ruckuswireless.com/articles/000004979
Also, as per this article, "any AP CLI command will be accepted" into the AP script.
However, when we upload the script, we get the following error: "command[set scg ip] is not allowed in AP CLI Script file."
Script is very simple, as following:
we need to change IP address of our vSZ-H, which is hosted on our own public cloud infrastructure.
Though we are pretty confident that we did it well in the past, declaring FQDN instead of IP address in "set scg ip" command, we want to make sure that all of our APs are correctly configured before going live with new IP address.
APs are distributed over many customers, thus DHCP 43 is not an option.
We would like to push an AP script command, as suggested in the following KB article: https://support.ruckuswireless.com/articles/000004979
Also, as per this article, "any AP CLI command will be accepted" into the AP script.
However, when we upload the script, we get the following error: "command[set scg ip] is not allowed in AP CLI Script file."
Script is very simple, as following:
#define AP FW versionAny clue on how to upgrade scg ip remotely (with no easy SSH access)?
fw_version=5.1.0.0.595 #define Model class model=all # Command set scg ip FQDN
11 REPLIES 11
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2019 02:38 AM
Hi Marco,
As far as I know that has not been changed.
Please raise a case via the support portal to have a support engineer look at it.
Regards
Martin
As far as I know that has not been changed.
Please raise a case via the support portal to have a support engineer look at it.
Regards
Martin
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2019 04:26 AM
Starting from SZ OS 5.1.0.0.268, the following commands are excluded in the AP CLI Script feature in order to protect the integrity and stability of the system.
AP CLI Command Blacklist
--tony
AP CLI Command Blacklist
- reboot
- set factory
- set scg reset
- set scg init
- set scg ip
- set scg disable/enable
- set hub disable/enable
- set interface
- set password
- set login
--tony
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2019 11:31 AM
Try using a real FQDN (!)
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2019 12:59 PM
Marco,
While not pretty, you could in theory do this from the CLI of the SZ. Something like the following should work.
remote ap-cli "set scg ip IP/FQDN"
remote ap-cli "set scg ip IP/FQDN"
There's a bit of a delay between inputting one command and a return of "OK", so using something like AutoHotkey to add your own delay in automating this could help you accomplish what you're trying to do.
Likewise you could change the set to get and verify they are all configured as you desire. The delay between the response(s) will be the pain point I imagine.
While not pretty, you could in theory do this from the CLI of the SZ. Something like the following should work.
remote ap-cli
remote ap-cli
There's a bit of a delay between inputting one command and a return of "OK", so using something like AutoHotkey to add your own delay in automating this could help you accomplish what you're trying to do.
Likewise you could change the set to get and verify they are all configured as you desire. The delay between the response(s) will be the pain point I imagine.

