v6.39rc [release candidate] is released

Version 6.39rc49 has been released.

Changes since previous version:
!) www - fixed http server vulnerability;
*) capsman - improved CAP status querying;
*) defconf - fixed default configuration generation when wireless package is disabled;
*) ike2 - check child state before allowing rekey;
*) ike2 - send EAP identity as user-name RADIUS attribute;
*) lte - added LTE signal level reading for Cinterion modems;
*) queue - fixed reboot loop when queues were used (introduced in 6.39rc42);
*) rb3011 - added partitioning support;
*) tr069-client - added “Device.Hosts.Host.{i}.” support;
*) userman - fixed rare crash when User Manager requested file does not exist on router;
*) wireless - fixed RBSXT5HacD2nr2 small channel support;

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.

!) www - fixed http server vulnerability;

please add more details!!!

version affected?

what type of vulnerability?

thanks.

Good morning! :slight_smile:
http://forum.mikrotik.com/t/statement-on-vault-7-document-release/106907/1

!) pppoe - added fastpath support when MRRU and MLPPP are enabled;

Is it about the pppoe-server or just the client?

Thanks.

I guess this is client only.
I don’t remember fastpath support for PPPoE server ever being promised.

A friendly bump on my request to have the IPv6 package enabled by default in the main RouterOS package. :slight_smile:

We want to get purchasing and rolling out hundreds of MikroTik TR-069 routers to our customers but are holding off until we are able to do this.

Try contacting support by email. They may know of a way to do this, or get you a custom package (especially if you’re buying hundreds of CPEs).

I think too much to MUM :open_mouth:

We also need a proper set of firewall rules, simply enabling ipv6 is not enough

Version 6.39rc51 has been released.

Changes since previous version:
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
*) tr069-client - fixed write for “Device.ManagementServer.URL”;

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.

Can you tell more about this?
Does this also improve IPsec on other multicore platforms like RB750GR3?

This is specifically for the CCR series (both problem and solution). More information here: http://forum.mikrotik.com/t/is-re-ordering-fixed-yet-with-ipsec-and-hardware-acceleration-updating-thread/101814/1

Did anyone else experienced the issue that the complete NAT configuration was gone after rebooting into rc51?

I had to manually rebuild the whole NAT cfg :confused:


Gesendet von iPad mit Tapatalk

No problem over here with the NAT or any other rules.

CAPSMAN controller: CCR1009
Wifi CAPS: WAP AC + HAP AC

v6.36.4:
working fine, reference speed wireless: 250-260Mbit/s

v6.38.x :

  • massive wireless issues with capsman (continous disconnects, slow speeds)
  • RSTP causing forwarding issues (traffic not forwarding, DHCP not getting through)

v6.39rcXX-51:

  • Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)

is any chance for fix for recent linux breach ?
eg this one:
https://security-tracker.debian.org/tracker/CVE-2017-2636



... in the Linux kernel through 4.10.1...

RouterOS v6 uses v3.3.6 and don’t have hdlc …you are safe.

6.38.x severe issues.

setup: gw = rb750gr3 ↔ sw = crs125 ↔ LAN & ap = wap ac / hap ac

Things have been operational in 6.37.1 750g3,crs125 and 1x wap ac. I have 3 vlans, 1 for management, 2 for lan. I bought another few wap ac and hap ac to add to the network.

First, I upgraded from 6.37.1 to 6.38.5. (some weird stuff happened upgrading CRS125.. more on this in another thread post later that led me to believe that the CRS had become faulty). Anwyay, found that the CRS lost connectivity to the hex although I wasn’t yet aware it was a version issue. Hex couldn’t mac ping CRS. It was intermittent, after several configuration resets on the CRS, I could get the hex to ping/mac ping the CRS. Thought I had stablized it after that. After solving that, I went on to plug in and out devices. Plugged in the HAP AC to the CRS resulted in the CRS losing connectivity to the hex. SPENT 8 HOURS straight thinking its my configuration issue since its a production environment. Finally, for some reason, I realized it could be a version issue and so I went on to downgrade all the mikrotik devices to the old working version – 6.37.1. Voila, things seem to be stable again. Also, related or not, while i was on 6.38.5, HAP AC had difficult time (intermittent) picking up a dhcp client ip from the hex.. whether or not its due to the CRS being in between. After downgrading, it picked up the dhcp client ip pretty much immediately. WAP AC was fine though, had always picked up a dhcp address without any issues. So of course it also misled me from thinking theres a version issue.

Alright, I’m very furious. So much wasted time and no profit. What’s going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.

Edit: Do move this post to the 6.38.5 thread, my mistake for posting here.

I think the issues you mentioned may be related to what I mentioned in #260. Infuriating.

Are you sure this is not the issue related to (changes in) spanning tree?