Policy required to re-"provision" CAPs.

I have a customer who wants to kill the guest network at certain times of the day. My script to disable the guest network does:

/caps-man provisioning set 0 slave-configurations=""
/caps-man remote-cap provision [find]

The only difference in the enable script is that it sets the slave-configurations=guest-cfg.

I would like to run the script with the minimum permissions required.

I’ve iterated through a few combinations, but am seeing inconsistent results. Sometimes, it seems the script, run by the scheduler, works with just policy=read,write. Other times it makes the change to the provisioning rule but does not re-provision the CAPs.

It always works if I run the script from /system script run on my ssh session. It doesn’t always work by clicking run script in winbox.

It seems to work if policy includes test, policy, or sensitive, singly or in combination with each other. I have always kept the read and write policies. I have matched the scheduler policy with the script policy.

Maybe it’s too late at night here and I’m doing something wrong and unable to see it. What policy, if any, should be required to run /caps-man remote-cap provision [find] from a scheduled script?

You could simply delete the CAP interfaces and later run the provision command, to re-create them

Or just disable them and re-enable them later when needed?

/cap interface disable [find where configuration=“guest-cfg”]
/cap interface enable [find where configuration=“guest-cfg”]

You can’t disable dynamic caps-interfaces, only remove them

Learned something new, thanks. Since we are using only action=create-enabled i didnt know about the restrictions for dynamic interfaces. But maybe lambert is using static interfaces already? Disabling and enabling works great for us, even within scripts :wink: