Troubleshooting
What to check when a device does not answer, a feature will not let you press it, or a result makes no sense.
A device will not connect#
Work through these in order — the first two account for most cases.
- Is that service switched on at the device? Each kind of connection needs its own service reachable:
WinBox on 8291, the API service for API, /ip service ssh for SSH, and /ip service www or www-ssl for REST.
- Is the account right, and can it actually log in? Try the same credentials directly in WinBox or over
SSH. An account that works over one kind of connection is not guaranteed to work over another if the permissions on the RouterOS side differ.
- Is something in between? Firewalls, VPN routing, and the device's own source-address restrictions all
count.
- Is it being given long enough? A device over a slow or congested path may simply need more than the
per-device timeout allows.
- Try another kind of connection. If 8291 fails but SSH works, the problem is the path or the service,
not the credentials.
A MAC address connection will not work#
Connecting by MAC address exists only over the connection WinBox uses (8291), and needs two things at once:
- You are on the same network segment as the device. This kind of connection does not go through a router,
so across segments it will never work.
- The device allows it on that interface.
API, SSH and REST always need an IP address or a host name — a MAC address will never work there.
A feature is greyed out or will not let me press it#
Most "missing" features are restrictions of the kind of connection, and they are deliberate:
| Symptom | Cause |
|---|---|
| Port monitoring unavailable | It works over the connection WinBox uses (8291) only. |
| Cannot run commands over API or REST | Running commands over those is RouterOS 7.x only. |
| REST not offered at all | RouterOS 6.x has no REST, and it needs /ip service www or www-ssl. |
| Power cycle button unavailable | Needs hardware that can supply power over the cable, an account with write permission, and Allow changes ticked first. |
A health check item says "could not check"#
"Could not check" is not a pass — it means that data could not be read. Usual causes:
- This kind of connection cannot see it. Only the connection WinBox uses reads all 31; API, SSH and REST
give access to less. The application warns about this before the run starts.
- The account lacks permission for the section that item reads.
- One of the two reach-out checks was blocked. Those two are off by default anyway. If a device cannot get
out, "could not check" is the expected result, not a fault.
Re-run over the connection WinBox uses, with an account that can read the relevant sections, and the gaps usually close.
A run ended as "uncertain"#
This means the commands were sent and then the connection dropped, or you cancelled after sending. The outcome is genuinely unknown, and the application does not re-send on its own.
What to do:
- Read the state back. Run the matching query command as a second round against the same devices and look
at the output. That is the only way to know what actually landed.
- Only then re-run the change, and only if the read-back shows it did not apply.
Blind retries are how one change becomes two. That is exactly why the status says "uncertain" instead of picking a comforting answer.
It says "Completed" but nothing changed#
"Completed" means the device reached the end of your commands — not that every line succeeded. RouterOS does not report success or failure line by line.
Look at that device's output text in the results panel: RouterOS error messages usually turn up there. Then read the state back with a query command.
I cancelled but the device did not stop#
Over API, SSH and REST, cancelling only stops this end *waiting*. It cannot promise the command stopped at the device — the device may well finish what it was already given. Over the connection WinBox uses (8291), cancelling stops that connection.
Either way, treat cancelled-after-send as uncertain and read the state back.
Windows warns when I launch it#
The builds checked so far carry no Windows digital signature, so SmartScreen is likely to warn on first run. That is expected at present, and it is stated on the download status page.
Only obtain RosRunner through official channels. If you find a download claiming to be signed or verified, tell us.
Preparing a support request#
The diagnostics window assembles a report package on your own machine and lists item by item what is in it. It does not send anything anywhere — attaching it to an email is a separate, deliberate act.
Include the RosRunner version (Help → About RosRunner), your Windows version, the RouterOS version on the device, which kind of connection you used, what you did and what happened.
See Support for what else to include.