Hello

I'm trying to change IP address of one interface on the router using API.

What I have as a coomand is:
and API response is
so it lloks like everything is OK.... But it is not. IP is not changed.

Mikrotik 6.18

Anybody can help ?


EDIT

If I use .id as selector for interface
I have !trap response.

It's very confusing, as =.id= works perfectly with SSID changing for example, but here it is not.

Use "numbers" instead of ".id" to target the item to be edited.

Use "numbers" instead of ".id" to target the item to be edited.

OK.

1. How to get the correct value for the numbers parameter ? Should I first enumerate all interfaces ? What for, if I know the name? Bit useless roundtrip and parsing on client side

2. If using =interface= parameter is wrong, why API doesn't return "!trap" ? It just gives me "!done"

3. And why in other areas (as I mentioned for example on setting SSID) the =.id= parameter is accepted with interface name.

I thing API is bit buggy and inconsistent in many areas. The same syntax from CLI perspective requires different approach from API coding.
I have an emails from Mikrotik guys from Jan 2014 that they are warking on concepts around API, what should be done next and how.... nothing changed from that time.

But back to bussines... What about my 1) question ?


EDIT

Just verified.... it works only with " =.id= " parameter as selector of interface on which I want to change IP. To get it I need to /ip/address/print, then parse whole output to find the .id of interface I want to play with.


EDIT
And what is strange and confusing this works perfectly
as you can see there is no id (like *3 od something what can be found in print output) in =.id= value. There is just plain interface name. And API accepts this and SSID is changed.

This is very confusing

If you know the name, you can use the name as a value for the "numbers" argument. However, in the case of the "/ip address" menu, there are no names to begin with, unlike, say, the "/interface" or "/queue simple" menus.

If you don't know the name (or there aren't names, as in here), you need to then use "print", along with a query that would match the desired item(s), and get their names or IDs from the output.

2. If using =interface= parameter is wrong, why API doesn't return "!trap" ? It just gives me "!done"

"interface" is a valid property you can change on a matching item. For example, you can specify that a particular address that was previously assigned to ether1 would now belong to ether2 instead.

It's just that without "numbers", there are zero items matched, and thus a set is "successfully" executed on 0 items. IMHO, yes, there should be an error for a missing required argument (that one being "numbers"), but regardless, "interface" is a valid argument name.

3. And why in other areas (as I mentioned for example on setting SSID) the =.id= parameter is accepted with interface name.

It seems to me the ".id" argument was never intended to be used as a way to target items... Or perhaps it was at one point, but MikroTik have come to realize this is not consistent with how CLI works, and are trying to fix it. CLI uses normal arguments (usually "numbers") to target items, and so that is how the API is modified to be like.

Thanks for your reply and help.

Just tested this, but it doesn't seem to work


and yes, I've doublechecked if I have such interface It's there

What's strange =numebers=interface_name works perfectly with /interface/wireless/set which works also with =interface=.

but /ip/address/set works for me only with =.id= which I must retrieve and parse from output of print command.



or maybe I'm wrong. But that's my conclusion as for now.

I believe when they are saying to use the numbers, you need to use the internal line item number...

For example,
If I want to Change the Office LAN IP, the number is 1,
If you don't know the number, or want the router to find it, you can use 'find'

try using this example in the mikrotik terminal and see what happens:

Code: Select all

:put [/ip address find interface=hotspot_bridge]

Hi, thanks for input. But we are talking about API not scripting.

Yes, I'm aware, but the two are related. The example was to give you an idea on what to do next.

Good Luck!

Like I said, the "/ip address" menu does not have names.

In menus like "/queue simple", the name of a queue is a unique identifier for an item, hence you can use it to target a queue, and similarly with the "/interface" menu to target an interface, "/ip hotspot user" to target a user, etc.

Items in "/ip address", "/ip arp", and a lot of other menus are NOT uniquely identified by a name. You can have several IP addresses for an interface, so you can't use the interface name as an identifier IN THOSE MENUS.

You've already found the only allowed way to target items in the "/ip address" menu - "print", and then take the ".id" of the item that you want to edit. To filter out all IDs for only the one(s) you need, use queries, e.g.

Yes, thanks for response. I've already coded this in my app. Just thoutgh that there is any faster way then this one.

Thank you for help.

Well, there is, if you wanted to modify ALL items together (like, let's say you wanted to set them all with the same comment) - you could use "find" to get all IDs in the current menu, all in a single property in the response called "ret".

To increase the efficiency of print requests, you can also use the ".proplist" argument to list (in a comma separated list that is) only the properties you want, in this case just ID, so: You still get a sentence from which you need to extract the ID, but at least that sentence won't be "polluted" with the current addresses and interfaces.

Sadly, there's no more efficient way currently. It has been proposed (and I concur) that commands other than print should accept queries themselves, as means to target items, so that you could f.e. do to change all IP addresses of "hotspot_bridge" to be assigned to "ether1" instead.

This is not (yet) implemented in RouterOS however, and MikroTik have not announced any plans to eventually support it (though they haven't explicitly said "No way!" either, so THAT is promising...).