What’s new in 4.9:
*) fixed problem - some of the bridge ports stayed invalid after reboot;
*) console - added ‘/port remote-access export’ command;What’s new in 4.8:
*) added support for second serial port on RB800/RB1100;
*) fixed problem - WinBox crashed while opening VAP interface;
*) dhcp server - fixed possible inactive dhcp server in case of many
dhcp leases with address-pool enabled (broken in v4.7);
*) dhcp server - show non-printable option 82 agent-circuit-id and
agent-remote-id values in hexadecimal notation
(in the same way as client-id is shown);
*) api - can supply password to ‘/system/upgrade/upgrade-package-source/add’;
*) console - fixed bug that caused “cannot set …” error when using
some properties in ‘find’ commands;
*) api - ‘print’ command was not showing values of some properties
such as ‘servers’ in “/ip/dns”;
*) show old software id in export file header;
Hmmm, it seems Mikrotik wants to sell us quickly new licenses 
The OLD problem with instability Bridge+nstreme have anyone tested with this new version??? finally fixed or continues???
BR
They are actually slowing down a little bit thankfully. You can see the pace tempered a little in 2009 onwards. I’d rather have a handful of mostly good releases compared to a rushed release made of duct tape, string and mystery meat. They still have a ways to go of course with their testing and changelog both. Many of the releases of old were quick successions to fix things that shouldn’t have gotten out, sort of like 4.9 is.
Here’s how things have been released over the past few years. My downloads are usually within a few days of the release (Doesn’t mean I use it that fast though)
drwxr-xr-x 2 root root 4096 2005-12-16 10:00 2.9.9
drwxr-xr-x 2 root root 4096 2005-12-16 10:00 2.9.8
drwxr-xr-x 2 root root 4096 2005-12-16 10:01 2.9.10
drwxr-xr-x 2 root root 4096 2006-01-11 14:16 2.9.11
drwxr-xr-x 2 root root 4096 2006-01-17 06:42 2.8.28
drwxr-xr-x 2 root root 4096 2006-02-06 15:51 2.9.12
drwxr-xr-x 2 root root 4096 2006-02-20 09:54 2.9.13
drwxr-xr-x 2 root root 4096 2006-03-09 20:48 2.9.16
drwxr-xr-x 2 root root 4096 2006-03-10 22:58 2.9.17
drwxr-xr-x 2 root root 4096 2006-03-22 11:57 2.9.18
drwxr-xr-x 2 root root 4096 2006-04-05 13:40 2.9.19
drwxr-xr-x 2 root root 4096 2006-04-13 14:55 2.9.20
drwxr-xr-x 2 root root 4096 2006-04-20 16:41 2.9.21
drwxr-xr-x 2 root root 4096 2006-04-21 10:24 2.9.22
drwxr-xr-x 2 root root 4096 2006-04-27 10:42 2.9.23
drwxr-xr-x 2 root root 4096 2006-05-18 11:55 2.9.24
drwxr-xr-x 2 root root 4096 2006-06-07 21:39 2.9.25
drwxr-xr-x 2 root root 4096 2006-06-15 15:36 2.9.26
drwxr-xr-x 2 root root 4096 2006-07-03 11:46 2.9.27
drwxr-xr-x 2 root root 4096 2006-08-09 13:54 2.9.28
drwxr-xr-x 2 root root 4096 2006-08-22 11:29 2.9.29
drwxr-xr-x 2 root root 4096 2006-09-08 09:13 2.9.30
drwxr-xr-x 2 root root 4096 2006-10-03 09:54 2.9.31
drwxr-xr-x 2 root root 4096 2006-10-03 09:56 3.0b1
drwxr-xr-x 2 root root 4096 2006-10-12 16:37 2.9.32
drwxr-xr-x 2 root root 4096 2006-10-19 21:10 2.9.33
drwxr-xr-x 2 root root 4096 2006-10-20 10:06 2.9.34
drwxr-xr-x 2 root root 4096 2006-11-06 14:48 2.9.35
drwxr-xr-x 2 root root 4096 2006-11-20 11:33 2.9.37
drwxr-xr-x 2 root root 4096 2006-11-25 17:08 2.9.38
drwxr-xr-x 2 root root 4096 2007-01-05 17:16 2.9.39
drwxr-xr-x 2 root root 4096 2007-01-05 17:17 3.0b5
drwxr-xr-x 2 root root 4096 2007-02-28 13:28 3.0b6
drwxr-xr-x 2 root root 4096 2007-03-15 16:08 2.9.40
drwxr-xr-x 2 root root 4096 2007-03-20 14:58 2.9.41
drwxr-xr-x 2 root root 4096 2007-04-04 14:51 2.9.42
drwxr-xr-x 2 root root 4096 2007-04-04 14:52 3.0b7
drwxr-xr-x 2 root root 4096 2007-05-14 11:33 2.9.43
drwxr-xr-x 2 root root 4096 2007-05-29 10:14 3.0b8
drwxr-xr-x 2 root root 4096 2007-05-31 16:34 3.0b9
drwxr-xr-x 2 root root 4096 2007-06-29 17:17 2.9.44
drwxr-xr-x 2 root root 4096 2007-07-04 18:33 3.0b10
drwxr-xr-x 2 root root 4096 2007-08-02 12:29 2.9.45
drwxr-xr-x 2 root root 4096 2007-08-02 12:30 3.0rc1
drwxr-xr-x 2 root root 4096 2007-08-13 14:24 3.0rc2
drwxr-xr-x 2 root root 4096 2007-08-14 09:31 2.9.46
drwxr-xr-x 2 root root 4096 2007-08-23 17:12 3.0rc3
drwxr-xr-x 2 root root 4096 2007-08-31 05:48 3.0rc4
drwxr-xr-x 2 root root 4096 2007-09-18 20:24 3.0rc5
drwxr-xr-x 2 root root 4096 2007-10-03 19:57 3.0rc6
drwxr-xr-x 2 root root 4096 2007-10-20 07:41 3.0rc7
drwxr-xr-x 2 root root 4096 2007-10-20 07:44 2.9.48
drwxr-xr-x 2 root root 4096 2007-10-24 22:52 3.0rc8
drwxr-xr-x 2 root root 4096 2007-10-26 10:13 3.0rc9
drwxr-xr-x 2 root root 4096 2007-11-10 20:28 2.9.49
drwxr-xr-x 2 root root 4096 2007-11-10 20:30 3.0rc10
drwxr-xr-x 2 root root 4096 2007-11-27 16:45 3.0rc11
drwxr-xr-x 2 root root 4096 2007-12-11 10:49 3.0rc13
drwxr-xr-x 2 root root 4096 2008-01-10 22:28 3.0rc14
drwxr-xr-x 2 root root 4096 2008-01-25 21:05 3.1
drwxr-xr-x 2 root root 4096 2008-01-25 21:05 3.0
drwxr-xr-x 2 root root 4096 2008-02-01 21:13 3.2
drwxr-xr-x 2 root root 4096 2008-02-15 10:14 3.3
drwxr-xr-x 2 root root 4096 2008-02-20 11:39 2.9.50
drwxr-xr-x 2 root root 4096 2008-03-04 16:26 3.4
drwxr-xr-x 2 root root 4096 2008-03-04 17:17 2.9.51
drwxr-xr-x 2 root root 4096 2008-03-19 10:25 3.5
drwxr-xr-x 2 root root 4096 2008-03-21 15:21 3.6
drwxr-xr-x 2 root root 4096 2008-04-07 11:31 3.7
drwxr-xr-x 2 root root 4096 2008-05-08 14:37 3.8
drwxr-xr-x 2 root root 4096 2008-05-12 15:12 3.9
drwxr-xr-x 2 root root 4096 2008-06-17 17:41 3.10
drwxr-xr-x 2 root root 4096 2008-08-11 22:26 3.11
drwxr-xr-x 2 root root 4096 2008-08-12 23:33 3.12
drwxr-xr-x 2 root root 4096 2008-08-22 11:42 3.13
drwxr-xr-x 2 root root 4096 2008-09-12 11:38 3.14rc1
drwxr-xr-x 2 root root 4096 2008-09-19 09:50 3.14
drwxr-xr-x 2 root root 4096 2008-10-16 21:14 3.15
drwxr-xr-x 2 root root 4096 2008-11-04 19:33 3.16
drwxr-xr-x 2 root root 4096 2008-12-05 14:05 3.17
drwxr-xr-x 2 root root 4096 2008-12-05 14:09 4.0b1
drwxr-xr-x 2 root root 4096 2009-01-10 16:01 3.18
drwxr-xr-x 2 root root 4096 2009-01-16 13:22 3.19
drwxr-xr-x 2 root root 4096 2009-01-28 11:55 3.20
drwxr-xr-x 2 root root 4096 2009-02-27 11:58 3.21
drwxr-xr-x 2 root root 4096 2009-03-16 10:02 3.22
drwxr-xr-x 2 root root 4096 2009-03-20 09:28 4.0b2
drwxr-xr-x 2 root root 4096 2009-05-18 14:48 3.23
drwxr-xr-x 2 root root 4096 2009-05-22 11:52 3.24
drwxr-xr-x 2 root root 4096 2009-05-22 11:55 4.0b3
drwxr-xr-x 2 root root 4096 2009-06-15 10:54 3.25
drwxr-xr-x 2 root root 4096 2009-07-15 09:05 3.26
drwxr-xr-x 2 root root 4096 2009-07-17 14:43 3.27
drwxr-xr-x 2 root root 4096 2009-08-09 17:04 3.28
drwxr-xr-x 2 root root 4096 2009-09-19 21:18 3.30
drwxr-xr-x 2 root root 4096 2009-09-25 11:17 4.0rc1
drwxr-xr-x 2 root root 4096 2009-10-13 09:26 4.0
drwxr-xr-x 2 root root 4096 2009-10-16 10:26 4.1
drwxr-xr-x 2 root root 4096 2009-10-27 21:41 4.2
drwxr-xr-x 2 root root 4096 2009-12-03 11:57 4.3
drwxr-xr-x 2 root root 4096 2009-12-21 14:14 4.4
drwxr-xr-x 2 root root 4096 2010-01-13 15:47 4.5
drwxr-xr-x 2 root root 4096 2010-04-02 15:35 5.0b1
drwxr-xr-x 2 root root 4096 2010-04-19 17:20 4.6
drwxr-xr-x 2 root root 4096 2010-04-28 16:37 4.8
drwxr-xr-x 2 root root 4096 2010-04-30 11:10 4.9
drwxr-xr-x 2 root root 4096 2010-04-30 11:13 5.0b2
No you can’t download this. It’s on a private internal server. Don’t ask for old versions from me.
If you want stability, you can always purchase Cisco for 20 times or more what I paid for Mikrotik and not get near the features. Personally, I can live with the changes and the occasional hick-up..They fix it in the end. You can always keep what you are using and wait to upgrade later when all the bugs have been vetted out.
-tp
I guess you dont have customers on your network right ? 
))
More QA always good. Mikrotik need to make beta for each release with longer testing. Would prefer longer time between release with less bugs rather than fix one, create new one.
i little cosmetic bug in 4.8 and 4.9.Last seen at dhcp server leases shows incorrect data
What you mean when you say “incorrect data” ?
-tp[/quote]
I guess you dont have customers on your network right ? ))[/quote]
Or you just run software updates the day they appear across a live network without testing in a beta environment or even waiting to read some feedback in a forum?
I just read here for a few days first, if nothing crops up in the forum and I have a requirement to upgrade for some reason ,then go ahead and update on a link close to you that you use perhaps? If nothing goes wrong and you see the improvement you needed then go ahead and update the rest of your network when your happy.
I’ve never had a problem being careful, and it’s not like every other company in the computing business cisco included doesn’t have bugs is it?
If your in a commercial environment it’s all part of the skill required to do this.
I think your dreaming if you think any company can release fully bug free software every go?
But a company can have a battery of tests that they run every new release against to ensure nothing broke. Every time an issue is reported you add it to the test battery. After a while you have a huge number of tests that are ran. These can either be executed by a human (tedius, error prone), or by automation. The more difficult issues are ones that take time to appear, or require complicated triggers, but when you have access to the internal state of the router, you can devise tests that look for anomalies, which might appear much sooner than it would manifest itself externally. Also, you could have a device which sits in the network and snoops on OSPF and/or BGP, DCHP, and other protocols and flags anything that doesn’t look proper.
Basically, you need someone who’s job it is to reproduce reported issues, and design/build generalized tests for them that you can run against all your products that run said software.
On the more long-term, don’t introduce errors to start with front,
a technique that is helpful is design-by-contract, which unfortunately, most programming languages don’t support or encourage.
Design-by-contract can also be used in deployed stuff, and when implemented properly can catch an error immediately and point the finger directly at the component (and specific part of that component) that is to blame, which usually makes fixing the problem simple. This can be used on products in the field, where said error could be reported to the log and a corrective action of some sort taken (such as generating an autosupout with details of the problem, and restarting DHCP, for hypothetical example). In areas where performance is critical design-by-contract can even be selectively enabled/disabled. (i.e. you notice some problem with your router, turn on “detect/report errors” feature, and reboot the router and wait til it happens again, or make it happen again).
However, design-by-contract is so effective that errors are almost always caught immediately in internal testing/development, and it can be disabled in deployed software (but shouldn’t be, except in performace critical sections, unless you’re sure your internal testing methodology tests every possible code path).
This all of course is easier written than done; but just because most companies may not do it, there are in fact techniques to produce error free products, but virtual 100% error free is usually more expense than dealing with the consequences of an error unless you’re producing nuclear reactors/weapons or medical devices or other human-life related products (like airplanes), or spacecraft where a truck-roll isn’t feasible or VERY expensive (not that some medical device and spacecraft companies haven’t tried to cut corners anyway).
The Art Of Computer Programming also talks about techniques that can be used to produce error-free software.
Common-sense says you can’t produce bug-free software. Common-sense says the world is flat.
Both are wrong.
still bad ping.. 
[root@PC-ROUTER] > ip add pr
Flags: X - disabled, I - invalid, D - dynamic
ADDRESS NETWORK BROADCAST INTERFACE
0 192.168.2.254/30 192.168.2.252 192.168.2.255 eth3-REMOTE
[root@PC-ROUTER] > ping 192.168.2.254
192.168.2.254 64 byte ping: ttl=64 time=6 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
192.168.2.254 64 byte ping: ttl=64 time=9 ms
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 6/8.7/9 ms
root@PC-ROUTER] > sys resou pr
uptime: 28m13s
version: “4.9”
free-memory: 1011164kB
total-memory: 1025552kB
cpu: “Intel(R)”
cpu-count: 2
cpu-frequency: 1795MHz
cpu-load: 0
free-hdd-space: 217393kB
total-hdd-space: 247915kB
write-sect-since-reboot: 632
write-sect-total: 632
architecture-name: “x86”
board-name: “x86”
platform: “MikroTik”
still? compared to what?
p.s. are you pinging router’s local address?..
yes.. compare with ROS 3.xx normally ping <1ms to router local address
at least in v4.6 I don’t have this problem (current load is ~500 Mbps):
[admin@MikroTik] > /ping 192.168.0.251
192.168.0.251 64 byte ping: ttl=64 time<1 ms
192.168.0.251 64 byte ping: ttl=64 time<1 ms
192.168.0.251 64 byte ping: ttl=64 time<1 ms
192.168.0.251 64 byte ping: ttl=64 time<1 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0/0.0/0 ms
[admin@MikroTik] >
Just tried a little experiment:
Two 4.9 routers, each rb433AH:
ping to self (loopback bridge):
xx.xx.xx.68 64 byte ping: ttl=64 time=2 ms
xx.xx.xx.68 64 byte ping: ttl=64 time=9 ms
xx.xx.xx.68 64 byte ping: ttl=64 time=1 ms
xx.xx.xx.68 64 byte ping: ttl=64 time=9 ms
xx.xx.xx.68 64 byte ping: ttl=64 time=9 ms
ping to neighbor’s loopback bridge:
xx.xx.xx.69 64 byte ping: ttl=64 time<1 ms
xx.xx.xx.69 64 byte ping: ttl=64 time<1 ms
xx.xx.xx.69 64 byte ping: ttl=64 time<1 ms
xx.xx.xx.69 64 byte ping: ttl=64 time<1 ms
And similar results when doing the reverse.
xx:xx:xx:xxf3:xx:xx:xx:xx 64 byte ping: ttl=64 time=6 ms
xx:xx:xx:xxf3:xx:xx:xx:xx 64 byte ping: ttl=64 time=9 ms
xx:xx:xx:xxf3:xx:xx:xx:xx 64 byte ping: ttl=64 time=9 ms
xx:xx:xx:xxf3:xx:xx:xx:xx 64 byte ping: ttl=64 time=1 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1/6.2/9 ms
xx:xx:xx:xxf2:xx:xx:xx:xx 64 byte ping: ttl=64 time<1 ms
xx:xx:xx:xxf2:xx:xx:xx:xx 64 byte ping: ttl=64 time<1 ms
xx:xx:xx:xxf2:xx:xx:xx:xx 64 byte ping: ttl=64 time<1 ms
xx:xx:xx:xxf2:xx:xx:xx:xx 64 byte ping: ttl=64 time<1 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0/0.0/0 ms
From 4.9 is possible downgrade to 3.30?
sure, what’s problem?
It’s a dangerous downgrade. Check your wireless and frequencies.
I don’t mind the router replying to local pings slowly. If this means that the routing process has higher priority - then fine. What do I care about functionality that does not need to be as fast as what I put that machine there to do - to forward, route my packets with lightning speeds.
In fact there are a lot of local processes and stuff happening on the router that I want to be with less priority than the routing. For example when a router replies to TCP SYN with a TCP RST. When the router replies with ICMP messages. I wonder if MikroTik care to take this matter under control. Maybe it is predetermined by whats underneath - the Linux code etc.
morgy, I would not recommend the downgrade.
What is the reason you want to downgrade the router?