Odd problem with "remove" command in several versions

RouterOS Scripting
1

Recently implemented a new script on our MT boxes and stumbled on what should be a simple block of code. The code below works fine on ROS v3.0, but not at all on v3.13 or v2.9.46

:foreach cntr in=[/ip hotspot active find] do={
:log info [/ip hotspot active get $cntr user];
:log info $cntr;
/ip hotspot active remove $cntr
}

The script outputs the username and the value of $cntr, but stops dead on the remove command. Can anyone reproduce this problem?

Any ideas about what could be causing this?

Upgrading ROS - Try on Non-Production Equipment First
2

Worked on this problem off and on all day today again to no avail.

Any of you gurus got any ideas? Anyone?

3

Normis, what do you make of this?

I’ve troubleshooted this problem a little more and here’s all the new info I have:

  • The code above works on ROS v3.0 and I recently discovered v3.7
    Returns an error on v2.9.46 and v3.13 which is unfortunately running on several important APs of ours.

  • The “id” ($cntr) that I’m dumping to the log is one character longer in v2.9.46 and v3.13 than in v3.0 and v3.7
    I suspect this could possibly be the cause of the error produced upon starting the script.


    What steps do you recommend me taking to correct this problem in the short term? I would like to upgrade/downgrade the remaining APs to either v3.0 or v3.7 so I can get them to function, but I don’t have access to either package file to make this happen. Can you provide me with these versions or suggest some workaround to get us up and running?

4

/ip hotspot active has dynamic entries, some of users could be already disconnected and script will fail because it will try to remove entry that does not exist. I don’t see any other reason why this script may fail.

5

mrz,

Interesting suggestion. Checked into this possibility and here’s what I came up with:

  • When I service these APs (usually the middle of the night), there is rarely anyone using the internet. Active entries are few and far between, so I would assume inactive entries should have long expired.

  • Also, I would think a problem like that should be random. Might catch an expired entry, might not. This is a new script and it has never worked on the versions I mentioned above, yet never failed on the others.


    As much as I would like it to be that simple, I’m thinking that’s not it…guess we’ll keep digging…gotta get this working.

6

Attn: Mikrotik Admins or anyone who has ROS v3.0 or v3.7 package files.
Anyone who knows what might be happening here or has access to v3.0 or v3.7 install files, please speak up. If I can get one of these versions I can at least get my units up and running until we figure out just what happened here.

I’m open to any suggestions as to what I could be omitting, mis-coding or not properly understanding with this issue.

7

Finally found v3.0 - will install on our remaining hardware this evening and post the outcome.

8

After upgrading to ROS v3.0, hosing a radio, and climbing a tower on Sunday to repair it (was able to fix it with netinstall), still no luck with getting the remove command to work in this application. That leaves the only difference being the board and processor. Remove command worked on RB333s with PowerPC, has never succeeded on RB532As. Could this be it? Hardware?

Still would like to hear from a Mikrotik Admin/Programmer…any ideas or workarounds?