I’m working on a small management panel that upgrades/downgrades mikrotik devices via their api (and does other fancy things too haha).
This consists of fetching the requested mikrotik release and then
using /system package downgrade if it is a downgrade
using /system reboot if it is a normal upgrade.
The fetching part goes fine (variables have been safely escaped, no worries there):
Rebooting however does work if I use a new client (I destroy the current one, create a new one, and then reboot the device in a new connection.
I did not test this with /system/package/downgrade yet, but I believe creating a new connection is not a good way to go
Anyone who can help me out here?
Thanks in advance!
Yentel
AFAIK, a downgrade implicitly causes a reboot… Which means the API connection is closed. However, there’s no indication to the client that the connection is being closed, which is why any command you would do after that would error. This API client in particular also sends a “/quit” command on connection close, which means that even if you don’t send anything, but still continue to have the instance, it would eventually error.
You have two options:
Don’t do a reboot, but just immediatly close the connection after the downgrade command (to avoid errors later down), sleep for a second (to let the shutdown sequence commence), and renew it (which would make it wait until the reboot is done and the router is ready to accept connections again). You said you’re sort of doing that already… But my point is the second reboot should not be necesarry.
Instead of doing commands like downgrad and reboot directly, add a scheduler script that does them. Make the scheduler script remove itself before anything else, and schedule it to run shortly after your PHP script is over. Assuming a reboot of the router is the last thing you’re doing in your script, using interval=1s should be sufficient delay.