Whether its a bug that a GET does NOT match the CLI… IDK. I suspect the CLI returns data it knows at time of the call. Since the new version available stuff requires a fetch, it’s not that odd it should use a POST to cause the remote connection (vs GET which is more to show config).
Perhaps better stated the GET /system/package/update will use a cache’d value form the last check-for-update, if none you’ll get nothing. If last time it check it was 7.13.x, that what it will show since it’s cached. Why you’re seeing variability in the versions. Basically you need to use the “check-for-updates” with POST.
I do not think it needs a parameters. But the content-type needs to be set to application/json. So the
--json ''
part does that. If using an older curl, it may not have the --json option. You can try:
-H 'Content-Type: application/json' -d ''
If that’s not it, post the curl command you’re using (with user:password and router IP obfuscated). Also if you’re using Windows…the env vars shown is not going to work — those work in WSL or Linux/Mac.
But at first I didn’t see the detail as I was using Comfortclick’s http driver to test it and it only said Internal server error… I needed to add policy=local,reboot,read,write,policy,test,api,rest-api policies too, then it worked.
I poked it until it worked for me. I gave the API user all group rights and then the command worked - Then I removed the policies one by one. So at the end I left only policy=local,reboot,read,write,policy,test,api,rest-api active. All other commands i’ve added before worked with just group policy=read,write,test,api,rest-api.
I thank you again Amm0 for making the RAML/OpenAPI scheme, it has been useful.