Yet another C library for API access: librouteros

RouterOS Scripting
1

Hi,

I realize that there is a large number of modules for API access out there and I feel kinda guilty for reinventing the wheel yet again. Unfortunately, though, none of the existing implementations did fit my bill, most due to language restrictions on my end. I need a plain C99 / POSIX.1-2001 implementation with a GNU General Public License (GPL) compatible license which is thread and reentrant-safe. webasdf’s implementation comes close, but lacks a build system, documentation and source code management.

I’ve therefore written (yet) another library called librouteros (if you can think of a better name, let me know) which is available from verplant.org/librouteros/. The library uses the GNU autotools and libtool and can therefore be easily built using:

./configure && make

Using the library is straight forward: First, you create a connection object using ros_connect. This object, the command you wish to execute and a callback function are then passed to ros_query. That function will do all the network communication, parse the reply into a generic ros_reply_t object and call the callback function. The network communication is hidden from the calling code and the functional approach makes memory management very easy. More detailed documentation is available as librouteros(3) manual page.

Currently the library is still in an early development stage which is denoted by the major version 0 (zero). This means both, API and ABI, are still unstable and may change at any time. If you want to contribute patches, please feel free to check out the source code from repository with the following command and send patches via email (or post a link here). My email address can be found on my homepage and in the README file.

git clone git://git.verplant.org/librouteros.git

If you have a Github account and want to use that, please let me know.

The long-term goal is to abstract the actual commands used, too. There are currently two high-level interfaces to receive a list of interfaces and the registration table as already parsed structures. More high-level interfaces will be added as the need arises.

My ultimate goal is to write a plugin for collectd to read statistics from my RouterBoards. Development of the library is heavily influenced by this goal and my personal use of the devices. So everything interesting for point-to-point connections will probably be available soon, while, for example, hotspot statistics / support is unlikely to be written by me. Patches are, of course, very welcome :slight_smile:

Regards,
—octo

2

does it support simultaneous commands?

3

it would be nice if you could make article about your implementation and benefits on our wiki: http://wiki.mikrotik.com/wiki/Main_Page

if you do that, then when you are done, contact support@mikrotik.com posting link and account name on www.mikrotik.com to reap benefits of your work. :wink:

4

you mean from one interface connect to several routers simultaneously or something else?

5

No, concurrent requests are only supported via multiple connections currently. Implementing asynchronous communication requires some sort of dispatching mechanism which is more trouble than it’s worth, in my experience. What application did you have in mind, that requires multiple simultaneous commands?

Regards,
—octo

6

Do you have any policy on article names? Would librouteros be appropriate?

Regards,
—octo

7

sounds good to me

8

for example, you connect to the router and monitor some interfaces + log. one connection per interface is not very interesting

huh, maybe it’s time to email about my Delphi API Client :smiley:

9

I’ve created the wiki page librouteros and added some generic information as well as a small (and untested) example program. Feedback is welcome of course :slight_smile:

Regards,
—octo

10

thank you, if you are interested in a free RouterOS license, email support. Chupaka - same for you :slight_smile:

11

i can give you tip about API and simultanous commands:

that can be easily done in one connection because API works that way. you can send commands (write to socekt) a command thus, sending it to the router, in return, RouterOS will form replies and 1 consecutive line will be one answer for the command, weather it has to respond to one command or 10 at the same time. Your only concern is - dividing answers and if you use some kind of containers where you store command sent and replies, you only have to match what reply is for what command.

linux socket will take charge of data transmissions, and the actually is not simultaneous as we perceive it, but that way we can run multiple commands and get replies in one go.

12

Hi,

yes, but this is exactly what I’m trying to avoid: When there are several outstanding replies at the same time, I’d need to coordinate reads or use a separate thread and add some queuing / dispatching infrastructure. Overall this adds a lot of complexity and I don’t see the advantage to having multiple connections. If anyone requires this functionality, I’m happy to accept a patch :slight_smile:

Also currently not supported are indefinitely running commands, such as listen: The entire response is read back before calling the callback function. This makes it easily possible to support nested commands. If someone needs such commands, the best way to implement this would be to add an alternative to ros_query, possibly called ros_listen and ros_cancel, which would call a callback for each sentence received without waiting for a “done”. Same here: Patches are welcome :slight_smile:

Regards,
—octo