Hello.
Does the Mikrotik team have plans to publish ROS 5.x release notes?
I'm asking, because the silly changelog does not cover all of the changes, which is bad (most of uncovered changes are small, but some are major)

They are starting from cli syntax changes:
e.g:

*) syslog

before 5.x: after 5.x: Was previous syntax worse than current?

*) snmp

before 5.x: after 5.x: ... same here - was the trap-sink less pr0 than trap-target?

Now the cherry: SSH
I've made some tools using ssh (paramiko) to automate configuration and management of ROS boxes.
SSH was ok, because it worked from 2.9.x to 4.17 without any major changes, while API was usable in some 3.x releases and 5.x branch.
SSH *WAS* ok until "*) ssh is now completely rewritten (...)", now it gives me EOF after executing command on first channel, and closes connection.

here's debug from paramiko:
http://www.nopaste.pl/12so

Ok to the point: i'm forced to write scripts in every fscking MT dialect, depending on MT version, this is sick.
And now even ssh stopped working for me..

Welcome to ROS! MT have stated many times that they wont release complete changlogs as they think it's impossible despite every other vendor managing to do so

Welcome to ROS! MT have stated many times that they wont release complete changlogs as they think it's impossible despite every other vendor managing to do so

Apple approach - they think you don't need it :-)

support wrote me that nothing changed on the ssh v.5.x
but I have the same problem; /

Once i sad here on forum that I believe that whoever is in charge of scripting development in Mikrotik, he intentionally makes this syntax changes from version to version just to make our lives miserable, and that is huge amusement for him.

There's no development, no planning, no supervision.
They just write code... and all decisions are made probably this way: http://www.ebaumsworld.com/video/watch/80617042/

This also changed (broke my dsa key import process):

:if ([:pick [/system resource get version ] 0 1] = \"5\") do={
:execute script=\"/user ssh-keys import public-key-file=mt.dsa.pub user=admin-ssh\"}
else={
:execute script=\"/user ssh-keys import file=mt.dsa.pub user=admin-ssh\"
}

It happened the same in a couple of other things too...

On wireless:
V4.17
/interface wireless set wlan1 band=
2.4ghz-b 2.4ghz-g-turbo 2ghz-10mhz 2ghz-b/g/n 5ghz 5ghz-5mhz 5ghz-onlyn
2.4ghz-b/g 2.4ghz-onlyg 2ghz-5mhz 2ghz-onlyn 5ghz-10mhz 5ghz-a/n 5ghz-turbo

V5.4
/interface wireless set wlan1 band=
2ghz-b 2ghz-b/g 2ghz-b/g/n 2ghz-onlyg 2ghz-onlyn 5ghz-a 5ghz-a/n 5ghz-onlyn

For normal wifi in 2,4 they changed the name from 2.4ghz-b/g to 2ghz-b/g

From V3 to V4 they changed the syntax to configure dns servers.

When they change the syntax, it should have a very strong reason.

Best regards,

For normal wifi in 2,4 they changed the name from 2.4ghz-b/g to 2ghz-b/g

When they change the syntax, it should have a very strong reason.

it is not just 2.4GHz, it is just 2GHz band as oyu can set 2.2GHz and up to 2.5GHz (depending on wifi module) and depending on what your regulatory domain allows.

For normal wifi in 2,4 they changed the name from 2.4ghz-b/g to 2ghz-b/g

When they change the syntax, it should have a very strong reason.

it is not just 2.4GHz, it is just 2GHz band as oyu can set 2.2GHz and up to 2.5GHz (depending on wifi module) and depending on what your regulatory domain allows.

And what about 900MHz card? Then it should be called only "b/g". I think it is not so strong reason to rename, just a cosmetic change.

For normal wifi in 2,4 they changed the name from 2.4ghz-b/g to 2ghz-b/g

When they change the syntax, it should have a very strong reason.

it is not just 2.4GHz, it is just 2GHz band as oyu can set 2.2GHz and up to 2.5GHz (depending on wifi module) and depending on what your regulatory domain allows.

Hi Janisk,

I would ask you if possible to:
When thereis a change on naming convention, please put that on the change-log.

It will save us a couple of hours on troubleshooting.

An example: A customer running dude with a custom function to monitor Mikrotik through ros_command("").
After an RouterOS upgrade, the probe goes down. Where is the problem?

It´s difficult to discover that the problem is on the RouterOS syntax.

Good weekend,

what could they be monitoring that requires the changing of the band?

what could they be monitoring that requires the changing of the band?

Very simple:

RB411U with R52h radio and dual-band antenna.

If the 5Ghz link goes down, the ros_command("") is used to change the frequency, band and antenna connector...

It´s a dual frequency link over water, normaly the link goes down at 6am, changes from 5Ghz to 2,4Ghz.

On the master device, this is done by dude, on the slave device this is done by scripting.

After a RouterOS upgrade, this failed...

Best regards,

900MHz cards usually are using frequency converters and card reports 2 ghz range. There are some cards that can be correctly identified as in that range and we can do automatic conversions of frequencies (just cosmetic change). For other cards that are not distinguishable from their 2GHz counterparts you can set frequency offset to get the "correct" values.