v6.39rc [release candidate] is released

Wed Apr 12, 2017 9:19 am

We re sorry for any inconvenience caused.

We have managed to reproduce this issue and it will be resolved in next rc public release.

horza · Wed Apr 12, 2017 11:59 am

6.39rc62 > 6.39rc68 caused my 2011UAS-2HnD and x86 to not boot. Starting services -> crash on both.
Both routers use a whole bunch of features, so not sure which one broke it

FWIW CHR upgraded just fine.

Wed Apr 12, 2017 12:51 pm

Version 6.39rc69 has been released.

Changes since previous version:
*) ike2 - allow multiple child SA traffic selectors on re-key;
*) ike2 - log RADIUS timeout message under error topic;
*) ipsec - do not loose "use-ipsec=yes" parameter after downgrade;
*) lte - added "session-uptime" in info command;
*) lte - reset interface stats on "link-down";
*) ppp - added "bridge-horizon" option under PPP/Profile;
*) snmp - increase “engineBoots” value on reboot;
*) tunnels - fixed reboot loop on configurations with IPIP and EoIP tunnels (introduced in 6.39rc68);
*) webfig - allow to select "default-encryption" profile on PPP tunnels;
*) webfig - show all available options under “Advanced Mode” for wireless interfaces;
*) webfig - fixed “last-link-up” & “last-link-down” time information;
*) winbox - do not start Traffic Generator automatically when opening "Quick Start";

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.

Wed Apr 12, 2017 1:23 pm

This release fixes crashes related to EoIP and IPIP tunnels which were introduced with previous release:
*) tunnels - fixed reboot loop on configurations with IPIP and EoIP tunnels (introduced in 6.39rc68);

We are sorry for any inconvenience caused.

pista · Wed Apr 12, 2017 1:33 pm

This release fixes crashes related to EoIP and IPIP tunnels which were introduced with previous release:
*) tunnels - fixed reboot loop on configurations with IPIP and EoIP tunnels (introduced in 6.39rc68);

We are sorry for any inconvenience caused.

And fix reboot loop on hAPac ? Because I have no EoIP or IPIP tunnels.

Wed Apr 12, 2017 4:52 pm

pista - Please write to support@mikrotik.com and explain your problem. Provide old supout files or export files from older versions (if you have any) so we could try to reproduce your problem.

pista · Wed Apr 12, 2017 5:04 pm

pista - Please write to support@mikrotik.com and explain your problem. Provide old supout files or export files from older versions (if you have any) so we could try to reproduce your problem.

I wrote to the support.
Below is answer from support....

I have only "autosupout.rif" what I find in the flash of router.

-----------------------------------------------------------------------------------------
Hello,
We are sorry for any inconvenience caused.
We have managed to reproduce such issue and will fix it in next 6.39rc public release.
If you can not access device, then you must Netinstall device to older RouterOS version.

Have a nice day!

Best regards,
Martins S.

--
MikroTik.com
--

04/11/2017 18:45 - wrote:

> Hello,
>
> after upgrade to 6.39rc68 on hAPac I have bootloop.
> How to repair it?
>
-----------------------------------------------------------------------------------------

Wed Apr 12, 2017 5:31 pm

pista - Please send this autosupout file to support within the same conversation. I see that there were no files attached and it was assumed that this is the same issue with IPIP and EoIP.

jkarras · Thu Apr 13, 2017 4:19 am

Spanning Tree is broken since 6.38. We want to implement redundant bridges, to link together carrier VLANs to customer ports or VLANs. The previous STP implementation was essentially similar to PVSTP (per VLAN Spanning Tree Protocol) but the new implementation results in routers sending and processing STP BPDU packets on ports which aren't members of the bridge. The simplest way of demonstrating this is to configure bridges on two different VLANs, on different routers which share the VLAN carrying network.

At the top of the 6.38 changelog there is this answer to your issue:

Important note!!!
RouterOS v6.38 contains STP/RSTP changes which makes bridges compatible with IEEE 802.1Q-2014 by sending and processing BPDU packets without VLAN tag.

biatche · Thu Apr 13, 2017 8:06 am

Spanning Tree is broken since 6.38. We want to implement redundant bridges, to link together carrier VLANs to customer ports or VLANs. The previous STP implementation was essentially similar to PVSTP (per VLAN Spanning Tree Protocol) but the new implementation results in routers sending and processing STP BPDU packets on ports which aren't members of the bridge. The simplest way of demonstrating this is to configure bridges on two different VLANs, on different routers which share the VLAN carrying network.
At the top of the 6.38 changelog there is this answer to your issue:

Important note!!!
RouterOS v6.38 contains STP/RSTP changes which makes bridges compatible with IEEE 802.1Q-2014 by sending and processing BPDU packets without VLAN tag.

and what's the answer?

jkarras · Thu Apr 13, 2017 8:35 am

Spanning Tree is broken since 6.38. We want to implement redundant bridges, to link together carrier VLANs to customer ports or VLANs. The previous STP implementation was essentially similar to PVSTP (per VLAN Spanning Tree Protocol) but the new implementation results in routers sending and processing STP BPDU packets on ports which aren't members of the bridge. The simplest way of demonstrating this is to configure bridges on two different VLANs, on different routers which share the VLAN carrying network.
At the top of the 6.38 changelog there is this answer to your issue:

Important note!!!
RouterOS v6.38 contains STP/RSTP changes which makes bridges compatible with IEEE 802.1Q-2014 by sending and processing BPDU packets without VLAN tag.
and what's the answer?

Since 6.38 BPDUs are sent and processed with out the VLAN tag.

biatche · Thu Apr 13, 2017 12:49 pm

Spanning Tree is broken since 6.38. We want to implement redundant bridges, to link together carrier VLANs to customer ports or VLANs. The previous STP implementation was essentially similar to PVSTP (per VLAN Spanning Tree Protocol) but the new implementation results in routers sending and processing STP BPDU packets on ports which aren't members of the bridge. The simplest way of demonstrating this is to configure bridges on two different VLANs, on different routers which share the VLAN carrying network.
At the top of the 6.38 changelog there is this answer to your issue:

Important note!!!
RouterOS v6.38 contains STP/RSTP changes which makes bridges compatible with IEEE 802.1Q-2014 by sending and processing BPDU packets without VLAN tag.
and what's the answer?
Since 6.38 BPDUs are sent and processed with out the VLAN tag.

He said its broken, so what's the fix?

pe1chl · Thu Apr 13, 2017 2:55 pm

Adapt all the equipment and settings in the network to be standards compliant.
That being said, it would have been friendlier when this change was configurable so a new version
could be installed with the old behaviour and a controlled migration of existing networks would be possible.

sbeauchamp · Thu Apr 13, 2017 3:05 pm

I seem to be having IPSEC peers acting odd. I haven't noticed this until the last couple RC versions. Peers will show a whole bunch of installed SAs, although only one pair per peer with increment bytes.I have two CCRs(rc62 and rc69) connected back to a CHR (6.37.5), both are doing this. the CHR shows tons on installed SAs, while the CCRs don't show any SAs at all. Eventually, the IPSEC peers fail and no traffic will pass. I can flush SAs from the CHR it will reestablish. Anyone seeing this?

Ill email support as well.

Thu Apr 13, 2017 3:28 pm

Version 6.39rc72 has been released.

Changes since previous version:
*) discovery - fixed LLDP discovery, IPv6 address was not parsed correctly;
*) l2tp - added support for multiple L2TP tunnels (not to be confused with sessions) between same endpoints (required in some LNS configurations);
*) l2tp-server - added "caller-id-type" to forward calling station number to RADIUS on authentication;
*) l2tp-server - added "use-ipsec=required" option;
*) l2tp-server - fixed upgrade to keep "use-ipsec=yes" in L2TP server;
*) log - added missing "license limit exceeded" log entry;
*) ppp - added option to specify "interface-list" in PPP/Profile;
*) pppoe - added warning on PPPoE client/server, if it is configured on slave interface;

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.

bbs2web · Thu Apr 13, 2017 5:12 pm

I understand MikroTik removing VLAN tags from STP BPDU frames when people create VLANs on bridges, as in:

int vlan add name=vlanXXX interface=bridge vlan-id=XXX

The change they however smashed in place, in my humble opinion, shows no field testing nor consideration for existing customers who have built networks having become accustomed to how RouterOS's STP implementation worked up until 6.38. Their changes now make it impossible for service providers to redundantly bridge interfaces; the whole point of STP in the first place.

I generally understand things better with examples, perhaps the following helps others too:

You have a customer who's paying for a layer 2 service to two cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup redundant VPLS tunnels to the two remote cities, on redundant routers, set each one to bridge the services to the customer's service delivery VLANs on the PNI and RSTP would automatically isolates the redundant uplink to prevent network topology loops. This is impossible since 6.38...

Their current implementation additionally simply assumes that it can transmit the STP BPDU frames on the VLAN's parent interface so it becomes immensely unpredictable:

- Bridging QinQ VLANs, Attach 'vlan10-vlan100' to a bridge and the STP frames are transmitted on vlan10. This is in direct contradiction to their change announcement where they indicated that STP wouldn't be tagged.

- Bridging other interfaces. RouterOS doesn't transmit STP BPDU directly on the carrier interface when you bridge a tunnel interface such as EoIP, VPLS, etc. By this I mean that RouterOS wouldn't sporadically send STP BPDU frames on ether1 because it's carrying an EoIP tunnel. A Virtual LAN interface is supposed to be isolated from other interfaces, why would MikroTik suddenly consider it normal to transmit STP BPDU frames outside of the bridge?

MikroTik should at the very least provide a method to retain their previous STP implementation, which worked well with Cisco's PVSTP (per VLAN STP). This quite simply transmitted STP BPDU frames on all bridge member ports. Yes, bridging vlan10 and then connecting the uplink port to a cheap D-Link or Netgear may cause the STP implementation on that switch to shut the port, but that's a problem with the switch or the user's implementation; not for MikroTik to have a knee jerk reaction and break something as fundamental as service provider bridging redundancy. PS: People with these switches should either simply disable STP on the uplink interface, change their topology, log a request to have switch firmware changed or get a PVSTP capable switch.

I furthermore don't see the point of having independent STP processes running for each bridge, if the STP BPDU frames are leaked to ports that aren't members of those bridges. Simply do what switch vendors have done and provide the option of how you want STP to operate (eg Netgear M4300 offers STP, RSTP, MSTP or PV(R)STP).

YOU CAN NOT CHANGE FEATURES WHICH FUNDAMENTALLY AFFECT HOW THAT PRODUCT FUNCTIONS..

Adapt all the equipment and settings in the network to be standards compliant.
That being said, it would have been friendlier when this change was configurable so a new version
could be installed with the old behaviour and a controlled migration of existing networks would be possible.

w0lt · Thu Apr 13, 2017 5:58 pm

When I upgraded to ROS v6.39rc62, the following Firewall rule brought my outside access to a crawl:

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related

Once I disabled it, the system began to work normally.
This is the same with the current release 6.39rc72.
I have submitted a supout file to tech support.

Thoughts?

-tp

pe1chl · Thu Apr 13, 2017 6:52 pm

Thoughts?

Too little context to say anything meaningful!
When you don't want to post your full config here, you will have to take that up with support.

jkarras · Fri Apr 14, 2017 2:11 am

When I upgraded to ROS v6.39rc62, the following Firewall rule brought my outside access to a crawl:

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related

Once I disabled it, the system began to work normally.
This is the same with the current release 6.39rc72.
I have submitted a supout file to tech support.

Thoughts?

-tp

I am seeing similar issues with slowness when moving past rc60. I'll try to remove the fasttrack-connection rule and see if it also resolves my issues. I suspect it will because I have a VRF which does not seem to be affected.

kometchtech · Fri Apr 14, 2017 3:29 am

When I upgraded to ROS v6.39rc62, the following Firewall rule brought my outside access to a crawl:

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related

Once I disabled it, the system began to work normally.
This is the same with the current release 6.39rc72.
I have submitted a supout file to tech support.

Thoughts?

-tp

I am also suffering from this symptom.
There is no problem if you do not use FastTrack, but I can not explain the symptoms when using FastTrack.
I also contact support, but I do not understand easily.

jkarras · Fri Apr 14, 2017 5:46 am

Confirmed disabling fasttrack rule fixes slow traffic that would have otherwise been tagged by the rule.

msatter · Sat Apr 15, 2017 5:18 pm

For long time I was very pleased to use IKE2 with my Adroid with StrongSwan as client. It is still working on 6.39v62 and I skipped 6.39v68 and used the 6.39v69 and gone was my IKE2 connection. I get the error "wrong EAP mode" and I poked a bit around and it seems to be the Peers tab and the certificate and remote certificate part. Nothing helped and changing setting StrongSwan did also not help. Updated to 6.39v72, despite no mention in the changelog on IKE2, to no avail.

So I downgraded to 6.39v62 and my IKE2 worked instantly to great pleasure to me!!

Does someone know how what to do so I don't being stuck on 6.39v62 forever because something changed in the later version of RouterOS and I don't have a clue how or what to change?

msatter · Sun Apr 16, 2017 1:27 pm

Do I need to regenerate my certificate in a different way to be able to connect to the latest version of routeros through Ipsec IKE2?

korzh · Sun Apr 16, 2017 6:05 pm

For long time I was very pleased to use IKE2 with my Adroid with StrongSwan as client. It is still working on 6.39v62 and I skipped 6.39v68 and used the 6.39v69 and gone was my IKE2 connection. I get the error "wrong EAP mode" and I poked a bit around and it seems to be the Peers tab and the certificate and remote certificate part. Nothing helped and changing setting StrongSwan did also not help. Updated to 6.39v72, despite no mention in the changelog on IKE2, to no avail.

Seems to got same issue on my RB951Ui-2HnD. Updated from 6.39rc62 to 6.39rc72, now IKEv2 functionality is lost.
Got following lines in log:

17:49:32 ipsec,debug ---->: KA tree dump: <Router Wan IP>[4500]-><Client IP>[15892] (in_use=2) 
17:49:32 ipsec ---->: processing payloads: NOTIFY 
17:49:32 ipsec ---->:   notify: INITIAL_CONTACT 
17:49:32 ipsec ---->:   notify: ESP_TFC_PADDING_NOT_SUPPORTED 
17:49:32 ipsec ---->:   notify: NON_FIRST_FRAGMENTS_ALSO 
17:49:32 ipsec ---->: peer wants tunnel mode 
17:49:32 ipsec ---->: processing payload: CONFIG 
17:49:32 ipsec ---->:   attribute: internal IPv4 address 
17:49:32 ipsec ---->:   attribute: internal IPv4 netmask 
17:49:32 ipsec ---->:   attribute: internal IPv4 DNS 
17:49:32 ipsec ---->:   attribute: internal IPv4 DNS 
17:49:32 ipsec ---->:   attribute: internal IPv4 NBNS 
17:49:32 ipsec ---->:   attribute: internal IPv4 NBNS 
17:49:32 ipsec ---->:   attribute: application version 
17:49:32 ipsec,error can't acquire address for <Client IP>, <Client cert details>: std failure: unknown id (4) 
17:49:32 ipsec,error ---->: can't acquire address for <Client IP>, <Client cert details>: std failure: unknown id (4) 
17:49:32 ipsec ---->: my ID (DER): <Router cert details> 
17:49:32 ipsec,error wrong EAP mode 
17:49:32 ipsec,error ---->: wrong EAP mode 
17:49:32 ipsec ---->: adding payload: NOTIFY 
17:49:32 ipsec ---->:   notify: INTERNAL_ADDRESS_FAILURE

Client device is BlackBery z30, using "Generic IKEv2" VPN mode, connecting via mobile network.

msatter · Sun Apr 16, 2017 9:27 pm

It seems that the client IP is the problem. Normally it is pulled from the pool but it seems that this address is also needed to be stated in the certificate.

17:49:32 ipsec,error can't acquire address for <Client IP>, <Client cert details>: std failure: unknown id (4)
17:49:32 ipsec,error ---->: can't acquire address for <Client IP>, <Client cert details>: std failure: unknown id (4)

If you're still running the v72 maybe you can put the IP someware in strongswan to if that differs.

korzh · Sun Apr 16, 2017 11:03 pm

It seems that the client IP is the problem. Normally it is pulled from the pool but it seems that this address is also needed to be stated in the certificate.

It's near to impossible to state IP address in certificate for road warrior in advance, since we don't know what IP will be assigned to device by mobile network (or it can be behind NAT on some public hotspot). Also setting auth method to PSK results to same error:

ipsec,error can't acquire address for <Client IP>, <Client IP>: std failure: unknown id (4)

Anyway I think that I found what was wrong.
After update following peer setting were modified (don't know why, possible bacause some new parameters were added to IPSec):
Passive was set to "no" and mode-config was set to "request-only", which is default IPSec mode config without address pool configured.

So, I found two ways to solve issue:
1. just define address pool, prefix length etc. in "request-only" mode config.
2. set peer "passive" parameter to "yes", define new mode config and set it in peer parameters. (This way seems to be more correct than first).

After all changes done I see that mobile device connects to RB with no problems.

Seems that that was my fault - I just was need to inspect all IPSec settings, but I was a bit confused with "wrong eap mode" line in log.

tagocha · Sun Apr 16, 2017 11:47 pm

thanks for valuable information

korzh · Mon Apr 17, 2017 2:12 am

Seems that that was my fault - I just was need to inspect all IPSec settings, but I was a bit confused with "wrong eap mode" line in log.

Oops. Seems that not only my fault.
Played a bit with PFS Group settings in proposal, changing value from "none" to any other value and got "wrong EAP mode" in log. Most interesting that error message persists even if PFS was reverted back to "none".
So, now I have exactly same configuration (on same OS version) which previously allowed to connect mobile device, but no connection can be established in fact.
Rebooting both router and client device results to nothing.
Looks like some kind of "floating" bug.

UPD: changing PFS settings randomly (from subset supported by client device) and trying to connect results in successful connection in one of about 10 cases, no matter what PFS is selected.

stucki · Mon Apr 17, 2017 5:12 pm

I can confirm the upgrade problem on the CHR.

stable to rc

msatter · Tue Apr 18, 2017 3:47 pm

So, I found two ways to solve issue:
1. just define address pool, prefix length etc. in "request-only" mode config.
2. set peer "passive" parameter to "yes", define new mode config and set it in peer parameters. (This way seems to be more correct than first).

After all changes done I see that mobile device connects to RB with no problems.

Seems that that was my fault - I just was need to inspect all IPSec settings, but I was a bit confused with "wrong eap mode" line in log.

I checked this an my configuration already was already set that way. I remember during fiddling with the settings I could connect however like you experienced that could be just luck and not repeatable.

Going back again to v62 and hope that the Wiki will be updated to explain how to setup a working Road Warrior again.

Update: the "wrong EAP mode" will be fixed in the next RC according to Mikrotik Support. See posting below.

emils · Tue Apr 18, 2017 3:56 pm

Issue with wrong EAP mode will be fixed in the next release candidate version.

AlexLite · Wed Apr 19, 2017 8:26 am

My wap ac on rc72 seems to reset to default configuration on every reboot.
Anybody ran into this?

ErfanDL · Wed Apr 19, 2017 9:30 am

What's going on? Mikrotik stopped updating? Update stopped on rc72

Sent from my C6833 using Tapatalk

pe1chl · Wed Apr 19, 2017 11:15 am

What's going on? Mikrotik stopped updating? Update stopped on rc72

Come on! rc72 was released last week!

Wed Apr 19, 2017 11:19 am

We had easter holiday from thursday to monday included. RC73 is in internal testing now

ganewbie · Wed Apr 19, 2017 3:19 pm

Version 6.39rc72 has been released.
Changes since previous version:
*) l2tp - added support for multiple L2TP tunnels (not to be confused with sessions) between same endpoints (required in some LNS configurations);
*) l2tp-server - added "caller-id-type" to forward calling station number to RADIUS on authentication;
.

Could you please shed some light on the changes?
I assume the first one concerning having multiple domains coming from one LAC (could be Junipur or Cisco) to the Mikrotik when it works as LNS, correct?
An example of my question is:
clientx@example1.com
clienty@example2.com

Thanks for the great product,

pe1chl · Wed Apr 19, 2017 3:26 pm

Is there a chance to get the rpfilter matcher assuming it is not yet available?
viewtopic.php?f=2&t=120863

mducharme · Fri Apr 21, 2017 7:21 am

I am having an EoIP Tunnel IPv6 MTU issue recently that must have started in one of the 6.39rc's.

I have a friend who runs an ISP also using MikroTik and he provides me with IPv6 through an IPv4 EoIP tunnel since my home ISP doesn't offer IPv6 yet. At some point (I'm not sure when), my IPv6 stopped passing larger packets, I can only ping IPv6 with packet size 1458 (1459 fails). I allow ICMPv6 globally so PMTUD should be working. His side is working fine (running 6.38.5), so it must be an RC issue. I was tied up with other issues so I only noticed this recently - not sure when the problem started. I was at rc49 with this issue and upgraded to rc72 and it is still happening.

Fri Apr 21, 2017 7:43 am

Is there a chance to get the rpfilter matcher assuming it is not yet available?
viewtopic.php?f=2&t=120863

+1

I would like to see this too. I heard murmurings that Mikrotik were planning on adding per-interface RP filter settings.. Any offical update ?

Chrisnetika · Fri Apr 21, 2017 10:22 am

When I upgraded to ROS v6.39rc62, the following Firewall rule brought my outside access to a crawl:

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related

Once I disabled it, the system began to work normally.
This is the same with the current release 6.39rc72.
I have submitted a supout file to tech support.

Thoughts?

-tp
I am also suffering from this symptom.
There is no problem if you do not use FastTrack, but I can not explain the symptoms when using FastTrack.
I also contact support, but I do not understand easily.

Having same issue on RB953GS-5HnT,
disabling fastpath or it's firewall rule fixes it

Fri Apr 21, 2017 12:24 pm

6.39rc76 has been released.
viewtopic.php?f=1&t=120946

Who is online