Version 6.37.4 has been released in bugfix channel.

What's new in 6.37.4 (2017-Jan-13 06:52):
*) bonding - fixed "tx-drop" on VLAN over bonding on x86;
*) certificates - added year cap (invalid-after date will not exceed year 2039);
*) certificates - fixed crash when crl is removed while it is being fetched;
*) certificates - fixed fail on import from CAPs when both key and name already exist;
*) crs - added comment ability in more switch menus;
*) dhcpv6-client - fixed DHCPv6 rebind on startup;
*) dhcpv6-server - fixed server removal crash if static binding was present;
*) dns - fixed typo in regexp error message;
*) dude - (changes here: http://wiki.mikrotik.com/wiki/Manual:Th ... _changelog);
*) export - updated default values to clean up export compact;
*) fan - improved RPM monitor on CCR1009;
*) firewall - do not defragment packets which are marked with "notrack" in raw firewall;
*) firewall - fixed "time" option by recognizing weekday properly (introduced in v6.37.2);
*) firewall - fixed dynamic raw rule behaviour;
*) firewall - fixed rule activation if "time" option is used and no other active rules are present;
*) firewall - nat action "netmap" now requires to-addresses to be specified;
*) health - report fan speed for RB800 and RB1100 when 3-pin fan is being used;
*) hotspot - fixed nat rule port setting in "hs-unauth-to" chain by changing it from "dst-port" to "src-port" on Walled Garden ip "return" rules;
*) ipsec - fixed kernel failure on tile with sha256 when hardware encryption is not being used;
*) ipv6 - added warning about having interface MTU less than minimal IPv6 packet fragment (1280);
*) ipv6 - moved empty IPv6 pool error message to error topic;
*) led - fixed dark mode for cAP 2nD (http://wiki.mikrotik.com/wiki/Manual:Sy ... ds_Setting);
*) license - fixed demo license expiration after installation on x86;
*) log - improved firewall log messages when NAT has changed only connection ports;
*) lte - increased delay when setting sms send mode;
*) metarouter - fixed startup process (introduced in 6.37.2);
*) ppp - fixed packet size calculation when MRRU is set (was 2 bytes bigger than MTU allows);
*) ppp - significantly improved shutdown speed on servers with many active tunnels;
*) ppp - significantly improved tunnel termination process on servers with many active tunnels;
*) profile - added "bfd" and "remote-access" processes;
*) profile - added ability to monitor cpu usage per core;
*) profile - make profile work on mmips devices;
*) profile - properly classify "wireless" processes;
*) proxy - fixed "max-cache-object-size" export;
*) proxy - speed-up almost empty disk cache clean-up;
*) queue - fixed "time" option by recognizing weekday properly (introduced in v6.37.2);
*) quickset - various small changes;
*) rb750Gr3 - fixed ipsec with 3des+md5 to work on this board;
*) rb751u - fixed ethernet LEDs;
*) snmp - always report bonding speed as speed from first bonding slave;
*) snmp - fixed rare crash when incorrectly formatted packet was received;
*) ssh - fixed high memory consumption when transferring file over ssh tunnel;
*) switch - fix BPDU dynamic Host table entry on Atheros Gigabit switch chips;
*) time - updated time zones;
*) traceroute - fixed memory leak;
*) trafficgen - fixed compact export when "header-stack" includes tcp;
*) vlan - allow to add multiple VLANs which name starts with same number and has same length;
*) vrrp - do not show unrelated log warning messages about version mismatch;
*) watchdog - do not send supout file if "auto-send-supout" is disabled;
*) webfig - added extra protection against XSS exploits;
*) webfig - show properly interface last-link-up/down times;
*) webfig - show properly large BGP AS numbers;
*) winbox - added "Complete" flag to arp table;
*) winbox - added "make-static" to IPv6 DHCP server bindings;
*) winbox - added "prefix-pool" to DHCPv6 server binding;
*) winbox - added upstream flag to IGMP proxy interfaces;
*) winbox - allow to enable/disable traffic flow targets;
*) winbox - allow to specify "connection-bytes" & "connection-rate" for any protocol in “/ip firewall†rules;
*) winbox - allow to specify "sip-timeout" under ip firewall service-ports;
*) winbox - do not allow to set "loop-protect-send-interval" to 0s;
*) winbox - do not create empty rates.vht-basic/supported-mcs if not specified in CAPsMAN;
*) winbox - fixed crash when legacy Winbox version was used;
*) winbox - fixed default values for interface "loop-protect-disable-time" and "loop-protect-send-interval";
*) winbox - fixed missing "IPv6/Settings" menu;
*) winbox - fixed typo in "propagate-ttl" setting;
*) winbox - properly show VHT basic and supported rates in CAPsMAN;
*) winbox - show all related HT tab settings in 2GHz-g/n mode;
*) winbox - show dynamic IPv6 pools properly;
*) winbox - show errors on IPv6 addresses;
*) winbox - show proper ipv6 connection timeout;
*) winbox - specify metric for “/ip dns cache-used†setting;
*) wireless - fixed full "spectral-history" header print on AP modes;
*) wireless - fixed upgrade from older wireless packages when AP interface had empty SSID;
*) wireless - show comment on "security-profile" if it is set;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.

Installed on CCR1009. Everything looks correct. Thanks!

Installed on RB2011, Omnitik, RB951. Works.

Nice... testing on RB2011, so far, so good

Hello Folks!

Upgraded CRS, RB750, RB333 and RB411 so far no problems.

1xRB1100ahX2, 1 x 751G, 2x951G
All with wifi, radius-client, pptp-client, ipsec-client excep the 1100.

No probs so far. Wireless statistics also good.

Also upgraded over 60 RB912UAG's - no dead ones, no Wireless configs destroyed, no high-cpu on Graphs etc. So far very very good compared to prev releases

Upgraded RB750, RB2011UiAS-2HnD-IN, RB1100AHx2 so far no problems.

RB3011 (WAN up/downstream perfect!) , CRS125, hAPac, RB75Gr3 no problems.

I still have trouble with the mikrotik sites. I think I have to use IPv6 nowhere else.

I upgraded from 6.36.4 to 6.37.4 and lost my wireless-package,
Had both installes (wireless-rep active, wireless-cm2 disabled).

After the automatic installation (via spackage upgrade), no wireless-package was installed.
I had to coinnect to the device via cable and manually install the package.
The wireless-config also got lost, so i had to restore the backup.

I upgraded a couple of devices (different types of mipsbe architecture) and encountered no problems (IPv4, IPv6, VPN servers - SSTP and L2TP/IPsec, wifi 2G and 5G, VLANs, GRE6/IPsec tunnels, OSPFv2/v3, ...).
Bugfix releases seem pretty stable last time, the idea to separate development/current/bugfix was really a good one, I think.

notToNew - This is from 6.37 changelog:
"check-for-updates - with two or more standalone wireless packages, will result in no wireless packages installed, uninstall extra packages first;"

notToNew - This is from 6.37 changelog:
"check-for-updates - with two or more standalone wireless packages, will result in no wireless packages installed, uninstall extra packages first;"

OK, sorry... this one i missed ...!

Hello!

How we can know the changes from the previous "bugfix" version?
Is it the changelog for "bugfix version" full or we need to check version by version? (example 6.37.3, 6.37.2, 6.37.1, 6.37.0.....)

In case of we need to read all changelogs, where we can found it in a unique step? (it's very hard to open changelog by changelog)

Regards

Sim

Hi All,

Have upgraded from v6.34.6 and v6.36.4 to this version (v6.37.4) on a host of these devices with no issues experienced thus far (also no netinstalls needed on any):
- cAP (mipsbe)
- mAP2n (mipsbe)
- RB951G-2HnD (mipsbe)
- RB951Ui-2HnD (mipsbe)
- RB2011UAS-2HnD (mipsbe)
- CRS125-24G-1S-RM (mipsbe)
- CCR1036-12G-4S (tile)
- RB3011UiAS (arm)

keep up the good work, really liking the newer release streams (bugfix/current/etc) has made for a much better experience than early v6 single releases.

Why it is necessary to specify SSID for physical wlan interface in current bugfix release? In previous bugfix release it could be unset.

In my setup I have 2 VirtualAP interfaces where I configured SSID for my 2 WLANs,

You can't have AP without SSID.

I have upgraded a CCR1016-12G with this version and no issues so far. The device is configured with PCQ load balancing over 8 internet lines and PCQ queue for the client lan. So far no issues and the upgrade wen't smooth togather with the routerboard firmware upgrade.

Very nice. Seems to have made the Wi-Fi speeds on my hAP AC (962UiGS-5HacT2HnT) faster!

"/ip accounting" settings are not correctly shown by winbox (current/lastest 3.10 , board is CRS125).
I've no way now to go deeper and check if it could be a ros 6.37.4(+?) or winbox only (3.10) problem.

Try to configure/enable ip accounting via winbox > all seems to be fine (service works)
Exit winbox and relogin, you will see ip accounting disabled and web-access settings are not shown (despite service is working)
If you check via CLI the settings are there, only winbox ignore them.

Please, someone confirm ?

Have a nice week-end to all!

damn! .. probably also "/ip traffic-flow" have the same behaviour (winbox 3.10, board is 3011).
bye..

After updating my hAP AC (RB962UiGS-5HacT2HnT with serial number 676405Fxxxxx) to 6.37.4, it is really slow to login using putty or winbox. Any thing I should check to see why this is? Also, sometimes when I makes changes, when logging back in with winbox, everything is blank.

Here is an output of /export compact file

After updating my hAP AC (RB962UiGS-5HacT2HnT with serial number 676405Fxxxxx) to 6.37.4, it is really slow to login using putty or winbox. Any thing I should check to see why this is? Also, sometimes when I makes changes, when logging back in with winbox, everything is blank.

/ip address
add address=192.168.0.10/24 interface=bridge-LAN network=192.168.0.0

/ip route
add distance=1 gateway=192.168.0.1

[/code]

add address=192.168.0.10/24
I think should be -
add address=192.168.0.1/24
Is the SFP your WAN port?

add address=192.168.0.10/24
I think should be -
add address=192.168.0.1/24
Is the SFP your WAN port?

I set it to .10 because this unit is simply an AP on my network. .1 is my other router. No, the SFP port is not in use. Only ether1 has an Ethernet cable plugged into it.

Okay, I'm getting closer. When doing a "System / Reset Configuration" and checking only "No Default Configuration & Do Not Backup" the hAP AC and 6.37.4 does not seem to work well. Updating to 6.38.1 and performing a "/system routerboard upgrade" again (even though it was already at 3.34 seems to work better. Logging in with winbox is fast. Also, I had a message in the logs "cpu is not running with defaults". It was at 600Mhz, I changed it to 720Mhz.

I had upgraded (but did not reset) another hAP AC to v6.37.4, and it seems to run fine. Thus, the Reset Configuration is causing something to occur.

I found my issue. See here.

Hi guys,

Not sure if this is the right place to post this but as this is related to 6.37.4 I thought it be best here. If its in the wrong place, could a mod please move it, thank you.

I believe I have found a "possible" bug in v6.37.4 [bugfix] release. It may also be present in other versions but I can't bring the network down to test much more right now.

First I am fairly new to OSPF in general so I am not totally sure if I am doing this right but from my understanding and research, I am. Please correct me if i'm wrong in how i've implemented this, however im still sure this is a bug more then how its been implemented.

As they say a picture/video says a thousand words, i've done a quick screencast to show you the bug live.

https://youtu.be/Rq8IFUZR010

What I am trying to do is add in a new OSPF filter rule under ospf-in so that a new network (in this case, 192.168.10.0/24) is allowed to be accepted. You will first see that I try and ping the new network and you will see that it doesn't respond (as expected). You will then see me adding in the new 192.168.10.0 network and then try and ping the new network. You will see that this does not work (not working as expected). You will then see me disabling all rules then re-enabling them and you will see that the ping then starts responding.

I am pretty sure this is not what it should be doing as I would expect as soon as you update the rules, it should start working. If this is working as design then I really do apologize for this post, however I am fairly sure this isn't hence why I thought I would bring it up.

Majestic: it is a well known problem (at least in BGP) and it "will all be fixed in version 7".

Majestic: it is a well known problem (at least in BGP) and it "will all be fixed in version 7".

Ahh thanks very much, glad its not me going mad

I can live with it, just wanted to make sure mikrotik was aware.

Anyone having an issue where ipsec tunnels connect, but don't seem to be passing traffic? Have to kill them a couple of times before they connect properly?

Anyone having an issue where ipsec tunnels connect, but don't seem to be passing traffic? Have to kill them a couple of times before they connect properly?

I am also experiencing the same issue but it seems to happen completely random. It does not do it all the time and when it does, its not all of the tunnels or the same ones every time. I've not seen no actual patterns which causes it or when it occurs so its not making debugging very hard. I actually thought it was just some of my links but maybe its not.

However, what I find I have to do every now and then is when the links drop, I have to kill the IPSEC connections then it all re-establishes fine. If I don't force the disconnection, it never brings up the tunnel.

FYI, I am using GRE+IPSEC to multiple different locations. I am also running OSPF on top of all this. Each network is connected to their counterparts in a kinda mesh type topography.

I don't see this issue. make sure your firewall rules are correct. Without the proper rules it can sometimes work because
dynamic rules are created on the outbound connection and the "established/related" rule then accepts the traffic in the other
direction. However, this is not the proper way to do it and it may fail. Killing the connection at one end makes the new
connection randomly be from either end and 50% of the time it will then work.
But really you need to have some rules like "allow incoming UDP port 500" and "allow IPsec-protected GRE traffic".
For best results, you also should have a "deny unprotected GRE traffic" rule BEFORE the established/related rule.

I don't see this issue. make sure your firewall rules are correct. Without the proper rules it can sometimes work because
dynamic rules are created on the outbound connection and the "established/related" rule then accepts the traffic in the other
direction. However, this is not the proper way to do it and it may fail. Killing the connection at one end makes the new
connection randomly be from either end and 50% of the time it will then work.
But really you need to have some rules like "allow incoming UDP port 500" and "allow IPsec-protected GRE traffic".
For best results, you also should have a "deny unprotected GRE traffic" rule BEFORE the established/related rule.

Already have the appropriate DNAT rules but thank you for the suggestion. However I don't have a "deny unprotected GRE traffic" rules as ive not seen how that I can use to set that up. But as of right now, I use a GRE tunnel using the two public endpoint IP's. I then do IPSEC over that gre link and assign a private /30 range which is added to the GRE tunnel. After this OSPF is added with the link address pair and the VPN flows normally.

As for Established/related rule(s), they are the first set of rules as per correct firewall implementation, following down to the services which are in order of most hit to limit CPU time to find the right match.

FYI, Its not a firewall related problem, that I can 99% assure you of and this problem doesn't appear every day or even every other day, it maybe happens once every two to three weeks approx.

Theres no actual patten or anything really visible in the logs which annoys me but the next time it happens, ile hit the support file and see if support can figure it out.

If you want to test it yourself, leave a load of tunnels online for several weeks (6+ should do it which is around what I have on each site right now). As I said it doesn't do it to all of them at the same time, from what i've seen its just one and it seems completely random. This has happened about 2-3 times since patch has been released in different locations but never at the same one twice (so far anyway). Its too random right now to pinpoint.

If you can give me the syntex to create an "deny unprotected GRE traffic" rule, I would really love to hear from you as that would be a nice addition to my rulesets.

Thank you.

The filter rules have the selector ipsec-policy which you can set e.g. to ipsec-policy=in,none or ipsec-policy=in,ipsec to create
rules that handle traffic that is not protected or traffic that is protected.
You will need something like:

add action=reject chain=input ipsec-policy=in,none protocol=gre reject-with=icmp-admin-prohibited
add action=accept chain=input connection-state=established,related
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input ipsec-policy=in,ipsec protocol=gre

I have no experience with weeks of uptime on 6.37.4 but I do have that with 6.37.3 and 6.38.1 with several IPsec tunnels and I did not notice this problem yet.

The filter rules have the selector ipsec-policy which you can set e.g. to ipsec-policy=in,none or ipsec-policy=in,ipsec to create
rules that handle traffic that is not protected or traffic that is protected.
You will need something like:

add action=reject chain=input ipsec-policy=in,none protocol=gre reject-with=icmp-admin-prohibited
add action=accept chain=input connection-state=established,related
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input ipsec-policy=in,ipsec protocol=gre

I have no experience with weeks of uptime on 6.37.4 but I do have that with 6.37.3 and 6.38.1 with several IPsec tunnels and I did not notice this problem yet.

Thank you very much for that snip it, didn't know you could do that.

With regards to 6.37.4 uptime, i've been running it almost the same day that it came out as 6.38.1 had some nasty bugs and it was quicker/easier to switch to then to netinstall 6.37.3. Give it a few weeks and see if yours are doing the same, as I said I am still not convinced theres a problem yet hence why I haven't said anything. I only confirmed that I've been seeing something similar to the post above me (the original one).

Anyway, please keep me updated in a few weeks time if yours starts experiencing the same as me as i'm still trying to get to the bottom of it. FYI, last time it did this was about two days ago now and was only on one node out of about six and was only effecting one link. Soon as forced it to disconnect, it came up fine.

I don't see this issue. make sure your firewall rules are correct. Without the proper rules it can sometimes work because
dynamic rules are created on the outbound connection and the "established/related" rule then accepts the traffic in the other
direction. However, this is not the proper way to do it and it may fail. Killing the connection at one end makes the new
connection randomly be from either end and 50% of the time it will then work.
But really you need to have some rules like "allow incoming UDP port 500" and "allow IPsec-protected GRE traffic".
For best results, you also should have a "deny unprotected GRE traffic" rule BEFORE the established/related rule.

Yeah, was working fine for a few months before going to 37.4... still happens, but again, random.

Today we had a failure of some IPsec tunnels and I thought I might have been bitten by this problem, but
it turned out to be routing problems between the different internet provider we use.

Is there any plans to patch the bugfix channel ( 6.37.x ) against Vault 7's "ChimayRed" exploit ? Some of my networks are not able to make the jump to current release channel.

Version 6.37.5 has been released in bugfix channel:
viewtopic.php?f=21&t=119373