I am also using http://wiki.mikrotik.com/wiki/API_PHP_class . it worked good but after some hours API returned cannot get challenge and then script could not connect to API anymore .
Another strange thing is , i have seen a lot of sessions in “/user active print” . there are more than 44500 sessions there from user which i used for API connection but i have used $API->disconnect () .
RouterOS v4.7
You aren’t following that example literally, are you? It does a login, one command, then logs out. You can log in once, do as many commands as you need to do, then disconnect (logout) once when you are finished for the session.
Maybe a “/quit” command sent just before the disconnect might drop the user from the active list.
The script runs each time the specific page hits by a user so it should login , execute the command and then logout . the only way is a persistent connection with something like CURL or pfsockopen which needs customization of API_PHP_Class .
I have also test with mikrotik official python api client . it has same problem and does not clear the admin from “/user active print” .
even after sending /quit . with /quit it successfully closes the connection and raises “connection closed by remote end” but the admin is still remains alive at “/user active print” .
The /user active list is directly tied to /ip firewall connection table for that service (from what I’ve found).
There are still connections in the connection table connecting to API.
If you remove the connection from the connection table, the /user active entry is also removed.
I recommend you run that script a few times and check that there are at least a few entries in “/user active”. Then make a supout file and email to support (at) mikrotik.com with a short explanation of the problem, and what you tried (disconnect and /quit).
The /user active list is directly tied to /ip firewall connection table for that service (from what I’ve found).
That must be true, for on an RB411 with connection tracking disabled (no NAT, just bridging and/or simple routing) running 4.5, repeated API connect/command/disconnect sessions do not accumulate, but behave as expected. (Using the Ruby API library, but the library/language doesn’t matter.)
problem with disconnects persist through all the versions since it was introduced while fixing critical bug. And, sadly, it is still open for version 4.x
sessions there from user which i used for API connection but i have used $API->disconnect () .