Seems like it's pretty easy to get the API server to crash.
Although once it's crashed I can usually connect to it again later and interact with it, if it crashes a second time it locks up routeros at 100% CPU.

I've been trying to use the API for extensive configuration of routerboards, both over the wire and over the air.
It seems to me most everyone is using a scheme of sending one API command at a time and deal with its response.
But there are many api 'set' commands that could potentially break a remote link and leave an orphaned routerboard.

Does anyone have a good solution for dealing with this?

I came up with a scheme for sending several api 'set' commands in one packet (so all the necessary changes get applied at a remote site) and then dealing with the individual responses whenever they get back. This is where I tend to see the API server crash.

Has anyone learned any gotchas with the API?
Anyone else seen these API server crashes?

I've used wireshark to capture packets so I've confirmed my packet is always going out okay.

When the API server doesn't crash, seems like I get all the responses to all the set commands back in a single packet. When the API server does crash seems like I only get back most of them and sometimes see the API respond with action timed out message.

Currently I am using routeros 3.27 on both rb411's and rb433's.
I know I could use winbox or do an ssh connection to the command line but I'm not interested in those solutions for this discussion.

At the moment it feels like the API is not good for extensive configuration.

please make supout.rif after the crash and send it to support@mikrotik.com

Yes I have done that a few times.
Mtik says they'll look into it but that's all the news I've heard so far.

I'm more interested to know what other users have done.

Chupaka, seems like you have been using the API quite a bit.
Other than the fact that some api commands like wireless scanning return empty responses,
what quirks and gotchas have you found with the API?

Have you ever seen it crash yourself?

if I find something - I just report and wait a fix =)

but in API I use only simple things (waiting for Torch tool via API ), so it's working flawlessly for me

Oh, I thought you used it a bunch and were an expert. Sorry my mistake.

I'm using API to synchronize all routers. But mine script is as you said "synchronous": send command and wait for results. Everything works flawelessly ;)

I'm using API to synchronize all routers. But mine script is as you said "synchronous": send command and wait for results. Everything works flawelessly

the same thing. but if it's really possible to crash API server (especially if it can be done before login), it's serious security breach, and should be fixed asap

If it is true, that you can crash the route by sending many commands in one packet, then capture this packet and send it to support.

wireshark pcap file is on its way.

This always happens post login so it's not quite a DOS attack.

Looks like this is not specific to the API.
It also happens if I send the equivalent command set in a script file to the ftp server and name the file *.auto.rsc

It seems as if both the API and the ftp server are feeding a process which is parsing and executing routeros commands. For some reason this process is intermittently blowing up. If you observe the blowup the first time (evidenced by the appearance of autosupout.rif) and reboot you will be ok. But if you do not pay attention and it happens again without a reboot the CPU gets pegged at 100%.

I was able to narrow the script down to the following two commands
The first command is 352 bytes/characters long and the second command is 272 bytes/characters long

I made a script putting the above two commands in a script in a for loop of 100 iterations and ran the script in the winbox terminal window via 'import myscript.rsc'. This executed without trouble.

I'd bet a nickel that this has something to do with the length of the above commands and the process getting fed by the API and ftp server.

BTW, I understand that when you ftp upload a script named *.auto.rsc that routeros is supposed to execute it on the spot but I've been observing that it does not get executed the first time I upload it after a reboot. Every time after that, routeros attempts to execute it as advertised.

I bet other folks can verify this if they exercise things enough. I have observed the crash in as little as one try and sometimes it takes more than ten and once in a blue moon more than 20.

Sure enough, if both of the commands are each broken into two commands with fewer arguments, I cannot get the problems I've witnessed to happen.

mtik, please fix!

have you sent it to support?..

I added exact commands to auto.rsc file and uploaded via ftp several times. No crashes at all. Could be something specific to that router. Try to reinstall router with netinstall and reset configuration.

Looks like mikrotik support was able to reproduce this crash. I got an email confirmation yesterday.