What's new in 6.30.4 (Aug.25.15-12:59:46)

*) bridge fastpath - fixed updating bridge FDB on receive (could cause TX traffic flooding on all bridge ports)
*) bonding fastpath - fixed possible crash when bonding master was also a bridge port
*) user-manager - fixed zoom for user-manager homepage when mobile devices used
*) tool fetch - don't trim [t]ftp leading slashes
*) conntrack - fixed problem with manual connection removal
*) winbox - restrict change dynamic interface fields
*) romon - fixed crash on SACKed tx segments
*) route - fixed crash on removing route that was aggregated;
*) ipsec - fixed crash in when gcm encryption was used
*) ipsec - allow to set peer address as "::/0"
*) ipsec - fixed empty sa-src address on acquire in tun mode
*) ipsec - show proposal info in export ipsec section
*) ipsec - preserve port wildcard when generating policy without port override
*) ipsec - fix replay window, was accidently disabled since version 6.30;

What's new in 6.30.3 (2015-Jul-24 08:06):

factory-only release

I'm surprised, i was expecting v6.31.1 in bugfix channel.

Why can not I download "install-image-6.30.4.zip"?
http://download2.mikrotik.com/routeros/ ... 6.30.4.zip
and
http://download2.mikrotik.com/routeros/ ... e-6.31.zip

Now i am confused, why the crs port flapping bugfixes are in current and not in bugfix?

This version includes only approved fixes which are already tested and actually work without breaking anything else.

I would think that in the future we should almost always expect some bugs to be fixed in x.y before x.y+1.0 too.

I'm surprised, i was expecting v6.31.1 in bugfix channel.

Yes, very confusing

It is not strange.

I'm surprised, i was expecting v6.31.1 in bugfix channel.

Yes, very confusing

Not at all. They promised to keep stable (bug fix only) branch until current gets stable. So far, so good.

Ah very nice, was actually worried MT had abandoned the promised bugfix track as 6.31 was released and 6.32rcs started appearing...

A very basic question, currently i'm on 6.30.2 release but winbox doesn't show update track choice (bugfix, and current), so i'd have to manually download the npk and do the restart as was common before.
Is there an option to enable update track choice or is this a bug, or I simply missed something as the new procedure was introduced?

Edit: strange just connected from a different pc (winbox) and the option appeared... nvm

Thanks

_saik0: it is a new feature of v6.31 so there will be no update track choices in v6.30.

Now i am confused, why the crs port flapping bugfixes are in current and not in bugfix?

This version includes only approved fixes which are already tested and actually work without breaking anything else.

So you - developers - even do not know whether your bugfix (CRS port flapping) is working without breaking anything else??? Do I understand it correctly? So is this bug fixed or not?

So you - developers - even do not know whether your bugfix (CRS port flapping) is working without breaking anything else???

This is a common case in any kind of software development. Any new code (be it a bug fix, or a new feature) has a great potential to break existing code. MT is not (and can not be) an exception in this regard.

That is why rc versions are released. When they are absolutely tested and we are sure that fix helps and does not break anything else in common configurations, then fix is included in bugfix version. Fix for CRS is relatively new so it is not yet included in bugfix version.

I'm surprised, i was expecting v6.31.1 in bugfix channel.

Yes, very confusing

Not at all. They promised to keep stable (bug fix only) branch until current gets stable. So far, so good.

Then the problem is the terminology used.

When you go to download a software, the 'current' release is considered the latest stable

This is clearly not the case here. The 'current' release is the 'bleeding edge' release not the 'stable' release.

Maybe the whole thing should be renamed properly to reflect what's actually going on.

Right now 6.30.4 is considered (by actually being stable) the 'latest stable' release, while 6.31 is simply worse than the RCs 6.31 should be called a bleeding edge release or a beta/rc release since it has caused tons of problems apparently.

When a user sees 'Current' automatically thinks that this is the latest STABLE. And THAT's why it is confusing!

Then the problem is the terminology used.

When you go to download a software, the 'current' release is considered the latest stable

This is clearly not the case here. The 'current' release is the 'bleeding edge' release not the 'stable' release.

I don't think "current" should always be considered stable. It is actually quite common to name non-stable releases "current". Take FreeBSD release naming rules, for example. CURRENT there means "bleeding edge".

Still, it doesn't change the fact that it's confusing to the end users IMHO.

If Current meant stable, what would Bugfix mean?

OK, i will break the trend and give some actual version feedback for a change

Yesterday's evening/night i upgraded my core networks, including some of the IPsec links to 6.30.4. Resulted in very calm and relaxed evening - no obvious problems found.

Please post any remaining issues you find in this 6.30.4 release! This is important, to make this version truly stable.

Yes, naming the versions is not easy.

At the moment we are still debating how this should work in the long term.
Right now:

bugfix = stable, only bug fixes are included, no risky new features (A)
current = latest version with new features and bug fixes also (A + B)
release candidate = nightly build, not much testing, release as soon as usable, includes A + B + C changes that are not thoroughly tested yet
development = alpha/beta of v7 when we release it (not yet available)

The important question is, should we replace 6.30.4 with 6.31.1 when we have important issues in v6.31, or ... if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

Normis, I think that you are catched in the trap now. Very good idea has exploded in much more effort and complexity while the customers do not seem to be happier too much. Please, keep bug fixing of 6.30 to be current and call 6.31 to be a release candidate.

As I said before Bugfix 6.30.x should not jump to 6.31.y until there's solid feedback that the latter is stable enough, and definitely not if it unexpectedly breaks something that is known to work in the former.

I am thinking now that maybe the Bugfix status of a version could be revoked if suddenly it is found to break something that worked before.

How can v6.31 become stable enough, if we can't release fixes for it?

Should we replace 6.31 with improved 6.31.x as current, and then eventually move last 6.31.x to bugfix, or continue with 6.32, 6.33, and then, based on time or performance start new bugfix only version

... so it will be the same like before?
(the second option)

No, the difference is that 6.30.x will be maintained while the other releases are happening. 6.30.5 will still be made if problems are found.

How can v6.31 become stable enough, if we can't release fixes for it?

Should we replace 6.31 with improved 6.31.x as current, and then eventually move last 6.31.x to bugfix, or continue with 6.32, 6.33, and then, based on time or performance start new bugfix only version

You can release fixes for it, but it does not mean they are automatically added to the Bugfix stream

So, when you release 6.31.1 it becomes Current. If it's never good enough, it does not go to Bugfix, and some later version will.

You may discover that 6.31 is so fundamentally broken that you decide to put 6.32 in Current without ever making any 6.31 Bugfix

Thanks for the input, vortex, this is one of the options. But it will not be easy to tell versions apart, once they are downloaded.

Maybe the router should try to fetch the current status of the version running on the box from Mikrotik every once in a while.

Then the administrator could also be informed that he MUST upgrade because of a severe security problem, or bricking risk, for example.

My view on versions:
The main task is to maintain high quality bugfix version on bugfix channel. As far as i can see only way to do so is to first publish it as Current, and when proper level of confidence in version stability is reached move it to bugfix to replace previous bugfix.

should you go 6.31.1 , 6.31.2... or 6.32, 6.33, .... in current channel and then move it to bugfix is basically irrelevant,

i would prefer first option to save numbers, and also to instantly realize that 6.31.1 is better than 6.31, but if it is on current channel not good enough for bugfix status yet, and if it turns out ok, you can re-release it in bugfix without rebuilding it with new number.

but i also know that there are people that will find it confusing and prefer 6.xx.y to be used only for bugfix versions.

6.xx.y is a bugfix to 6.xx, but it does not mean it is in the Bugfix channel

The problem is trying to lock channels to specific version patterns, which is wrong.

OK, but when you have on your PC:

6.31.3
6.32.2
6.33.5
6.34.2

Which one is considered more stable than the other?

Display up to date stream paths on the interfaces and website.

Display up to date stream paths on the interfaces and website.

Combine it with download Archive (that everyone is requesting for years), and you have nice look and functionality on web page

if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

+1

6.30.4 leave on web page as bugfix
and when you have 6.31.1 - name is still current

The important question is, should we replace 6.30.4 with 6.31.1 when we have important issues in v6.31, or ... if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

Hi Normis and all,

What you call bugfix stream seems to me like "Log Term Support" releases in sysadmin world (See Ubuntu server release model for example).

Obviously, the release rythm of rOS and Ubuntu are quite different. But the logic used could be used nonetheless.
From my point of view, this release and maintenance model allow to have everyone happy:

• => To be on the bleeding edge, follow every new version
  => To be on the safe side, stick to the LTS releases.

If the support time-window of LTS release do overlap (as it is the case with Ubuntu srv), then each can choose whether to upgrade to a newer LTS early, or stick to an older LTS release until it is approaching end of support and allow the newer LTS to be fully bugfixed before going for it.

my 2 cents.
Fabrice

Has anyone tried v6.30.4 yet? Working good?

Working good so far - RB2011 and RB532.

6.30.4 working stable for now on OmniTik (2d uptime) - no issues.

Its very stable version No known issues at this time. Ugraded about 100pcs, no problem.

Glad to hear that idea to have a bugfix version has paid off. Seems that this version does not have major issues so far, at least according to this conversation.

At my 493ah not working 6.30.4
Or is config problem?
2 wifi cards, 4 lans in use
Ppoe for vdsl and vpn for 10 users
Works 2-4 min and block all
I post pictures in 6.31 section, in log info i get red warning

Upgraded also on my RB1100AHx2 - the PPoE upload speed limitation present in 6.30.2 is fixed (even if not mentioned in the release note). No major issues so far.

How can v6.31 become stable enough, if we can't release fixes for it?
Should we replace 6.31 with improved 6.31.x as current, and then eventually move last 6.31.x to bugfix, or continue with 6.32, 6.33, and then, based on time or performance start new bugfix only version

My 2 cent:

6.30.x : stable/LTS version maintained for a while (min 2/3 months)
6.31, 6.32 .. 6.3X (with their rc in between as in use before)

When evidences/feedbacks give enough confidence you can swap the stable/lts to a newer version (not necessarily the last released) ..or (in emergency) when security issues come out.

Can anyone confirm what happens to active working port on rb532a with rb564 installed on it running 6.30.4 when the port is manually disabled and then enabled? In 6.30.2 the port will look correctly but will not revert to running state back until the power is recycled. Simple reboot does not help.

Normis/Mikrotik

For what it's worth I would say that unless there are any low hanging fruit/easy fixes that can be incorporated into 6.30 then I believe that the .4 should be the last iteration.

With the way Mikrotik develops and at the speed they develop, the best thing I would say is to develop and release bug fixes up to a certain point. However one thing to do would be to stretch out the development cycles a little bit for new features.

Changes that are 6.x should take longer (3 to maybe 6 months) whereas 6.xx.y should take shorter (few weeks to a month).

That gives Mikrotik more time to develop new features and make sure the code is more solid, and it gives the bug fix team time to fix the bugs in the current code. This also allows for regression testing to be easier as well, and also allows for proactive/retroactive addition to patches to be implemented that way bugs in older code aren't reopened in newer code.

Normis/Mikrotik

For what it's worth I would say that unless there are any low hanging fruit/easy fixes that can be incorporated into 6.30 then I believe that the .4 should be the last iteration.

With the way Mikrotik develops and at the speed they develop, the best thing I would say is to develop and release bug fixes up to a certain point. However one thing to do would be to stretch out the development cycles a little bit for new features.

Changes that are 6.x should take longer (3 to maybe 6 months) whereas 6.xx.y should take shorter (few weeks to a month).

That gives Mikrotik more time to develop new features and make sure the code is more solid, and it gives the bug fix team time to fix the bugs in the current code. This also allows for regression testing to be easier as well, and also allows for proactive/retroactive addition to patches to be implemented that way bugs in older code aren't reopened in newer code.

No. I would like a longer lasting Bugfix release without new features. Our network is no playground. Stability is number one feature.

Now i am confused, why the crs port flapping bugfixes are in current and not in bugfix?

No. I would like a longer lasting Bugfix release without new features. Our network is no playground. Stability is number one feature.

+1000

I think one should look at how long it has been between acceptable non-dev RouterOS releases to establish the bug fix branch duration baseline.

But I don't think this duration should be a hard constraint, as many people are requesting some feature and upgrading minor version because of that. What should happen is that a bug fix branch must not be closed until there's a newer one at least as solid (test?).

It is not like you need an LTS because upgrading otherwise means a difficult upgrade of some application.

I think right now people are too sensitised to the recent RouterOS development history.

I think, the mentioned LTS approach like Ubuntu, or better Asterisk (they had the same Problem as Mikrotik before), is the best one.

I think, the mentioned LTS approach like Ubuntu, or better Asterisk (they had the same Problem as Mikrotik before), is the best one.

An additional option is to do feature upgrades with packages as it is done with wireless package. So if you need top end wireless features you can select the newer package and take the risk.

LTS in Linux and Asterisk are major releases, not minor ones.

I own and operate a small software company. While I don’t know everything, I do have experience related to this subject. The new approach MikroTik has taken is the right approach conceptually speaking. I have been extremely scared to update to new versions of the firmware and look forward to this new release schedule.

Since MikroTik's goal is to instill confidence to the technical community, I think the best way to do that would be to offer a permanent bug fix branch. Since we can't change the past, going forward, MikroTik could do something similar to this:

Maintain two branches: FEATURE and BUG

RouterOS version 7.0.0 -- 7 is the MAJOR version and represents the beginning of time.
RouterOS version 7.1.0 -- the next digit is the branch identifier
even number for FEATURE, odd number for BUG branch. BUGP branches are frozen in time, forever.

Let's walk through time to see how this will play out.

7.0.1 -- FEATURE branch, first update. A new Wifi package was added, that's nice.

7.1.1 -- BUGP release, a bug was found in 7.1.0 and corrected. Notice, this version does not (never will) have the new Wifi package.

7.1.2 -- BUGP release, a small bug was fixed. This version is becoming very stable.

7.2.0 -- FEATURE release, a new one too. MikroTik wanted to release a version with the Wifi package that was based on 7.1.2. They also added a new DNS package.

7.3.1 -- BUG release (not P branch), that new DNS package turned out to be buggy. Oops. They fixed it.

7.1.3 -- BUGP release, this version is rock stable! Only a tiny bug fixed, nothing new added.

--two years later

The FEATURE branch is now at 7.6.2 and has many features. The BUGP branch is at 7.1.15 and is so stable some people say that MikroTik means "stability" in Esperanto. MikroTik killed off the 7.4 branch after they fixed it with 7.5 which eventually turned into 7.6. Notice how the Version 7.1 still lives on and only changes when necessary.

Notice that there is a permanent BUGP release, and Mikrotik can choose (at their discretion) to have multiple BUG versions for each of their FEATURE releases based on how much time and resources they have. The benefit is that for those of us whose reputations are on the line, we have a BUGP release we can count on.

MikroTik can add and fix things all they want. Internally at MikroTik, they will probably be maintaining three branches of their firmware: The permanent BUGP release, the new FEATURE releases, and random BUG releases for the each of the new feature releases. This means MikroTik can choose to kill off random FEATURE branches as they merge in BUG releases.

I have installed 6.30.4 on a RB750. I did a factory reset. Port flapping occurs on all the LAN ports when connected. I downgraded to 6.29.1. No port flapping occurs. (Port flapping also occurs on 6.31, that is noted in the release notes for 6.32rc6, but it implies that the problem was introduced in 6.31. The problem seems to have been introduced in 6.30 and is still present in 6.30.4.) By the way, the port flapping is fixed in 6.32RC6, but if you do a reset configuration with 6.32rc6, the configuration goes to a very strange config with no firewall or routing and the IP address of 192.168.88.1 configure only on eth1.

...if you do a reset configuration with 6.32rc6, the configuration goes to a very strange config with no firewall or routing and the IP address of 192.168.88.1 configure only on eth1.

It's a standard default config, why you say "very strange"?

...if you do a reset configuration with 6.32rc6, the configuration goes to a very strange config with no firewall or routing and the IP address of 192.168.88.1 configure only on eth1.

It's a standard default config, why you say "very strange"?

I say "very strange" because in all other releases setting to default configuration on this router sets the router up as a SOHO router with a firewall, WAN port on eth1 (with DHCP client), and LAN ports with DHCP server on eth2-5.

6.29 and 6.30.2 had major problems for me. 4 days ago I upgraded about 10 towers (some bridged, some routed, some a bit of both to 6.30.4 as a last ditch attempt before facing the prospect of dropping them back to 6.7.. So far so good.

6.30 should be equivalent to LTS.
Having a list of "known" bugs, "known" missing features and "known" workarounds is OK.
Upgrading a stable version with reasonable confidence that no new bugs will be introduced is essential.

Crossing fingers because there's a good chance that the latest "latest Stable version" (sic) new features and bug fixes have introduced lots of new bugs is not good in many environments.


To prevent a nightmare of multiple versions for the developers/testers, might I suggest something like:-
A new LTS version every 3 months (development being so fast at Mikrotik !).
Maintenance/bug fixing of the previous LTS for up to additional 3 months (so 6 months "support" in total).
Maintenance/bug fixing of non LTS versions for 1 month.
e.g.In 10 months time, we'd be able to choose something like.
6.30.32 - LTS. Unchanged for 4 months.
6.40.38 - LTS. Unchanged for 1 month.
6.60.23 - LTS. Previous so bugfix support for next 2 months.
6.70.7 - LTS. Released previous month.
6.71.3 - previous stable version plus 2 bugfixes.
6.72 - current stable version

That is hardly LTS. LTS is supposed to last years.

I don't think it makes much sense for RouterOS.

I think, the mentioned LTS approach like Ubuntu, or better Asterisk (they had the same Problem as Mikrotik before), is the best one.

An additional option is to do feature upgrades with packages as it is done with wireless package. So if you need top end wireless features you can select the newer package and take the risk.

Since all packages needs to have same version number that sounds impossible to me. Or you get bugfix versions on packages as well, makes it even more complicated imho. Good idea but after some thinking maybe better not.....

1st priority for administrator is stability
2nd priority is to have best network with latest features.

After reading previous posts and falling in some 'traps' my self I produced following structure. Its basically mentioned by some already and imho it combines most suggestions in one working scheme.



For stability highest version will be one with bugfixes without any new features compared to 6.xx ("0" version).
Only after some time (2 months sounds reasonable) that version that after its last bugfix shows no more new mayor bugs can bear the title "current" because its been declared 'stable'

New version that adds new features are 'rc' versions until it has proven to have no new bugs. (Same procedure as with stable version.

So:

3.30 is always "rc" (3.29 or older is "stable"); Users are picking it up because it brings new features shown in log, hence we call it 3.30rc (ALWAYS!); ==>> bugs come up ==>> bug fix is made ==>> 3.30bf1 ==>> 3.30bf2 etc. until for 2 months no more new bugs surface ==>>3.30bf5 is declared "current" (maybe some selected users can vote?) and will bear name 3.30S+ (=Stable+support)
[a "bf" version is therefore always a 'bugfix' for a "rc" version. Only after 60 days without buf fixes a rc version evolved through its "bf" versions into a "S" version, stable. Only than it can become "current" version on the server for regular downloads]

At the same time other development can be made, but have to be put in new version 3.31 that will be called 3.31rc
Same process as 3.30 will be followed and one day it can be called "current" and bear name 3.31S+

Only when 3.31S+ is there it can take over the title "Current" from 3.30. Because only now everybody should be able to install it without problems.
If you are still waiting for new features, probably 3.31rc and 3.32rc are out but it didn't survive 60 days without bugfixes yet....


Scheme:

3.30rc ==> 3.30bf1 ==> 3.30bf2 ==> 3.30bf3 ==>3.30bf4==60 days=>3.30S ==> "Current" ==> "S+"
3.31rc ==>3.31bf1==>3.31bf2 ==> 3.31bf3 ==>3.31bf4==60 days=>3.31S ==> "Current" ==> "S+"
3.32rc ==>3.32bf1==>3.32bf2 ==> 3.32bf3 ==>3.32bf4==60 days=>3.32S ==> "Current"
etc.

Indeed we now might have several 'lines' of initial "rc" versions with their "bf" versions. Each line only becomes "S+" after 60 days without new bugs and only the latest line (highest number) with "S+" can be made "Current"

Now its also important the website states for each "rc" clearly what new features are compared to previous version.
Make a graph that clearly shows what features are in what version. A simple spreadsheet might do with older versions slowly fading away in time when more and more new versions are introduced.
(This would also make it more easy to troubleshoot some issues by the user if he enters in a problem after some versions were introduced in his routers. Or some don't like new features and want to stick to latest version without some specific feature.)

Than for each bugfix version a changelog should be maintained.

Off course the website should have some basic explanation saying:

1. "Current" version is latest 60 day stable version after some bug fixes. No more new important bugs found..
2. "S+" is a versions proven to be stable and MT renders support but lesser features compared to "Current"
3. "RC" versions are versions that have new features compared to "Current" but is not grant the "Current" status since its younger than 60 days and bugs might still submerge.
4. Older versions fading away in time will loose the "+" when MT is not giving support any longer. Probably only the latest family version might carry the "S+" sign for years untill its really outdated.. (any body still using 3.xx??)

Auto update from the router (winbox, telnet, script etc.) should never, NEVER be a more recent version than the "Current". Only this version is a version that is around for at least 60 days after the last important bug fix for that line. So only this version is safe to use for ALL! No more mistakes will be made now......

What about 'small' non destructive bugs that might come up in the 60 days period?
These bugs are to be weighted by MT to declare them of lesser importance and should be fixed in a new rc version (with higher number.) The moment they decide to fixed into a new bugfix version of that specific line the 60 days counter should start counting again for that line.....
They will have to make that decision and there will always be discussion on it by the ones affected.




I hope in the end we will see a proper system established. On the moment its chaos. I run now 3.27's, 3.30's, 3.31's, 3.30.2's and 3.30.4's on my network and am still surprised at times that some boards go down after running fine for weeks without an issue..... and I need some new functions at time.....
Just replaced the 3.30.2 on the 2nd NetMetal that ran for 2 weeks without any hickup to 3.30.4 because it suddenly stopped passing traffic over a bridge port..... I thought 3.30.2 was pretty stable...

I think, the mentioned LTS approach like Ubuntu, or better Asterisk (they had the same Problem as Mikrotik before), is the best one.

An additional option is to do feature upgrades with packages as it is done with wireless package. So if you need top end wireless features you can select the newer package and take the risk.

Since all packages needs to have same version number that sounds impossible to me. Or you get bugfix versions on packages as well, makes it even more complicated imho. Good idea but after some thinking maybe better not.....

1st priority for administrator is stability
2nd priority is to have best network with latest features.

After reading previous posts and falling in some 'traps' my self I produced following structure. Its basically mentioned by some already and imho it combines most suggestions in one working scheme.



For stability highest version will be one with bugfixes without any new features compared to 6.xx ("0" version).
Only after some time (2 months sounds reasonable) that version that after its last bugfix shows no more new mayor bugs can bear the title "current" because its been declared 'stable'

New version that adds new features are 'rc' versions until it has proven to have no new bugs. (Same procedure as with stable version.

So:

3.30 is always "rc" (3.29 or older is "stable"); Users are picking it up because it brings new features shown in log, hence we call it 3.30rc (ALWAYS!); ==>> bugs come up ==>> bug fix is made ==>> 3.30bf1 ==>> 3.30bf2 etc. until for 2 months no more new bugs surface ==>>3.30bf5 is declared "current" (maybe some selected users can vote?) and will bear name 3.30S+ (=Stable+support)
[a "bf" version is therefore always a 'bugfix' for a "rc" version. Only after 60 days without buf fixes a rc version evolved through its "bf" versions into a "S" version, stable. Only than it can become "current" version on the server for regular downloads]

At the same time other development can be made, but have to be put in new version 3.31 that will be called 3.31rc
Same process as 3.30 will be followed and one day it can be called "current" and bear name 3.31S+

Only when 3.31S+ is there it can take over the title "Current" from 3.30. Because only now everybody should be able to install it without problems.
If you are still waiting for new features, probably 3.31rc and 3.32rc are out but it didn't survive 60 days without bugfixes yet....


Scheme:

3.30rc ==> 3.30bf1 ==> 3.30bf2 ==> 3.30bf3 ==>3.30bf4==60 days=>3.30S ==> "Current" ==> "S+"
3.31rc ==>3.31bf1==>3.31bf2 ==> 3.31bf3 ==>3.31bf4==60 days=>3.31S ==> "Current" ==> "S+"
3.32rc ==>3.32bf1==>3.32bf2 ==> 3.32bf3 ==>3.32bf4==60 days=>3.32S ==> "Current"
etc.

Indeed we now might have several 'lines' of initial "rc" versions with their "bf" versions. Each line only becomes "S+" after 60 days without new bugs and only the latest line (highest number) with "S+" can be made "Current"

Now its also important the website states for each "rc" clearly what new features are compared to previous version.
Make a graph that clearly shows what features are in what version. A simple spreadsheet might do with older versions slowly fading away in time when more and more new versions are introduced.
(This would also make it more easy to troubleshoot some issues by the user if he enters in a problem after some versions were introduced in his routers. Or some don't like new features and want to stick to latest version without some specific feature.)

Than for each bugfix version a changelog should be maintained.

Off course the website should have some basic explanation saying:

1. "Current" version is latest 60 day stable version after some bug fixes. No more new important bugs found..
2. "S+" is a versions proven to be stable and MT renders support but lesser features compared to "Current"
3. "RC" versions are versions that have new features compared to "Current" but is not grant the "Current" status since its younger than 60 days and bugs might still submerge.
4. Older versions fading away in time will loose the "+" when MT is not giving support any longer. Probably only the latest family version might carry the "S+" sign for years untill its really outdated.. (any body still using 3.xx??)

Auto update from the router (winbox, telnet, script etc.) should never, NEVER be a more recent version than the "Current". Only this version is a version that is around for at least 60 days after the last important bug fix for that line. So only this version is safe to use for ALL! No more mistakes will be made now......

What about 'small' non destructive bugs that might come up in the 60 days period?
These bugs are to be weighted by MT to declare them of lesser importance and should be fixed in a new rc version (with higher number.) The moment they decide to fixed into a new bugfix version of that specific line the 60 days counter should start counting again for that line.....
They will have to make that decision and there will always be discussion on it by the ones affected.




I hope in the end we will see a proper system established. On the moment its chaos. I run now 3.27's, 3.30's, 3.31's, 3.30.2's and 3.30.4's on my network and am still surprised at times that some boards go down after running fine for weeks without an issue..... and I need some new functions at time.....
Just replaced the 3.30.2 on the 2nd NetMetal that ran for 2 weeks without any hickup to 3.30.4 because it suddenly stopped passing traffic over a bridge port..... I thought 3.30.2 was pretty stable...

We've 6.30 running everywhere now without a problem. This is our current stable.

We have 6.30.4 almost everywhere, only some 6.27 on far devices.
Both very stable IMHO

That is hardly LTS. LTS is supposed to last years.

I don't think it makes much sense for RouterOS.

It's all relative. 6 months of supporting a stable release is much longer than the current "install and hope" scenario.

The newer the version, the more risk. If you don't want/need to run bleeding edge (I still run 6.7 on many devices), you currently have to take an educated guess (usually by spending hours on this form to find feedback) as to which release is the most stable using certain features in certain scenarios.

It would be much simpler to have some LTS versions with a known list of features/bugs and make the choice of which release to use based on the features you require. As for the syntax of RouterOS version numbers and release schedule of the invariably buggy "latest stable versions", I don't really give a monkeys.

Oh..6.30.4 - still working

We've 6.30 running everywhere now without a problem. This is our current stable.

The fact bug fixes are already at 6.30.4 means it is not a stable version. Maybe for you but not for lots of others.

What a single user's experiences are with certain version is not relevant. Only if for some time no new complaints or failures are shown by several users on different platforms and with different configurations a version can be called "stable".

I have had now several units that after weeks of running with 6.30 still stopped passing traffic. Where under 6.27 same boards in same setup worked flawless for at least half a year.....

That is hardly LTS. LTS is supposed to last years.

I don't think it makes much sense for RouterOS.

It's all relative. 6 months of supporting a stable release is much longer than the current "install and hope" scenario.

The newer the version, the more risk. If you don't want/need to run bleeding edge (I still run 6.7 on many devices), you currently have to take an educated guess (usually by spending hours on this form to find feedback) as to which release is the most stable using certain features in certain scenarios.

It would be much simpler to have some LTS versions with a known list of features/bugs and make the choice of which release to use based on the features you require. As for the syntax of RouterOS version numbers and release schedule of the invariably buggy "latest stable versions", I don't really give a monkeys.

Oh..6.30.4 - still working

Yes, but a minor version that is maintained for 6 months is not really the same concept as an LTS.

For me, an LTS is not something that you need only for stability.

There is still a problem with connection bytes and connection rate when used together. I am using this feature from long time to divide the "heavy traffic" from "normal traffic". But since version 6.30, I think, it is not working anymore. The rule is something like:
The first rule does not capture traffic anymore, as result packets are not marked and queues in relation are not working.

My happiness was premature. The "CCP lost compression got out of sync" L2TP/IPSec VPN client bug is still present in this version, even when compression is disabled in the ppp profile.
The "dial on demand" option in SSTP VPN client still acts strange - connects and disconnects in cca 1 second pace.
Ticket #2015081866000551

Found a minor bug in 6.30.4, easy to duplicate.

Winbox 3rc12
RB1100AHx2

Control B does not work to bring up comments. Works fine on RB2011iL

Cheers

Found a minor bug in 6.30.4, easy to duplicate.

Winbox 3rc12
RB1100AHx2

Control B does not work to bring up comments. Works fine on RB2011iL

Cheers

Ctrl+M is the shortcut for comments...

Sorry, I fat fingered that : ) I meant control M doesn't work on the 1100AHx2.

You probably tried to CTRL-M a dynamic item. Works OK on static items on my 1100AHx2 (and this is how it should be....).

How does one install this version? I need the npk file, or? Where do I get it?

How does one install this version? I need the npk file, or? Where do I get it?

http://www.mikrotik.com/download
And select the version

How does one install this version? I need the npk file, or? Where do I get it?

http://www.mikrotik.com/download
And select the version

Thank you, newer seen that box before.

You probably tried to CTRL-M a dynamic item. Works OK on static items on my 1100AHx2 (and this is how it should be....).

No, I'm well aware of dynamic entries. I first noticed it while updating filter rules, then tried it on all kinds of entries. None worked on any of our 1100AHx2s. But like I mentioned, there was no problem with the 2011iL-wRMs.

Update - I rebooted the computer, and now it works as expected. That's bizzare.

On RB912UAG-5HPnD (used as AP and ethernet linked to Ubnt Airgrid M5) I've encountered ethernet negotiation issues with 6.30.4; after 1-2 days the link go down and the ubnt device say 'unplugged'.
Downgraded RB912 to 6.27 (with witch the board had worked well for months), now 3 days had passed and ethernet is still ok.

Just a guess ..maybe something related to (Interface/Ethernet/Status Tab) 'Last Link Up Time' and 'Link Downs' counters/functionality ?? (present on 6.30.x+ and not in 6.27)

No. I would like a longer lasting Bugfix release without new features. Our network is no playground. Stability is number one feature.

+1000

Also +1000

No. I would like a longer lasting Bugfix release without new features. Our network is no playground. Stability is number one feature.

+1000

Also +1000

I'm not sure, isn't that what we currently have with v6.30.4? Or you are asking for something else?

I have installed 6.30.4 on a RB750. I did a factory reset. Port flapping occurs on all the LAN ports when connected. I downgraded to 6.29.1. No port flapping occurs. (Port flapping also occurs on 6.31, that is noted in the release notes for 6.32rc6, but it implies that the problem was introduced in 6.31. The problem seems to have been introduced in 6.30 and is still present in 6.30.4.) By the way, the port flapping is fixed in 6.32RC6, but if you do a reset configuration with 6.32rc6, the configuration goes to a very strange config with no firewall or routing and the IP address of 192.168.88.1 configure only on eth1.

I had the same problem two days ago. After installation 6.32.1 everything is ok.

@normis; Imagine yourself; You are new to Mikrotik, just bought some routers to make some network. Like all software driven devices nowadays first thing you'd look for is if there is a new software/firmware on the manufacturers website. So you go to http://www.mikrotik.com and go to the download section were you'll find a "current" version. As newbee not knowing how the system works you download it, install it and 50% change you're in deep s*it then........ because "current" doesn't mean "stable" it means; "Lets hope this works...."

Or,
You are a network operator and know Mikrotik has regular updates on their software; so you spend some time to develop an automated upgrade system/script because manually that is just too much work. So you arranged the routers to regularly check the server to see if there is a new OS version and the router downloads it and installs it. Off course, the script only looks for the "current" version, yet again, next days you'll find out half your network went down the drain. Havoc everywhere.....

Or,
You are a long time forum member and user of Mikrotik and because of that you never trust new software releases immediately after they have been issued. So you wait and monitor the forum until you think the latest OS with some new features you'd like is stable enough to download. So, you start the auto upgrade script, or do it manually like a robot. In doing so after some upgrades you suddenly look at the upgraded boards and; "f*ck, they just put a new OS as current, I wasn't prepared for that! Let's hope it works...... fingers crossed!" and yes, after some hours (or immediately if you are lucky) boards start to crash....


These are just some examples why the "current" version that is given as default on the website or on the upgrade servers should be the last known stable one. If that is the one with several bugfixes, good. It means the bugs are fixed.

Although the word "current" can mean several things, the impression is created that it is a version that is recommended to use. And if it is recommended by the manufacturer to use it normally spoken means "it is stable". But not with Mikrotik, in Mikrotik it means " we hope it works, lets see how many people find issues so we can start correcting them...."

Hence my fellow forum users state

No. I would like a longer lasting Bugfix release without new features. Our network is no playground. Stability is number one feature.

It means that a "stable" version should be the preferred option on the website and upgrade servers by default.

Imho "current" should be skipped in terminology and start using the words "stable" for bug fixed versions and "New" for versions that are currently called "current". And then you can still have the "release candidates".

If Mikrotik maintains putting the label "current" on versions that are at times not by far matured, you'll find more and more frustrated users. I don't think that is what you are looking for?

[Another alternative label for the present "current" versions might be "play".... so if you want to play with your network go for it.... but if you don't like gambling, stay away from it...]

@normis
We need at least one 100% stable release of 6.xx, with no major bugs - and yes, 6.30.4 is the best at the moment .
Some new additional features in ROS are less important for us (speaking as an WISP network administrator).

Also, I agree with your new release policy except in one detail - please make the latest stable bugfix release default option for download/upgrade instead of the current one, it is safer option for most cases.
I think that way both of us will have less problems.
If someone really wants to test some new feature(s) then let them manually chose and download the latest current release.

One more advice, please please please keep your syntax coherent, don't ever change it for existing features, it gives us hell for automating tasks.

@WirelessRudy - 100% agree again

I'm not sure, isn't that what we currently have with v6.30.4? Or you are asking for something else?

No not asking for anything else, I like many other WISP's grade stability as number one and new features second

please make the latest stable bugfix release default option for download/upgrade instead of the current one,

We can't do that, because old versions know nothing of the chain system. They check the "current" and we can't change this without an upgrade.

Please post any remaining issues you find in this 6.30.4 release! This is important, to make this version truly stable.

Yes, naming the versions is not easy.

At the moment we are still debating how this should work in the long term.
Right now:

bugfix = stable, only bug fixes are included, no risky new features (A)
current = latest version with new features and bug fixes also (A + B)
release candidate = nightly build, not much testing, release as soon as usable, includes A + B + C changes that are not thoroughly tested yet
development = alpha/beta of v7 when we release it (not yet available)

The important question is, should we replace 6.30.4 with 6.31.1 when we have important issues in v6.31, or ... if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

While I agree with the development format but must voice concerns about RC, especially as they contain A+B and are not
thoroughly tested, should RC contain during installation a warning prompt that they are RC and be warned? "Do you want to install Yes/No"
Bugfix and Current don't need this warning prompt as I assume more thorough testing is done?

Please post any remaining issues you find in this 6.30.4 release! This is important, to make this version truly stable.

Yes, naming the versions is not easy.

At the moment we are still debating how this should work in the long term.
Right now:

bugfix = stable, only bug fixes are included, no risky new features (A)
current = latest version with new features and bug fixes also (A + B)
release candidate = nightly build, not much testing, release as soon as usable, includes A + B + C changes that are not thoroughly tested yet
development = alpha/beta of v7 when we release it (not yet available)

The important question is, should we replace 6.30.4 with 6.31.1 when we have important issues in v6.31, or ... if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

While I agree with the development format but must voice concerns about RC, especially as they contain A+B and are not
thoroughly tested, should RC contain during installation a warning prompt that they are RC and be warned? "Do you want to install Yes/No"
Bugfix and Current don't need this warning prompt as I assume more thorough testing is done?

Well, we have seen that actually "Current" does need same warning. How many of us gone wrong here, now and in the past?

There should be only one version for default downloads and that should be a "Stable" version. And that should be the only "current" version. Anything else is either 'development', 'release candidate' or 'EOS' (End of support).

And referring to normis his schedule; Like some proposed before, if certain version after some bugfixes becomes stable for some period, some weeks for instance, only than a version can become "Stable"

So although 6.30.4 is still a bugfix, maybe after two more weeks without any new surprises it could be renamed into 6.30.SR meaning Stable Release. Until that moment 6.29 or even 6.27 should be the "current" on the website. (This is due the transition we are in on the moment)

6.32 should still be a "rc" and 6.32.x will be bugfixes to the rc. Only if for some weeks no more bugs are found it can be renamed into 6.32.SR and become the default download option at that present to be labelled as "current". (Well; "Stable")

6.32 incorporates the new software channels so from 6.32 onwards any user has the option to start 'playing' with new releases and candidates etc. even from within the router's auto upgrade function. Indeed a good idea at least on the website to post a warning on any version that is not yet "Stable Release".

Only this way profesional users can build automated process to upgrade the system. Because only this way a "current" version is 99% guaranteed stable.

This is really the last time I nag about the procedure and propose some changes. Some might think I've got nothing else to do....

please make the latest stable bugfix release default option for download/upgrade instead of the current one,

We can't do that, because old versions know nothing of the chain system. They check the "current" and we can't change this without an upgrade.

You can use two coincident aliases ("current" for old ros and "stable" for newer ros) pointing to actual bugfix releases.
Then you start use a new alias (e.g. develop/new/cuttingedge/..) for actual current releases.

P.S. ..and, please, backport port flapping fixes on 6.30.5 ..on some board (like RB912 I still have to use 6.27)

Only this way profesional users can build automated process to upgrade the system. Because only this way a "current" version is 99% guaranteed stable.

I think I agree with many of the ideas expressed here (mainly: we need releases without bugs, maintened for a long time, even it is means that they lack new features).
But, one thing : you CANNOT blame Mikrotik if your automated update process failed because of new release coming-out at the wrong moment !

What I mean is : if you build automated process to upgrade many devices, you SHOULDN'T use the "simple" auto upgrade command that will one day install a version that you do not want.
First, you SHOULD test (intensively) one release, and once you have validated it on your test device*s*, you update your production devices farm.
And more importantly, in your script, you SHOULD do the upgrade by uploading manually the version that you have (tested+validated+) selected to the device. Basically :
=> scp routeros-mipsbe-6.30.4.npk admin@yourDevice:/
=> /system reboot

[But, one thing : you CANNOT blame Mikrotik if your automated update process failed because of new release coming-out at the wrong moment !

What I mean is : if you build automated process to upgrade many devices, you SHOULDN'T use the "simple" auto upgrade command that will one day install a version that you do not want.
First, you SHOULD test (intensively) one release, and once you have validated it on your test device*s*, you update your production devices farm.
And more importantly, in your script, you SHOULD do the upgrade by uploading manually the version that you have (tested+validated+) selected to the device. Basically :
=> scp routeros-mipsbe-6.30.4.npk admin@yourDevice:/
=> /system reboot

I agree. I don't have such automate process in use anyway. I only mirror what I saw happening with others on this forum. As you can see I am a long term member and I learned already long time ago that installing the "current" version on your production environment is asking for problems.

And yes, I do think you can blame Mikrotik if they put a new release out and call it "current" while it is not by far stable.
[You'll find in the manual several examples how to do it to make your life as operator 'easy'... well, until disaster strikes...]

If tomorrow Microsoft will issue a new Windows patch (that by the millions is manually or automatically downloaded and installed) and the next day they find it has serious new bugs, it will hit the mainstream news channels....
How would dare to blame the user?

No, Mikrotik should not, never and ever, put a version out as the preferred default one (because that is the "current" version) if it is not al least has seen thorough testing...

Of course Mikrotik should not publish buggy releases. Nobody will say "Mikrotik should put more bugs in RouterOS".
But there is also reality of software development, and even with great care, bugs can and will happen and nobody can avoid them at 100%.
So, the question is how to conciliate 2 things : having as-less-buggy-as-possible software (which requires testing before) and releasing new version with new features (which will certainly introduce new bugs).
Because, imagine if everybody use the "bugfix" releases, nobody would use the new releases and nobody will spot the (inevitable) bugs in those, and the new releases will never get bugfix. So, at the end, we stay **forever** with a bug-free release but with nothing new for decades

NB: you are comparing 2 really different things :

1. some professional network administrators that apply MANUALLY (or with script) updates to devices
2. and users (with no tech knowledge) that are subject to AUTOMATIC updates of their windows

Of course Mikrotik should not publish buggy releases. Nobody will say "Mikrotik should put more bugs in RouterOS".
But there is also reality of software development, and even with great care, bugs can and will happen and nobody can avoid them at 100%.
So, the question is how to conciliate 2 things : having as-less-buggy-as-possible software (which requires testing before) and releasing new version with new features (which will certainly introduce new bugs).
Because, imagine if everybody use the "bugfix" releases, nobody would use the new releases and nobody will spot the (inevitable) bugs in those, and the new releases will never get bugfix. So, at the end, we stay **forever** with a bug-free release but with nothing new for decades

Not everybody will use the "bugfix" release only. Only 'no tech knowledge' users and professional network admins will use these initially and for their production environment.

There will be still lots of users that like to play around with new options, features etc. or have been asking for them so they need to be tested and tried.

What I every time have to come back on; 'A' version presented on the website and upgrade servers as "current" has to, will be and should, be seen as a stable version that just works on any routerboard. There might be an occasional small bug left for a rare usage, but in general it should be sound and stable.
This version will be used in a first upgrade if you just bought a new device, weather you are a absolute mikrotik 'dummy' or an experienced operator. This version can be used in upgrading your network, by script or manually. This should be the 'current stable' version. No doubts on that version.... All you want is the latest OS that just works... nothing more.

The moment the experienced want more, or is looking for something specific, or just like to be an 'beta' or 'charlie' tester, he or she, can try a newer version. That newer version might solve his specific need, or just brings something newer, better even. But at a cost; there might still be some bugs.
Doesn't matter, I am sure anybody that want to try such version should be aware of the cost in trying something new that is not completely mature.

The bottom line is; Not making any choice should give you a stable version, that can be called "current" (Not my choice of wording.)
If you want to try something new, YOU should have to make the choice.

Now its just the other way around......

NB: you are comparing 2 really different things :

1. some professional network administrators that apply MANUALLY (or with script) updates to devices
2. and users (with no tech knowledge) that are subject to AUTOMATIC updates of their windows

I consider myself pretty professional, my existence depends on the money I make with my network, but still. Let me explain what happend to me once or twice;

I have almost 800 MT units. I'd like to follow upgrade versions to improve my network to the edge, but not at any cost.
So how is my behaviour (I am sure a lot will do the same):
When a new version is out I follow the forum for at least a week to see if there are any issues. I there are issues that I think might hurt my network, I don't touch it.
If I think that there are little issues or the issues are not having effect on my network because they ocurre on configs I don't use, I can try it.
I start usually with brand new client units that are to be used and get their pre-config.
If they work in the field for a while and I do more and more than I move to some lesser important units close to home or easy to fix.
If still it all looks to go fine I might start with one small PtMP client network. I manually start upgrading all CPE's, one by one.
Since I have about 800 units to go this is a process that can take some weeks.
So, after some days doing some PtMP networks I finally go for some of the bigger AP's. 30, 40 CPE's. So you develop a sort of habit in doing how you do it, manually.
What happened now a couple of times? Well, without any notificación the 'current' version was replaced by a newer "current" version. I took some upgrade before I actually noticed it! Specially because such new version initially worked fine.
But I found myself suddenly upgrading production units into a new release version that might not be that safe as I thought I was upgrading....... bugger... fingers crossed they'd stay alive.

Now this would not be an issue as long as you could take it for granted a "current" version is sound and safe. But just recently we, and MT, just saw a version released (6.31) that was obviously not safe at all. And its not the first time this happened!

If MT would have developed a much more conservative strategy in publishing versions as "current" this would never had happend. By not changing their policy such 'mistakes' are prone to happen again and again, until all confidence in MT ROS is gone.

And remember, confidence goes by horse, but only comes back on foot.....

Because, imagine if everybody use the "bugfix" releases, nobody would use the new releases and nobody will spot the (inevitable) bugs in those, and the new releases will never get bugfix. So, at the end, we stay **forever** with a bug-free release but with nothing new for decades

One can solve that dilemma by extensive in-house testing before releasing new code at the first place.
So instead of that, all of us (paying costumers) have to agree to be test subjects in ongoing and never-ending software development??? Well, I would rather not to be a test subject by default.

We can't do that, because old versions know nothing of the chain system. They check the "current" and we can't change this without an upgrade.

Today we have a Mikrotik RouterOS device asking Mikrotik software central "Hey dear Mikrotik server, I'm RouterOS device with software version x.yy, which is the best software for me to download and install?" and you want to tell me you can't change server's default answer to that question?

No it does not work that way. Like I said, it is the same file for the v6.32 and for v6.29. If we change the answer to "v6.30.4" then also v6.32 will not receive updates to v6.33

Fine if it cannot be changed for 6.33, but you can fix it in 6.33 for 6.34

6.32 Current looks for upper Current. It gets 6.33 unstable Current

6.33 Current looks for upper Current or Unstable, it gets 6.34 Unstable or 6.34.1 stable Current

6.34 Unstable looks for upper Current or Unstable, it gets 6.34.1 stable Current

6.34.1 looks for upper Current, it gets 6.34.3 stable Current (assuming 6.34.2 remains Unstable)

Please post any remaining issues you find in this 6.30.4 release! This is important, to make this version truly stable.

Yes, naming the versions is not easy.

At the moment we are still debating how this should work in the long term.
Right now:

bugfix = stable, only bug fixes are included, no risky new features (A)
current = latest version with new features and bug fixes also (A + B)
release candidate = nightly build, not much testing, release as soon as usable, includes A + B + C changes that are not thoroughly tested yet
development = alpha/beta of v7 when we release it (not yet available)

The important question is, should we replace 6.30.4 with 6.31.1 when we have important issues in v6.31, or ... if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

Normis,

I would love to see 6.30.x stay around for at least 6 months if not longer and only move to the next bugfix when it is incredibly stable. Many other network vendors will keep bugfix only versions around for a very long time so that there is a clear choice for stability vs. new features over a long period of time. Now that there is a separate version for new features, I believe there is much greater value in keeping the bugfix as stable as possible than trying to move too quickly to the next bugfix release.

I think realistically, you might only have 2-3 bugfix versions to increment fixes in every major release. Something like

6.1.x - Bugfix at the beginning of the major release
6.15.x - Bugfix towards the middle of the major release
6.30.x - Bugfix towards the end of the major release

Obviously not every bugfix would be spaced that neatly apart, but it illustrates the idea.

I applaud the effort at MikroTik to work on improving the software development model to meet the needs of the vast majority of customers. Well done!

check-gateway=arp is flakey. at least when there are 100,000+ routes. fails over the secondary routes even though arp entry still exists and connectivity to original gateway is never lost. switched to =ping and works fine. supout sent.

No it does not work that way. Like I said, it is the same file for the v6.32 and for v6.29. If we change the answer to "v6.30.4" then also v6.32 will not receive updates to v6.33

And this is great! It should not be possible to automatically upgrade to the unstable version. If you want upgrade to unstable version - do it manualy.

No, if you are on the unstable stream, it should be possible to just click to get the next one.

I don't want to manually upgrade anymore.

However, a confirmation dialog would be welcome.

No, if you are on the unstable stream, it should be possible to just click to get the next one.

I don't want to manually upgrade anymore.

Well, as long as MT regularly put unstable versions as "current" than don't complain next time you'll find yourself automatically installed disaster on your network......

[Or you make a new upgrade script that only installs latest bugs fixed versions. Now that is possible too. But then it won't make a lot of sense to have a script, because once the bugs are fixed that version won't see any new coming anymore..

Yet again it proves why MT should get rid of "current" and use "stable" as the default version. Than it can follow the upgrade's timeline even if it goes to higher family version. As long as they make sure it is a 99% safe version automated processes can be used again. Now it's more like Russian Roulette......]

There seems to be a serious memory leak in this release that's triggered by viewing ip/firewall/connections in webfig. Once you bring up that page, available memory starts dropping and doesn't stop until you stop the www service. Exiting the browser alone doesn't help. It took my RB912 with 64mb memory only 3 minutes to go from 32mb avail to 2mb avail and a watchdog reboot. This is with about 500-700 connections in the table.

Support ticket created with supout.rif

Is 6.30.5 on the roadmap?

There seems to be a serious memory leak in this release that's triggered by viewing ip/firewall/connections in webfig. Once you bring up that page, available memory starts dropping and doesn't stop until you stop the www service. Exiting the browser alone doesn't help. It took my RB912 with 64mb memory only 3 minutes to go from 32mb avail to 2mb avail and a watchdog reboot. This is with about 500-700 connections in the table.

Support ticket created with supout.rif

I am unable to repeat this behavior on any of my routers here. I can leave this page open, but Free Memory stays solid and does not change. Please tell me the number of your support ticket, so I can check the status.

Is 6.30.5 on the roadmap?

Do you have any issues that we need to fix?

I have a problem to add ipv6 pool in From Pool field when i add ::/64 ipv6 Addresses.
I make a ipv6-pool in DHCPv6 client but this pool cant display at From Pool filed when i add ::/64 ipv6 Addresses.
When i load a backup from previous ROS, all work ok.
When i make reset configure add configure the router from beginning, i have the above problem.
In addition i have always connect/disconnect when i make pppoe client connections with ipv6 enable.
With previous backup file i dont have the same problem.
The configuration is exactly same.
The only different is I make reset configuration.
I have CRS109-8G-1S-2HnD-IN and the old board is RB951G-2HnD.
The problem is the same with this:
http://forum.mikrotik.com/viewtopic.php?t=61976

There seems to be a serious memory leak in this release that's triggered by viewing ip/firewall/connections in webfig. Once you bring up that page, available memory starts dropping and doesn't stop until you stop the www service. Exiting the browser alone doesn't help. It took my RB912 with 64mb memory only 3 minutes to go from 32mb avail to 2mb avail and a watchdog reboot. This is with about 500-700 connections in the table.

Support ticket created with supout.rif

I am unable to repeat this behavior on any of my routers here. I can leave this page open, but Free Memory stays solid and does not change. Please tell me the number of your support ticket, so I can check the status.

The ticket was 2015091366000031 and I got a response that the fix was in 6.32.1 and that does appear to be the case.

There is a bug in OSPF interfaces.
In Winbox when you add a comment to a ospf interface this goes down and stay for some seconds in the waiting state so run the dijkstra algoritm again and then it return in running state.