What's new in 5.16 (2012-May-09 17:23):

*) webfig - fixed problem when new item addition to status page in design skin mode
did not work;
*) add pw-type option for BGP VPLS;
*) fixed mac telnet - sometimes did not work if more than one mac level path
to destination;
*) user - fixed problem when adding new users from console it's password was not set;
*) reset packet mark when encapsulating/decapsulating from eoip,ipip,gre,eoipv6,ipipv6,gre6 tunnels
*) Fixed a wireless issue, which was introduced in v5.15 (wireless problem with many wireless clients to an AP)

http://www.mikrotik.com/download.html

*) reset packet mark when encapsulating/decapsulating from eoip,ipip,gre,eoipv6,ipipv6,gre6 tunnels

yahooo! at last

my [Ticket#2009090566000031] was about this

by the way, have you changed the behaviour also for pptp and l2tp? they are affected too but are not in list for some reason...

What is the wireless problem that was fixed?

there were many posts on the forum, about weird AP behaviour in v5.15

What about the fix for poe power issues in the 750UP ?

Can somebody explain wireless problem fixed? Exactly please

Its the issue that an AP would stop passing traffic for some reason. I have just installed this version on three APs to see if it is fixed.

Has no effect on the dynamically created VPLS tunnels e.g.

*) reset packet mark when encapsulating/decapsulating from eoip,ipip,gre,eoipv6,ipipv6,gre6 tunnels

Why? I'm using this behavior to marking packet for traffic shaping. For example if I have two ipip tunnels over one ethernet interface, I can mark SQL packets in both tunnels and then shape in tree queues on ethernet interface with other (non tunnel) traffic. When encapsulation will reset packet mark, I can't do this

After upgrade from 5.15 to 5.16 RB433Gl change CPU freq. to 800 Mhz is it how it should be?

*) reset packet mark when encapsulating/decapsulating from eoip,ipip,gre,eoipv6,ipipv6,gre6 tunnels

Why? I'm using this behavior to marking packet for traffic shaping. For example if I have two ipip tunnels over one ethernet interface, I can mark SQL packets in both tunnels and then shape in tree queues on ethernet interface with other (non tunnel) traffic. When encapsulation will reset packet mark, I can't do this

Sorry, but are you saying that you are dropping packets after they are encapsulated into IPIP?? what is the point in that? You can always use global-out to work with all packets before they are separated to individual interfaces.

normis wrote:
*) reset packet mark when encapsulating/decapsulating from eoip,ipip,gre,eoipv6,ipipv6,gre6 tunnels

yahooo! at last

my [Ticket#2009090566000031] was about this

by the way, have you changed the behaviour also for pptp and l2tp? they are affected too but are not in list for some reason...

PPTP and L2TP already worked in described behavior, that's why they are not changed, all tunnels work identically now.

What about this issue .... After reboot files are gone.

Best Regards,

Daniel

sergejs
Announcement by email ?

sergejs
Announcement by email ?

do you really need it ? You already saw it here.

This entry from the changelog is not on the download site.. Why not?

*) Wireless problem fixed


Yeah, where is the email announcement?

sergejs
Announcement by email ?

do you really need it ? You already saw it here.

Now I don't, but when I was less active user on the forum I knew about updates only by email - this was very helpful for me.

Anyway, I got the email, you will probably get it later. Emails are sent in order of user registration date.

Thank you normis

sorry for the off-top:
where is your nick burgundy color ?

during some forum user group reorganization, all users now display "registered user" group by default. it doesn't mean I don't have ability to ban somebody

*) reset packet mark when encapsulating/decapsulating from eoip,ipip,gre,eoipv6,ipipv6,gre6 tunnels

Why? I'm using this behavior to marking packet for traffic shaping. For example if I have two ipip tunnels over one ethernet interface, I can mark SQL packets in both tunnels and then shape in tree queues on ethernet interface with other (non tunnel) traffic. When encapsulation will reset packet mark, I can't do this

+1
WTF?! That was a great feature, not a bug !!
If people want to reset marks, couldn't they add a rule that overwrites the previous encapsulated mark, and then to start with new rules ?

We are marking packets before encapsulation (based on TOS/DSCP, or any other firewall matcher), and then we are performing shaping or DSCP marking of the encapsulated flows depending on these marks. This features available for all encapsulated traffic type would be better (PPPoE for vlan priority marking, L2TP for DSCP marking of the UDP, and so on...).

in JunOS that's a feature. See copy-tos-to-outer-ip-header for example.

In consequence can someone clearly explain how to propagate, from this new ROS version, packet-marks and/or connection-marks from encapsulated flows to outer encapsulating flows, and this for each encapsulating type (PPPs, GRE/EoIP, IPIP, OVPN, SSLVPN) ?

We are heavily using this feature (I repeat, not a bug like I understand this changelog)...

Whether router problem solved 751U-2HnD? for 5.16 version

Sorry, for repeating myself. But do i understand it correctly?

You mark original packet stream - allow it to be encapsulated (and maybe fragmented into 2 or more packets), and then use queues to limit tunnel packet stream - limitation results into packet drops, so you drop packet that might contain some part or several packets.

Isn't it easier to limit everything before you put it into tunnels?

I personally hate the fact that your global-out captures traffic that you haven't marked. Also i think all tunnels should have exactly the same behavior not one for ppp other for other tunnels

Sorry, for repeating myself. But do i understand it correctly?

You mark original packet stream - allow it to be encapsulated (and maybe fragmented into 2 or more packets), and then use queues to limit tunnel packet stream - limitation results into packet drops, so you drop packet that might contain some part or several packets.

Isn't it easier to limit everything before you put it into tunnels?

I personally hate the fact that your global-out captures traffic that you haven't marked. Also i think all tunnels should have exactly the same behavior not one for ppp other for other tunnels

It may be possible to shape BEFORE encapsulating in most cases, you're right, but in case of mixed trafic outgoing on an interface (encapsulated and not encapsulated) that's should be a problem.

However, about setting vlan-priority or TOS/DSCP on outter traffic based of inner traffic is something important for carrying encapsulated flows over a Diffserv path using features as WMM for 802.11, or similar for WiMax 802.16e/d, for ATM, for licenced radio links using adaptative modulations, satellite links and so on...

I agree that it should be the same behaviour for all encapsulation types, however I'd prefer to have this feature available for these all.

Maybe you need a new feature, instead of how you did it before. Write to support, and describe your goal, we will work out how to solve it.

Maybe you need a new feature, instead of how you did it before. Write to support, and describe your goal, we will work out how to solve it.

Support request is now opened... [Ticket#2012051166000486]
Moreover, this feature has been requested for L2TP in 2010 : "[Ticket#2010050466000476] L2TP packet DSCP reflect" This feature is called "tos reflect" on Cisco routers.

"It's not a bug, It's a feature."

Hi,

*) Wireless problem fixed


is it broken in 5.15 or the Version before ??


Thx

dingsingo

v5.15 introduced a wireless problem with many wireless clients to an AP. v5.16 fixes it.

ok, but non forum users won't know that, because it is still missing in changelog on download site, as MarcusW mentioned earlier:

This entry from the changelog is not on the download site.. Why not?

*) Wireless problem fixed

The PPPoE authentication problem with my provider which i saw in 5.15 seems solved

Tnx,
Marius

ok, but non forum users won't know that, because it is still missing in changelog on download site, as MarcusW mentioned earlier:

This entry from the changelog is not on the download site.. Why not?

*) Wireless problem fixed

Because there are not sure if it's fix, really for that kind of problem need testing and time, install and see u self like I do...

5.16 web-proxy error randomly restarts the routerboard
I'll try to turn it on again and create the USB Flash


5.16 web-proxy má chyby náhodně restartuje routerboard (RB433UAH zdroj 24V 2A)
zkusím jí vypnout a znova vytvořit na USB Flash

edit:

with the web-proxy that is not random, it restarts itself in this version 5.16

s web-proxy to nesouvisí náhodně se to restartuje samo od sebe v téhle verzi 5.16

edit:

upgrade 5.16 > 6.0beta2 => uptime 9h (again OK)

Aktualizoval jsem 5.16 na 6.0beta2 a zdá se, že náhodný restarty routerboardu jsou odstraněny


5.16 is with my configuration routerboard unstable
5.16 je s mojí konfigurací routerboardu nestabilní

The PPPoE authentication problem with my provider which i saw in 5.15 seems solved

Tnx,
Marius

I have problem with PPPoE clients - when their wireless drops, ppp stays on ... since I don't allow two sessions, they can not log in any more ... after update to 5.16 - seems it is the same ?????

Help?

EDIT: 5.15 was out at the same time I replaced one MT (upgraded to 5.15, logically) and, at the same time, while copying the configuration, managed not to set Keepalive Timeout on PPPoE service .............. seems that was my "error" and not faulty 5.15

it's amazing Nstreme is still crippled. P Throughput never exceeds 55,000 even at data rates of 270/270. also random disconnects. I'm now forced to use NV2 for my PtP's, which give high jitter and latency compared to good old Nstreme.

is anyone else REALLY not seeing this? I have over 10 PtP's that I've witnessed this on. roll back to 4.x and I get a solid 144,000 Pthroughput.

I found the Problem - every day MT himself erase ALL subdirs (with all files) on plugged microSD-card.

Have RB1100AH with plugged microSD (8Gb) into slot, using for store boot-images, boot-configs files - receives by client's computers when booting via bootp+DHCP+tftp (all at this MT-routerboard).

I try create (via ftp) on microSD subdir with configations files for remote booting:
------------
...
16 micro-sd1 disk
17 log.1.txt .txt file
18 log.0.txt .txt file
19 micro-sd1/lost+found directory
20 micro-sd1/initrd file
21 micro-sd1/vmlinuz file
22 micro-sd1/pxelinux.0 .0 file
23 micro-sd1/ponix.network .network file
24 micro-sd1/pxelinux.cfg directory
25 micro-sd1/pxelinux.cfg/default file
...
----------
on the next day this dir - /micro-sd1/pxelinux.cfg (with all files) deleted! ((

BTW: how I can use MT-tftp service for uploading logs from booting clients? In example - create the dir and using masks for write-create permission for requests:
req.path: upload/*.log
real path: micro-sd1/upload/
Perm.: write-create
??

updated some MT 400 series devices from 5.12 to 5.16 because of Ether1 link up/down problem

Still Ether1 link up/down ( on RB411 / firm 2.39 ) in Log with 5.16 on one device.

will keep an close eye on other ones.

AlxFirst,
thank you very much for the report.
We are aware of the problem, it will be fixed in the upcoming versions.

hengst,
please contact support with attached support output file and details about device connected to other end.

I have been running 5.16 network wide and it appears to to be stable, and the AP wireless problems we had with 5.15 have not re-appeared. So all looking good, thank you Mikrotik!

Regards
Brian
Zimbabwe

Hello Folks!

Last night and today we upgraded from RoS5.14 to RoS 5.16 (RoS 5.15 had some strange wireless behavior). So far all seems fine, no customer complainments.

If this works well, we will upgrade all remaining sectors to 5.16.

I would like to have from MT best patching practice, what, why, when and how often. Little bit how MT think about it and how they do.

Code: Select all

/interface vpls bgp-vpls set 0 pw-type=tagged-ethernet

Has no effect on the dynamically created VPLS tunnels e.g.

Code: Select all

 1 RDB name="vpls3" mtu=1500 l2mtu=1504 mac-address=02:B8:66:F2:24:E4 arp=enabled 
       disable-running-check=no remote-peer=10.133.200.11 cisco-style=no 
       cisco-style-id=0 advertised-l2mtu=1504 pw-type=raw-ethernet 
       vpls=xxxxx-vpls2 

 2 RDB name="vpls2" mtu=1500 l2mtu=1504 mac-address=02:E6:D8:3F:42:AC arp=enabled 
       disable-running-check=no remote-peer=10.88.88.1 cisco-style=no 
       cisco-style-id=0 advertised-l2mtu=1504 pw-type=raw-ethernet 
       vpls=xxxxx-vpls2

A note for others as it is not obvious, the pw-type setting on BGP based VPLS tunnels changes the NLRI information for compatibility with JunOS devices. It DOES NOT update the pw-type listed in the dynamic VPLS interface stats.

I have been running 5.16 network wide and it appears to to be stable, and the AP wireless problems we had with 5.15 have not re-appeared. So all looking good, thank you Mikrotik!

Regards
Brian
Zimbabwe

Another positive to add: Links that were somewhat marginal are now holding connection a lot better. I am seeing link that would drop every 20-30 minutes for a second or two, now staying connected for over 24 hours, on NV2 and 802.11

I really like this release, it is going to take a lot to get me to move from 5.16.....

Regards
Brian
Zimbabwe

I have been running 5.16 network wide and it appears to to be stable, and the AP wireless problems we had with 5.15 have not re-appeared. So all looking good, thank you Mikrotik!

Regards
Brian
Zimbabwe

Another positive to add: Links that were somewhat marginal are now holding connection a lot better. I am seeing link that would drop every 20-30 minutes for a second or two, now staying connected for over 24 hours, on NV2 and 802.11

I really like this release, it is going to take a lot to get me to move from 5.16.....

Regards
Brian
Zimbabwe

Hello Folks!

Also I confirm now RoS5.16 is OK! We have upgraded from RoS5.14 to RoS5.16 in almost whole our network now, so far no reported problems. RoS5.16 is go for production by our means.

@ sergejs

Have send you one situation regarding Ether1 flapping. to support at mikrotik.com

We use mostly Tp-link home equipment at people houses. this one is going direct to customer Pc on wired side.

did see this ;
on several places. tried it with 5.12 , 5.14 , 5.16

it occurs very random and at diff places. cant bake a cake with it.
shall collect more info for you.

(edit) just found also a SXT ( ROS 5.6 ) --> Tp-Link TL-WR740N with same :
I know the first situation is one where most of the time Pc is in standby ( no trafic ) , looks like it happens most when there is no or little trafic ?

I have lots of setups like yours: sxt+wrt740n. I've done incremental upgrades all the time and thank god never seen such behavior on any ROS version..

hengst,
Are you able to repeat port flapping 100% at 5.16 version?
Thank you very much for the e-mail sent to support, we will research the problem.

@sergejs

From yesterdayevening log file
( RB411(ROS 5.16) --> Pc ethernetport )
Tried to contact this customer about chipset in his Pc, but no luck yet. coming back on that.
this is the customer with most of flapping in log file.
will go back with this one to ROS 4.17 to check if that makes any diff.

As i mentioned , i see it happen on no or very low trafic ether connections.
Have also no complains from customers about it.

( edit )
Found some more SXT on ROS 5.6/7 / Tp-link with same random ether1 info in log file, updated them to 5.16/latest RBfirm and keep eye on those to report coming days.

Can you try putting a switch in the middle?

What model board are you using?

Also can anyone confirm if this works properly on RB-1100?
I am running RB-1100s and so far I can not find any firmware that handles stable on it. I am running 5.4 or 5.6 now, but they reboot on their own sometimes.

Is anyone using this on RB-1100?

how it to explain? intended damage of the protocol nstreme?

NV2

802.11

nstreme

petro25 is it mistake
I see on pic. with 802.11 protocol u have about 221mbit throughput??

Lakis don't trust the eyes?

I can confirm that with 4.17 / RBfirm 2.39 on a RB411 has no issues with Ether1 flapping.
This confirms for me that its not a stupid wiring/contact problem. ( this device is directly connected to PC Lan port )

Same board on 5.12 / 5.14 or 5.16 did show Ether1 up/down random in Log file.
To reproduce that again, i will upgrade back to 5.16 and report.

---------------------
2 SXT devices upgraded from 5.6/7 to 5.16 with RBfirm 2.38 still random Ether1 up/down in Log.
1 SXT device upgraded from 5.6 to 5.16 with RBfirm 2.36 did not show Ether1 up/down in Log. ( updated the RBfirm now to see if it reproduces the flapping )
---------------------

(edit)
how stupid, but i now see 4.17 doesnt report as"Ether up/down"in log file ? but as "device change" ?
can it be than that now iḿ to run 5.x on clients i do get to see more info about Etherlinks and it shows bad wiring ? wich i didnt see on 4.x ? but was always bad afterall ?
i dont see tx/rx errors on ether1 do.

well to test it remote, ping to a local device is an option.

@petro25
Can you explain which protocol and HT chains used in each screenshot as
Picture (1)receive 88/92% 124Mbps, (2) send 221Mbps, (3) 18/69% 4598Kbps, (4) 100/100 39226 Kbps

over each drawing it is written

1-NV2
2-802.11
3-4 -nstreme

over each drawing it is written

1-NV2
2-802.11
3-4 -nstreme

OK - so different HT chains on nstreme caused the different ccq and throughput.

I have a strange problem...
Three brand new RB711 boards (they are in the Mikrotik integraged antenna sextant)

I upgraded the firmware on all three units to 5.16

Using winbox (v.2.2.18)
Two of the units will make a backup (files - backup)
One unit will not make a backup!!! It does not give an error and it behaves just like it would if the backup file was created however there is no backup file created.

The file system is working because from the terminal window I can export a KEY file to the file system.

edit - note - the suspect problem unit is working normal on the network...

Does anybody have any ideas what to try to fix it.
( I am guessing to downgrade it to 5.14 then try again to upgrade it to 5.15 -- but I would like to hear first if anybody else has seen this and what resolved the issue )

Tom Jones

@n21roadie
3- nstreme --- Data Rates - default
4 - nstreme --- Data Rates - configured - only MCS15

@TomjNorthIdaho

netinstall from scratch is the safest way to be sure that your device is not defected.

can it be than that now iḿ to run 5.x on clients i do get to see more info about Etherlinks and it shows bad wiring ? wich i didnt see on 4.x ? but was always bad afterall ?

As far as I remember that is exactly what MT support has been saying here on the forum ever since v5 is out.

Hello Folks!

RoS5.16 seemed to work properly for some week, now problems arrive, but not on all customer antennas.

On 4 RB411 we got random reboots several times per day, which gives a bad customer impact!

Autosupout files are generated and reports sent in to support@mikrotik.com, yet no answer, they have to work on it for some time
We did not have this in RoS 5.14, it come with RoS5.16, I do think it is unlikely antennas is broken in one way or another, they are relatively new (1-2 years and all have UPS and is surge protected).

Anyone who have seen this ?

jan/02/1970 01:00:20 system,error,critical System rebooted because of kernel faiure
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shtudown (cause 1)
jan/02/1970 01:00:21 system,error,critical System rebooted because of kernel failure
jan/02/1970 01:00:21 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:20 system,error,critical System rebooted because of kernel failure
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:21 system,error,critical router was rebooted without proper shutdown (cause 1)

Hello Folks!

RoS5.16 seemed to work properly for some week, now problems arrive, but not on all customer antennas.

On 4 RB411 we got random reboots several times per day, which gives a bad customer impact!

Autosupout files are generated and reports sent in to support@mikrotik.com, yet no answer, they have to work on it for some time
We did not have this in RoS 5.14, it come with RoS5.16, I do think it is unlikely antennas is broken in one way or another, they are relatively new (1-2 years and all have UPS and is surge protected).

Anyone who have seen this ?

jan/02/1970 01:00:20 system,error,critical System rebooted because of kernel faiure
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shtudown (cause 1)
jan/02/1970 01:00:21 system,error,critical System rebooted because of kernel failure
jan/02/1970 01:00:21 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:20 system,error,critical System rebooted because of kernel failure
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:21 system,error,critical router was rebooted without proper shutdown (cause 1)

If anyone else sees reboots, please send supout.rif file to support, we will see reason for reboot

how stupid, but i now see 4.17 doesnt report as"Ether up/down"in log file ? but as "device change" ?
can it be than that now iḿ to run 5.x on clients i do get to see more info about Etherlinks and it shows bad wiring ? wich i didnt see on 4.x ? but was always bad afterall

The "port up/down" reporting was only added in v5.3, so obviously you did not see such logs before. maybe you always had a bad link, but only now you get a log about this.

Hello Folks!

RoS5.16 seemed to work properly for some week, now problems arrive, but not on all customer antennas.

On 4 RB411 we got random reboots several times per day, which gives a bad customer impact!

Autosupout files are generated and reports sent in to support@mikrotik.com, yet no answer, they have to work on it for some time
We did not have this in RoS 5.14, it come with RoS5.16, I do think it is unlikely antennas is broken in one way or another, they are relatively new (1-2 years and all have UPS and is surge protected).

Anyone who have seen this ?

jan/02/1970 01:00:20 system,error,critical System rebooted because of kernel faiure
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shtudown (cause 1)
jan/02/1970 01:00:21 system,error,critical System rebooted because of kernel failure
jan/02/1970 01:00:21 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:20 system,error,critical System rebooted because of kernel failure
jan/02/1970 01:00:20 system,error,critical router was rebooted without proper shutdown (cause 1)
jan/02/1970 01:00:21 system,error,critical router was rebooted without proper shutdown (cause 1)

If anyone else sees reboots, please send supout.rif file to support, we will see reason for reboot

Hello Folks!

Problem found, IMPORTANT this is NOT RoS 5.16 problem!

We have RoS5.16 all over and only one device has problems, hardware problems!

Hardware problem in one device that by co-insident happen close after upgrade plus thunder storm season began en customers start to shut off their antennas when not used!

After sending in autosupout file to MT support problem was solved, PCI bus problems report say.

So all can calm down, RoS 5.16 is stable, it is safe to use it!

Thanks steen. We're at 5.9 now. Is it worth upgrading?

We're at 5.9 now. Is it worth upgrading?

Yes. This version works really well and is very stable.

Thanks steen. We're at 5.9 now. Is it worth upgrading?

Yes, it is worth upgrading!

RoS 5.16 is very stable and show better nv2 performance, no suddenly 100% cpu on rb450g, no 100% cpu due to snmp etc.
We observed 3-4% increase in the nv2 p2mp environments

So go for it!

On 5.16, I switch my backhaul links (some point-to-point and some multi-point) to NV2 (TDMA) from 802.11 , and I am seeing 100% increase in throughput.

Some of my links are 802.11A and some are 802.11N (all 5Ghz WDS links) and clients are at least 10 miles to 16 miles from AP.

FYI - I also set the AP NV2 TDMA Period Size to 4 (sacrafice some response for greater throughput). And I also lock in short preamble.


Tom Jones

Tested on a problematic link. Looks much better now.

Thanks!

I sent email to support.

I reboot my rb and show log error in kernel.

it's amazing Nstreme is still crippled. P Throughput never exceeds 55,000 even at data rates of 270/270. also random disconnects. I'm now forced to use NV2 for my PtP's, which give high jitter and latency compared to good old Nstreme.

is anyone else REALLY not seeing this? I have over 10 PtP's that I've witnessed this on. roll back to 4.x and I get a solid 144,000 Pthroughput.

Well, I noticed exactly the same issue.

With ROS 5.14 on ALL my 802.11a/40MHz "turbo" Point-to-Point links max P Throughput (with CCQ=100%/100%) is 58514 Kbps (nstreme with polling, CSMA disabled, no framing). Bandwidth testing is inline with the above value, which is much less than the expected one. Version 4.17 performs definitely better than this.

I temporarily stopped any upgrade to 5.x until this problem is fixed.

Did you test ROS 5.17? Any news about this point?

Regards,
rock