I have problem with connecting to MikroTik with this $API->connect!!!
Sometimes connect, sometimes not!!!

Connection attempt #1 to 10.2.2.7:8728...
<<< [6] /login
>>> [5/5 bytes read.
>>> [5, 39] !done
>>> [37/37 bytes read.
>>> [37, 1] =ret=e468307e9a81295c12141bd7ddc805f4
Connection attempt #2 to 10.2.2.7:8728...
<<< [6] /login
>>> [5/5 bytes read.
>>> [5, 39] !done
>>> [37/37 bytes read.
>>> [37, 1] =ret=1c2341c8123f35583fe82073525b99bc
Connection attempt #3 to 10.2.2.7:8728...
<<< [6] /login
>>> [5/5 bytes read.
>>> [5, 0] !trap
Connection attempt #4 to 10.2.2.7:8728...
<<< [6] /login
>>> [5/5 bytes read.
>>> [5, 31] !trap
>>> [29/29 bytes read.
>>> [29, 1] =message=cannot get challenge
Connection attempt #5 to 10.2.2.7:8728...
<<< [6] /login
>>> [5/5 bytes read.
>>> [5, 31] !trap
>>> [29/29 bytes read.
>>> [29, 1] =message=cannot get challenge
Error...

how many concurrent connections through API you already have to this router?

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.

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.

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 .

Maybe a "/quit" command sent just before the disconnect might drop the user from the active list.

Tried but unfortunately not worked

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).

I will follow this topic at http://forum.mikrotik.com/viewtopic.php?f=2&t=41200 because that board is more popular

this is know problem. and we are working to correct it.
Only reliable way to get out those ghosting entries is to reboot the router.

As a programmer can you suggest a way to persistent the connection for preventing this problem temporary ?

for time being - see at what number of connections it fails and reboot router slightly before that number. Not much of a workaround.

It is a random number

10k - 20K worked for me.

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.)

I have this problem with new 4.10 firmware. This problem does not happen in 4.5. I'm not sure which firmware re-introduced the bug.

4.10 me also,

4.10 for me to

v4.11 x86 is also not disconnecting correctly. Also, I use NAT and there are no connections to API (8728) on the router.

I will continue to use SSH/Telnet, it's very solid.

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

It is fixed for 5.x

janisk,
Thank you for the update. I look forward to v5

Yeah, I'm too looking forward to stable final v5 release
Currently I have found no means to overcome this problem, I also can't find entries to remove in ip firewall connections list.

I had the same problem with the API for version 4.10.
To test did downgrade one server to 4.5, and another server updated to 5.0rc1.
And they both work without the above problems. Almost. ))
In one week, both servers had to reboot.
In 5.0rc1 and in version 4.5 session disappear good.
BUT in an uncertain time MT simply stops responding through the API.
Here's waiting for the repetition ...
As a solution to the problem may be reboot MT via telnet from remote script.

So what's so different between versions 4.5 and 4.11?
Can we actually expect this to be somehow fixed in next 4.x version?

both, rc1 and 4.5 stop responding or just 4.5, older versions had that problem in rc1 it should have been fixed.

I think work is going into v5.x I don't believe this problem will be fixed in v4.x IMO

if you remember broken console in RouterOS 5.0beta2 then that was caused by that patch. That is why it is not yet there in version 4

Very sadly that problem as i understand can't be solved in v4, i have same problem in latest v4.16.

anybody tests this problem in 5.0rc11 ?

Of v5 final we wait.

anybody tests this problem in 5.0rc11 ?

what problem exactly?

If you talk about idling connections in active list - it has been fixed in 5.0beta2

anybody tests this problem in 5.0rc11 ?

what problem exactly?

If you talk about idling connections in active list - it has been fixed in 5.0beta2

http://forum.mikrotik.com/viewtopic.php?f=2&t=41200

http://forum.mikrotik.com/viewtopic.php?f=2&t=41200

yes, it is the same. in all versions since 5.0beta2 till 5.0rc11 this problem of active API sessions accumulating has been solved.