v6.39rc80 [release candidate] is released!

Fri Apr 21, 2017 12:23 pm

We have released MikroTik RouterOS v6.39rc76, we are getting very close to release stable v6.39 to current channel. Please report all known issues here or to support@mikrotik.com

What's new in 6.39rc76 (2017-Apr-21 07:24):
other changes in 6.39rc tree,
https://mikrotik.com/download/changelog ... lease-tree

*) capsman - added EAP identity to registration table;
*) capsman - added support for "background-scan" and channel "reselect-interval";
*) ike2 - fixed RSA authentication without EAP;
*) ike2 - fixed policy release during SA negotion;
*) l2tp - fixed hidden attribute decryption in forwarded CHAP responses for LNS;
*) ppp - include rates, limits and address-lists parameters in RADIUS accounting requests;
*) pppoe - added warning on PPPoE client/server, if it is configured on slave interface;
*) tile - fixed IPSec crash (introduced in 6.39rc64);
*) webfig - allow to change global variable contents;
*) webfig - allow to enter frequency ranges in wireless scan list;
*) webfig - do not allow to reorder items if table is sorted by some column;
*) webfig - fixed bridge property display;
*) webfig - show proper error messages for optional erroneous text fields;
*) winbox - added "k" and "M" unit support to PPP secret limit-bytes parameters;
*) winbox - added "Flush" button under unicast-fdb menu;
*) winbox - added "memory-scroll", "filter-cpu", "filter-ipv6-address", "filter-operation-between-entries" parameters;
*) winbox - added protected routerboard parameters under routerboard settings menu;
*) winbox - hide "wps-mode" & "security-profile" in wireless nv2 mode;
*) winbox - properly show wireless registration table stat counters;
*) wireless - fixed dynamic wireless interface removal from bridge ports when changing wireless mode;

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.

v6.39rc80 is released,
viewtopic.php?f=1&t=120946&p=595256#p595256

bbs2web · Fri Apr 21, 2017 1:44 pm

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

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 to STP was introduced just before 6.38 was released and shows no consideration for existing customers who have built networks, having become accustomed to how RouterOS's STP implementation worked up until then. The change now makes it impossible for service providers to redundantly bridge interfaces; one of the, if not most important, benefits 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 services to various cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup VPLS tunnels to the remote sites, 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 loops. One could additionally interleave bridge priorities to balance workloads on redundant equipment (eg odd/even VLANs). This is impossible since 6.38...

The 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).

g33k · Fri Apr 21, 2017 2:14 pm

May I have the details on 'ppp - include rates, limits and address-lists parameters in RADIUS accounting requests;'

Thanks

xlighting · Fri Apr 21, 2017 2:21 pm

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.

Fri Apr 21, 2017 2:57 pm

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.

No problems here. usually problems like this are with policy routing, but policy roluting and fasttrack is mutually exclusive....

biatche · Fri Apr 21, 2017 3:14 pm

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I understand MikroTik removing VLAN tags from STP BPDU frames when people create VLANs on bridges, as in:
Code: Select all
int vlan add name=vlanXXX interface=bridge vlan-id=XXX
The change to STP was introduced just before 6.38 was released and shows no consideration for existing customers who have built networks, having become accustomed to how RouterOS's STP implementation worked up until then. The change now makes it impossible for service providers to redundantly bridge interfaces; one of the, if not most important, benefits 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 services to various cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup VPLS tunnels to the remote sites, 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 loops. One could additionally interleave bridge priorities to balance workloads on redundant equipment (eg odd/even VLANs). This is impossible since 6.38...

The 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).

Would having MSTP option solve this issue?

xlighting · Fri Apr 21, 2017 3:35 pm

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.
No problems here. usually problems like this are with policy routing, but policy roluting and fasttrack is mutually exclusive....

revert to 6.38.5(with same config) will immediately fix the problem...

indeed I have policy routing, I don't think they are exclusive since ANY https is affected, no matter which route it goes. so my guess is something wrong with the MTU/MSS

Marino · Fri Apr 21, 2017 4:23 pm

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.
No problems here. usually problems like this are with policy routing, but policy roluting and fasttrack is mutually exclusive....
revert to 6.38.5(with same config) will immediately fix the problem...

indeed I have policy routing, I don't think they are exclusive since ANY https is affected, no matter which route it goes. so my guess is something wrong with the MTU/MSS

Same here. I saw some posts with fasttrack problems in the previous version too. I'm using a RB750Gr3.

Fri Apr 21, 2017 4:51 pm

bbs2web, thank you very much for the output. We will see what we can do.

g33k, PPP accounting messages now include the following paramters
MikroTik-Rate-Limit
X-Ascend-Xmit-Rate and X-Ascend-Data-Rate
MikroTik-Addres-list

Marino, and other who might have the same problem potentially.
It would be great to get some steps/instructions to support@mikrotik.com how to repeat described problems.

jkarras · Fri Apr 21, 2017 5:32 pm

Marino, and other who might have the same problem potentially.
It would be great to get some steps/instructions to support@mikrotik.com how to repeat described problems.

Steps for me were to upgrade to anything past rc62. Sites became unbearably slow if the traffic flow went through the fasttrack rule. I have a VRF on my device and that traffic was not showing issues its also not picked up by the fasttrack rule. If I disable the fast track rule everything flows normally again.

In my scenario the traffic was flowing through a SRCNAT rule I don't have a good way at the moment to test if non-SRCNAT traffic is affected.

Fri Apr 21, 2017 6:05 pm

Steps for me were to upgrade to anything past rc62...

I don't think your reply is what sergejs has been asking for. It looks like just a small number of people experience problems similar to yours, so this must be something very specific to your exact configuration, no matter how simple or generic you consider your config to be. Can you please just share you full configuration with support@ (or, even better, send your supout to them).

jkarras · Fri Apr 21, 2017 6:13 pm

I understand. I already had an email typed up after that last version didn't fix it with a sprout from before and after the upgrades. I was waiting until after the next update just in case they fixed it then.

My case is actually pretty simple. Standard home Internet provider, DHCP on WAN, masquerade rule, fast track matching related,established. Enabled traffic to Internet goes slow. disabled things are fine.

mducharme · Fri Apr 21, 2017 7:49 pm

Unable to open any HTTPS site, unless the fasttrack rule is disabled.
meanwhile, HTTP site is not affected, even if the fasttrack rule is enabled.
No problems here. usually problems like this are with policy routing, but policy roluting and fasttrack is mutually exclusive....
revert to 6.38.5(with same config) will immediately fix the problem...

indeed I have policy routing, I don't think they are exclusive since ANY https is affected, no matter which route it goes. so my guess is something wrong with the MTU/MSS

I am having MTU issues with IPv6 on these new RC's, maybe it is the same problem. I had to disable IPv6 temporarily. Pings fail once packet size is turned up too high. I get my IPv6 through a tunnel.

Edit: perhaps it started at rc40? There was this change made in rc40: !) ppp - implemented internal algorithm for "change-mss", no mangle rules necessary;

Maybe when they were making these changes for PPP MTU something was broken for MTU/MSS with other tunnel types.

nkourtzis · Fri Apr 21, 2017 8:07 pm

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I understand MikroTik removing VLAN tags from STP BPDU frames when people create VLANs on bridges, as in:
Code: Select all
int vlan add name=vlanXXX interface=bridge vlan-id=XXX
The change to STP was introduced just before 6.38 was released and shows no consideration for existing customers who have built networks, having become accustomed to how RouterOS's STP implementation worked up until then. The change now makes it impossible for service providers to redundantly bridge interfaces; one of the, if not most important, benefits 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 services to various cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup VPLS tunnels to the remote sites, 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 loops. One could additionally interleave bridge priorities to balance workloads on redundant equipment (eg odd/even VLANs). This is impossible since 6.38...

The 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).

I totally agree. I had MAJOR problems caused by this change until I figured out what the problem was. I was getting outages (and even complete freezes!) because the Tiks kept thinking that there was a loop where there was none. The problem was that BPDUs from two different bridges on the same physical network (one VLANed, one not) were being mixed up. At least a selectable option (strip/do not strip) would be nice to have, for those who need the tags to remain untouched.

nkourtzis · Fri Apr 21, 2017 8:18 pm

Another problem I saw in the 6.39RC is that the script for updating DynDNS (not the builtin "cloud" menu), taken from the wiki (https://wiki.mikrotik.com/wiki/Dynamic_ ... for_dynDNS) stopped working after years without a problem. I have traced it down to the update statement, which uses the /tool fetch command to call the update URL. It is called but does not succeed to update the address. Probably a change in the behaviour of the fetch command caused an incompatibility. It is important, as this script is bound to a specific interface and thus it works better on routers with many public IPs.

anuser · Fri Apr 21, 2017 8:57 pm

*) capsman - added EAP identity to registration table;

/caps-man registration-table print detail gives me empty eap-identity, only, i.e.

eap-identity=""

biatche · Fri Apr 21, 2017 9:14 pm

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I understand MikroTik removing VLAN tags from STP BPDU frames when people create VLANs on bridges, as in:
Code: Select all
int vlan add name=vlanXXX interface=bridge vlan-id=XXX
The change to STP was introduced just before 6.38 was released and shows no consideration for existing customers who have built networks, having become accustomed to how RouterOS's STP implementation worked up until then. The change now makes it impossible for service providers to redundantly bridge interfaces; one of the, if not most important, benefits 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 services to various cities and wants each one handed off as a VLAN on their PNI (provider network interconnect). On 6.37.5 you could setup VPLS tunnels to the remote sites, 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 loops. One could additionally interleave bridge priorities to balance workloads on redundant equipment (eg odd/even VLANs). This is impossible since 6.38...

The 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).
I totally agree. I had MAJOR problems caused by this change until I figured out what the problem was. I was getting outages (and even complete freezes!) because the Tiks kept thinking that there was a loop where there was none. The problem was that BPDUs from two different bridges on the same physical network (one VLANed, one not) were being mixed up. At least a selectable option (strip/do not strip) would be nice to have, for those who need the tags to remain untouched.

I believe we share the same issue. I just didn't have the knowledge or understanding on how to explain it. Are you able to share what devices are involved to reproduce this at a very minimum and your topology?

I untag my vlan99 mgmt on the CRS and have a few trunk ports with native vlan 99, hence communicating as vlan1 by devices connected to this. Sorry if my explanation is poor so far. I've only come to learn that it is now possible to enable RSTP on the CRS as of 6.38, which I've yet to try. Hence, I had rstp enabled on two ends but not in between. I have two bridges, one involving vlans and another not. My question to you then is, would we face freezes still even when RSTP is enabled on the CRS?

msatter · Fri Apr 21, 2017 9:36 pm

I can confirm that, ike2 - fixed RSA authentication without EAP; has been resolved and it is working as normal again.

Thanks for fixing this.

hedele · Sat Apr 22, 2017 2:03 pm

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

I second this entire post - this change to how STP works is simply unacceptable as it breaks several different deployments we have in place where we NEED to rely on RouterOS to transmit correctly tagged BPDUs for interoperability with Cisco (and other PVST capable) gear.

stucki · Sat Apr 22, 2017 2:37 pm

is the update for chr on esx solved?

fabvit · Sat Apr 22, 2017 7:14 pm

Please can you point me to the download link of 6.39rc76 (2017-Apr-21 07:24)?
on the official download page I can only see 6.39rc72 (Release candidate)

msatter · Sat Apr 22, 2017 7:27 pm

Please can you point me to the download link of 6.39rc76 (2017-Apr-21 07:24)?
on the official download page I can only see 6.39rc72 (Release candidate)

The easiest way is to follow the part above the table and use Winbox.

As you did not state which model you have you have to copy the link of the rc72 and replace twice the 2 by a 6 and then you can use the new URL to download the rc76.

achelon · Sat Apr 22, 2017 8:00 pm

Hi,

My working IKEv2 config using RSA certs seems to be broken since rc72. Only 1 device can connect at a time now. When second device tries to connect (e.g. macOS,) device logs
"Failed to process IKE Auth packet". Config hasn't changed from my old working one of:

/ip ipsec mode-config
set request-only name=request-only
add address-pool=ipsec-pool address-prefix-length=24 name=cfg_priv split-include=0.0.0.0/0,<local subnet> system-dns=\
    yes
  /ip ipsec policy group
set default name=default
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 disabled=no enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc \
    lifetime=1h name=default pfs-group=modp2048
/ip ipsec peer
add address=0.0.0.0/0 auth-method=rsa-signature certificate=<cert name>_0 comment=IKEv2 dh-group=\
    modp4096 disabled=no dpd-interval=2m enc-algorithm=aes-256 exchange-mode=ike2 generate-policy=port-strict \
    hash-algorithm=sha512 lifetime=1d local-address=<public IP> mode-config=cfg_priv my-id=fqdn:<public URL> \
    passive=yes policy-template-group=default send-initial-contact=no
/ip ipsec policy
set 0 disabled=no dst-address=0.0.0.0/0 group=default proposal=default protocol=all src-address=0.0.0.0/0 template=\
    yes
/ip ipsec user settings
set xauth-use-radius=no
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0

Any suggestions?

Achelon

sterling · Sat Apr 22, 2017 10:45 pm

So again with RSTP on a VLAN that is attached to a Bridge, it is going to send out the BPDU packets to the interface, regardless of VLAN, right?

Isn't that how RSTP works on most switches?

Unless MSTP or PVSTP is implemented, this is now normal operation mode which is 'normal' to switches operating in RSTP as well, right?

Just tring to figure out how things are supposed to operate with RSTP in 6.39 going forward.

I have VPLS endpoints bridged with interfaces connected to the same switch banks for redundancy.
So what is the 'norm' for setup on Mikrotik in this scenario where I'm expecting the VPLS endpoints to behave if connection/traffic gets separated from one of the connections to the switch?

Is there something I should be setting with RSTP or the VPLS interfaces connected to the same switch bank?

dereed999 · Mon Apr 24, 2017 2:12 am

New to RouterOS so not sure if this is a bug or not. (Sorry! And I have tried searching to forums but can't find an answer).

I have a Metal 52 ac running 6.39rc76 (for some reason out of the box they wouldn't boot, nor properly reset so I had to use Netinstall, PXE boot, and flash new firmware and I chose 6.39rc76 - yeah, yeah, I could have picked a stable OS.)

On the "Quick Set" "CPE" screen of the web interface (192.168.88.1), for the "Wireless" section... should there be a dropdown to pick the radio band? I have dropdown for channel bandwidth, but no way from the "Quick Set CPE" screen to switch the radio from 5 GHz to 2.4 GHz or vice-versa. Should this drop down exist? If not, what is the proper way to put in a feature request as it seems an important feature for dual-band radios for anyone who wants a "quick setup" vs. customizations/advanced settings. (And yes, I will likely use many of the advance features, but there's a certain "I want to get this online and working quickly before I play with it" aspect

)

Again, sorry if this is not a bug and is elsewhere on the forum, but I tried to search and have failed....

Mon Apr 24, 2017 11:37 am

Everyone who is experiencing issues with FastTrack please write to support@mikrotik.com. Mention version from which it stopped to work properly and send supout file which is generated at the moment when FastTrack is not working as suspected.

We have tried to test different configurations with FastTrack, but unfortunately have not been able to reproduce this problem. There must be something specific triggering this and supout files might help to find out what it is.

Marino · Mon Apr 24, 2017 1:30 pm

Everyone who is experiencing issues with FastTrack please write to support@mikrotik.com. Mention version from which it stopped to work properly and send supout file which is generated at the moment when FastTrack is not working as suspected.

We have tried to test different configurations with FastTrack, but unfortunately have not been able to reproduce this problem. There must be something specific triggering this and supout files might help to find out what it is.

Sorry I cannot install the rc76 at the moment. I'm back at rc58, which works fine.

My setup:
- 750Gr3 for internet access (NAT) with capsman. I'm using capsman forward with a bridge interface. For ipsec in and out I use mangle rules with action mark connection. On the fasttrack rule in the firewall there is a !ipsec rule for this connection mark to bypass fasttrack for ipsec traffic.
- 2x wireless devices -HAP AC and 951G- as CAP (capsman forward to the bridge on 750Gr3)

Deantwo · Mon Apr 24, 2017 2:18 pm

I am still receive large amounts of spammy debug log messages while I have an active IPsec tunnel.

12:59:22 ipsec receive Information. 
12:59:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
12:59:22 ipsec sendto Information notify. 
12:59:22 ipsec sendto Information notify. 
12:59:22 ipsec receive Information. 
12:59:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
12:59:42 ipsec receive Information. 
12:59:42 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
12:59:42 ipsec sendto Information notify. 
12:59:42 ipsec sendto Information notify. 
12:59:42 ipsec receive Information. 
12:59:42 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:00:02 ipsec receive Information. 
13:00:02 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:00:02 ipsec sendto Information notify. 
13:00:02 ipsec sendto Information notify. 
13:00:02 ipsec receive Information. 
13:00:02 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:00:22 ipsec receive Information. 
13:00:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:00:22 ipsec sendto Information notify. 
13:00:22 ipsec sendto Information notify. 
13:00:22 ipsec receive Information. 
13:00:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:00:42 ipsec receive Information. 
13:00:42 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:00:42 ipsec sendto Information notify. 
13:00:42 ipsec sendto Information notify. 
13:00:42 ipsec receive Information. 
13:00:42 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:01:02 ipsec receive Information. 
13:01:02 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:01:02 ipsec sendto Information notify. 
13:01:02 ipsec sendto Information notify. 
13:01:02 ipsec receive Information. 
13:01:02 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:01:22 ipsec receive Information. 
13:01:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:01:22 ipsec sendto Information notify. 
13:01:22 ipsec sendto Information notify. 
13:01:22 ipsec receive Information. 
13:01:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:01:42 ipsec receive Information. 
13:01:42 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:01:42 ipsec sendto Information notify. 
13:01:42 ipsec sendto Information notify. 
13:01:42 ipsec receive Information. 
13:01:42 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:02:02 ipsec receive Information. 
13:02:02 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:02:02 ipsec sendto Information notify. 
13:02:02 ipsec sendto Information notify. 
13:02:02 ipsec receive Information. 
13:02:02 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:02:22 ipsec receive Information. 
13:02:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:02:22 ipsec sendto Information notify. 
13:02:22 ipsec sendto Information notify. 
13:02:22 ipsec receive Information. 
13:02:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:02:42 ipsec receive Information. 
13:02:42 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:02:42 ipsec sendto Information notify. 
13:02:42 ipsec sendto Information notify. 
13:02:42 ipsec receive Information. 
13:02:42 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:03:02 ipsec receive Information. 
13:03:02 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:03:02 ipsec sendto Information notify. 
13:03:02 ipsec sendto Information notify. 
13:03:03 ipsec receive Information. 
13:03:03 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK 
13:03:22 ipsec receive Information. 
13:03:22 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE 
13:03:22 ipsec sendto Information notify. 
13:03:23 ipsec sendto Information notify. 
13:03:23 ipsec receive Information. 
13:03:23 ipsec xxx.xxx.xxx.xxx notify: R_U_THERE_ACK

Why don't they have the "debug" topic?

Mon Apr 24, 2017 2:58 pm

We have released 6.39rc79 version.

What's new in 6.39rc79 (2017-Apr-24 08:42):

*) fastpath - fixed traffic blocking when fasttrack-connection filter rule is enabled (introduced in 6.39rc62);
*) fetch - fixed authentication failure;
*) fetch - fixed download issue over HTTPS;
*) lte - added initial support for DWR-910 modem;
*) quickset - added initial LTE AP mode support;
*) winbox - fixed typo in BGP advertisements menu Aggragator->Aggregator;
*) winbox - removed unnecessary "/system health" menu on "hAP ac lite";

w0lt · Mon Apr 24, 2017 8:46 pm

FastTrack problem seems to have been resolved !!
Good Going guys, my RB3011 is running full speed again.

-tp

bratislav · Mon Apr 24, 2017 10:53 pm

Would having MSTP option solve this issue?

Unfortunately Mikrotik is just ignoring this issue and sticks with 16 years old RSTP standard ...

bratislav · Mon Apr 24, 2017 10:56 pm

So again with RSTP on a VLAN that is attached to a Bridge, it is going to send out the BPDU packets to the interface, regardless of VLAN, right?

Isn't that how RSTP works on most switches?

Unless MSTP or PVSTP is implemented, this is now normal operation mode which is 'normal' to switches operating in RSTP as well, right?

Just tring to figure out how things are supposed to operate with RSTP in 6.39 going forward.

I have VPLS endpoints bridged with interfaces connected to the same switch banks for redundancy.
So what is the 'norm' for setup on Mikrotik in this scenario where I'm expecting the VPLS endpoints to behave if connection/traffic gets separated from one of the connections to the switch?

Is there something I should be setting with RSTP or the VPLS interfaces connected to the same switch bank?

Just disable RSTP ... and STP ...

biatche · Tue Apr 25, 2017 1:00 am

How about giving us MSTP and PVRSTP for 6.40? This way I can continue purchasing MT products.

to make PVRSTP you could just take your pre-6.38 code and modify it a little.

anuser · Tue Apr 25, 2017 8:55 am

RouterOS v6.39rc79
"/caps-man registration-table print detail" still gives me empty eap-identity, only, i.e.

eap-identity=""

Tue Apr 25, 2017 9:41 am

Hey guys, this is a post about 6.39rc versions and not about feature requests.
Yes, we hear you and aware about RSTP/STP/MSTP/PVRSTP. You are welcome to make another thread or send all your findings to support@mikrotik.com

Tue Apr 25, 2017 1:57 pm

We have released 6.39rc80. It should be one of the latest rc releases before going to 6.39.

Changelog:
What's new in 6.39rc80 (2017-Apr-25 09:23):

!) bridge - reverted bridge BPDU processing back to pre-v6.38 behaviour; (v6.40 will have another separate VLAN-aware bridge implementation);

Tue Apr 25, 2017 2:24 pm

!) bridge - reverted bridge BPDU processing back to pre-v6.38 behaviour; (v6.40 will have another separate VLAN-aware bridge implementation);

Very nice to see that you actually listen to us

Tue Apr 25, 2017 2:27 pm

Very nice to see that you actually listen to us

They do, indeed. But your wording has to be crystal clear for this to happen.

biatche · Tue Apr 25, 2017 4:07 pm

We have released 6.39rc80. It should be one of the latest rc releases before going to 6.39.

Changelog:
What's new in 6.39rc80 (2017-Apr-25 09:23):

!) bridge - reverted bridge BPDU processing back to pre-v6.38 behaviour; (v6.40 will have another separate VLAN-aware bridge implementation);

https://wiki.mikrotik.com/wiki/Manual:C ... e_Protocol

does this still apply? do we still need to create a bridge on the CRS which appears to be a post 6.38 thing?

zryny4 · Tue Apr 25, 2017 4:54 pm

What about fast-forward feature in bridge?

/interface bridge print
 1  R name="local" mtu=auto actual-mtu=1500 l2mtu=1598 arp=enabled arp-timeout=auto
      mac-address=XX:XX:XX:XX:XX:XX protocol-mode=rstp fast-forward=no priority=0x8000 auto-mac=yes
      admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6
      ageing-time=5m

I searched for information on the wiki, but did not find anything...

PS sorry for my english

MartijnVdS · Tue Apr 25, 2017 5:01 pm

What about fast-forward feature in bridge?

That's described in the full changelog:

!) bridge - added "fast-forward" setting and counters (enabled by default only for new bridges) (CLI only);
!) bridge - added support for special and faster case of fastpath called "fast-forward" (available only on bridges with 2 interfaces);

bbs2web · Tue Apr 25, 2017 7:09 pm

We are very appreciative of Mikrotik's decision! Would you perhaps consider a stp bridge sub-menu where one could select either per-bridge (R)STP (the current implementation), standard (R)STP (the one in 6.38) or MSTP?

I understand standard (R)STP to essentially be common to all bridges, MSTP to provide a limited number of STP instances that certain bridges could be bound to and Per Bridge STP where each bridge is associated with its own STP instance. The last, in our experience, appears to be compatible with Cisco's PV(R)STP and is how it will work again in 6.39.

Perhaps one could select the STP type on a per bridge basis (the most flexible)?

What's new in 6.39rc80 (2017-Apr-25 09:23):

!) bridge - reverted bridge BPDU processing back to pre-v6.38 behaviour; (v6.40 will have another separate VLAN-aware bridge implementation);

biatche · Wed Apr 26, 2017 4:58 am

dear devs, please clarify if there are any ramifications set by the reverted BPDU change on the CRS in relation to bridge+STP. In short, should we create a bridge with RSTP still on the CRS. As in, is switch STP support reverted as well? It's very important we know this.

anuser · Wed Apr 26, 2017 9:16 am

6.39rc80 (2017-Apr-25 09:23):

"/caps-man registration-table print detail" still gives me empty eap-identity, i.e. only:

eap-identity=""

Wed Apr 26, 2017 10:49 am

6.39rc80 (2017-Apr-25 09:23):
"/caps-man registration-table print detail" still gives me empty eap-identity, i.e. only:
eap-identity=""

This fix will go only in v6.40rc as v6.39rc is going for final testing for v6.39 release.

Wed Apr 26, 2017 11:04 am

Hello,

The reverted BPDU changes do not affect how hardware based (R)STP works on CRS switches.
This CRS (R)STP configuration will still work using untagged BPDUs and will remain as is:
https://wiki.mikrotik.com/wiki/Manual:C ... e_Protocol

The changes in RouterOS v6.38 affect software based bridges in setups like below where it is made that only untagged BPDUs are allowed:
https://wiki.mikrotik.com/wiki/Manual:I ... N_examples
It was done to make (R)STP compatible between CRS switches and software bridges, but since they have caused various upgrading issues, it is decided to revert them.

From now on:
* CRS hardware based (R)STP will work only with untagged BPDUs;
* RouterOS software based (R)STP will work with tagged BPDUs on VLAN interfaces as it has been pre-v6.38 and will remain old functionality;
* In VLAN setups (R)STP will not be compatible between CRS switches and RouterOS software bridges for some time;
* RouterOS v6.40 is planned to have another separate VLAN-aware bridge implementation to allow using CRS (R)STP together with software bridge (R)STP in future.

DJSmiley · Wed Apr 26, 2017 12:34 pm

From the release notes:

What's new in 6.39rc80 (2017-Apr-25 09:23):
*) snmp - added optical table;

I was missing this for a long time. Hope to finally be able to monitor power levels on optics using SNMP.

Any more information about this? What are the OID's for this?

peson · Wed Apr 26, 2017 11:46 pm

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

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).

I agree. I've been requesting the MSTP since my presentation from 2009. (https://mum.mikrotik.com//presentations ... -final.pdf)
In MUM three years ago, I was told that MT was working on this.
I hope that this will be added in 6.40, it's very much needed. Best would of course be a SPB (802.1aq) support

raffav · Thu Apr 27, 2017 12:58 am

Any one else getting WiFi poor performance, high latency, low Sinal quality, or even disconnecting offen, using capsman?
I started to notice this behavior since >rc70

Enviado de meu XT1580 usando Tapatalk

biatche · Thu Apr 27, 2017 2:40 am

Please provide a method of restoring previous STP mode, whereby Router OS would exclusively transmit and process BPDUs on (R)STP bridge ports.

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).
I agree. I've been requesting the MSTP since my presentation from 2009. (https://mum.mikrotik.com//presentations ... -final.pdf)
In MUM three years ago, I was told that MT was working on this.
I hope that this will be added in 6.40, it's very much needed. Best would of course be a SPB (802.1aq) support

Then we'll have ISIS..

anuser · Thu Apr 27, 2017 7:35 am

Any one else getting WiFi poor performance, high latency, low Sinal quality, or even disconnecting offen, using capsman?
I started to notice this behavior since >rc70

Update: I just received reports from my colleagues that user complain about massive disconnection and authentication problems => Back to <6.39RC70

Marino · Thu Apr 27, 2017 11:54 am

We have released 6.39rc80. It should be one of the latest rc releases before going to 6.39.

Changelog:
What's new in 6.39rc80 (2017-Apr-25 09:23):

!) bridge - reverted bridge BPDU processing back to pre-v6.38 behaviour; (v6.40 will have another separate VLAN-aware bridge implementation);

Great release, thanks.

raffav · Thu Apr 27, 2017 2:23 pm

Any one else getting WiFi poor performance, high latency, low Sinal quality, or even disconnecting offen, using capsman?
I started to notice this behavior since >rc70
Starting from ~6.39rc60 CAPSMAN + all of my access point are running actually very well. No more complaints about slow connections or disconnectins and yes there were many of them daily only some weeks ago... For me 6.39rc releases are a big improvement over 6.38.5.

Can you give some tips?
You are using witch device?
You are using virtual ap to?
I think I am using it on a wrong way

Enviado de meu XT1580 usando Tapatalk

anuser · Thu Apr 27, 2017 3:15 pm

Can you give some tips?
You are using witch device?
You are using virtual ap to?
I think I am using it on a wrong way

I have to apologize. I just received reports from my colleagues that user complain about massive disconnection and authentication problems => Back to something <6.39RC70
What was the latest release for you being stable?

Thu Apr 27, 2017 3:27 pm

Can you give some tips?
You are using witch device?
You are using virtual ap to?
I think I am using it on a wrong way
I have to apologize. I just received reports from my colleagues that user complain about massive disconnection and authentication problems => Back to something <6.39RC70
What was the latest release for you being stable?

Please tell us more detailed what exactly is not stable with the CAPsMAN? Could you contact support@mikrotik.com about this issue?

ivicask · Thu Apr 27, 2017 3:46 pm

Any one else getting WiFi poor performance, high latency, low Sinal quality, or even disconnecting offen, using capsman?
I started to notice this behavior since >rc70
Update: I just received reports from my colleagues that user complain about massive disconnection and authentication problems => Back to <6.39RC70

Are you having a 4-way handshake occasional errors?I had this problems initially, but it got fixed after flashing 6.39rc7x version, but still i can see this error pop out here and there, i did send all info to support but didint get much usefull answer, and as it mostly works fine i didint want to "touch" anything anymore.

sid5632 · Thu Apr 27, 2017 4:19 pm

CHR is still emitting TCP(Syn) packets to 169.254.169.254:80

Chupaka · Thu Apr 27, 2017 4:53 pm

CHR is still emitting TCP(Syn) packets to 169.254.169.254:80

"169.254.169.254 is used in Amazon EC2 and other cloud computing platforms to distribute metadata to cloud instances."
http://docs.aws.amazon.com/AWSEC2/lates ... adata.html

raffav · Thu Apr 27, 2017 5:07 pm

Can you give some tips?
You are using witch device?
You are using virtual ap to?
I think I am using it on a wrong way
I have to apologize. I just received reports from my colleagues that user complain about massive disconnection and authentication problems => Back to something <6.39RC70
What was the latest release for you being stable?

I not sure, since when I stated notice that
but I have 2 problem,
1 is at home 450G as capsman and Basebox2 as CAP, I started to get disconnection on my mobile device when I was on one parte of the kitchen and when I got back to 38.5 on the same part the wifi don't get drop the signal stay on 70-80 .
I Will try some RC version like 70,72 to se if I stay on 70-80
2 Problem I get is at work
but this is not releated to RC version and yes to all configs,
I think that the 2.4 is saturated, but first I need to exclude bad config on capsman

pinging the gateway on work
[code
ping 192.168.150.1 -t -n 50

Pinging 192.168.150.1 with 32 bytes of data:
Reply from 192.168.150.1: bytes=32 time=2ms TTL=64
Reply from 192.168.150.1: bytes=32 time=5ms TTL=64
Reply from 192.168.150.1: bytes=32 time=108ms TTL=64
Reply from 192.168.150.1: bytes=32 time=13ms TTL=64
Reply from 192.168.150.1: bytes=32 time=15ms TTL=64
Reply from 192.168.150.1: bytes=32 time=10ms TTL=64
Reply from 192.168.150.1: bytes=32 time=23ms TTL=64
Reply from 192.168.150.1: bytes=32 time=86ms TTL=64
Reply from 192.168.150.1: bytes=32 time=15ms TTL=64
Reply from 192.168.150.1: bytes=32 time=11ms TTL=64
Reply from 192.168.150.1: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.150.1: bytes=32 time=479ms TTL=64
Reply from 192.168.150.1: bytes=32 time=3ms TTL=64
Reply from 192.168.150.1: bytes=32 time=167ms TTL=64
Reply from 192.168.150.1: bytes=32 time=275ms TTL=64
Reply from 192.168.150.1: bytes=32 time=1191ms TTL=64
Reply from 192.168.150.1: bytes=32 time=2ms TTL=64
Reply from 192.168.150.1: bytes=32 time=1ms TTL=64
Reply from 192.168.150.1: bytes=32 time=7ms TTL=64
Reply from 192.168.150.1: bytes=32 time=431ms TTL=64
Reply from 192.168.150.1: bytes=32 time=6ms TTL=64
Reply from 192.168.150.1: bytes=32 time=24ms TTL=64
Reply from 192.168.150.1: bytes=32 time=8ms TTL=64
Reply from 192.168.150.1: bytes=32 time=2ms TTL=64
Reply from 192.168.150.1: bytes=32 time=30ms TTL=64
Reply from 192.168.150.1: bytes=32 time=4ms TTL=64
Reply from 192.168.150.1: bytes=32 time=690ms TTL=64
Reply from 192.168.150.1: bytes=32 time=9ms TTL=64
Reply from 192.168.150.1: bytes=32 time=6ms TTL=64
Reply from 192.168.150.1: bytes=32 time=280ms TTL=64
Reply from 192.168.150.1: bytes=32 time=181ms TTL=64
Reply from 192.168.150.1: bytes=32 time=22ms TTL=64
Reply from 192.168.150.1: bytes=32 time=119ms TTL=64
Reply from 192.168.150.1: bytes=32 time=2ms TTL=64
Reply from 192.168.150.1: bytes=32 time=176ms TTL=64
Reply from 192.168.150.1: bytes=32 time=218ms TTL=64
Reply from 192.168.150.1: bytes=32 time=2ms TTL=64
Reply from 192.168.150.1: bytes=32 time=1ms TTL=64
Reply from 192.168.150.1: bytes=32 time=268ms TTL=64
Reply from 192.168.150.1: bytes=32 time=21ms TTL=64
Reply from 192.168.150.1: bytes=32 time=2ms TTL=64
Reply from 192.168.150.1: bytes=32 time=99ms TTL=64
Reply from 192.168.150.1: bytes=32 time=2ms TTL=64
Reply from 192.168.150.1: bytes=32 time=88ms TTL=64sss
Reply from 192.168.150.1: bytes=32 time=106ms TTL=64
Reply from 192.168.150.1: bytes=32 time=2139ms TTL=64
Reply from 192.168.150.1: bytes=32 time=597ms TTL=64
Reply from 192.168.150.1: bytes=32 time=753ms TTL=64
Reply from 192.168.150.1: bytes=32 time=462ms TTL=64

Ping statistics for 192.168.150.1:
Packets: Sent = 50, Received = 49, Lost = 1 (2% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2139ms, Average = 187ms

[/code]

jondavy · Thu Apr 27, 2017 9:12 pm

into Wireless Registration Table, mac-ping, mac-telnet not work

anuser · Fri Apr 28, 2017 9:40 am

Please tell us more detailed what exactly is not stable with the CAPsMAN? Could you contact support@mikrotik.com about this issue?

=> 2017042722000941

Are you having a 4-way handshake occasional errors?I had this problems initially, but it got fixed after flashing 6.39rc7x version, but still i can see this error pop out here and there, i did send all info to support but didint get much usefull answer, and as it mostly works fine i didint want to "touch" anything anymore.

=> Indeed I had handshake infos in the past. But I cannot find anything more in current logging data

Njumaen · Fri Apr 28, 2017 1:15 pm

rc80 works fine with my CRS125-24G-1S and three hAPac and a wAPac attached via capsman.
one thing: webfig shows non-master-interfaces in the CAPs Scanner... obsolte because you only can select the master-ifs

great work so far!

Regards,

Ralf.

MartijnVdS · Fri Apr 28, 2017 2:01 pm

CHR is still emitting TCP(Syn) packets to 169.254.169.254:80
"169.254.169.254 is used in Amazon EC2 and other cloud computing platforms to distribute metadata to cloud instances."
http://docs.aws.amazon.com/AWSEC2/lates ... adata.html

169.254.0.0/16 is for 'link local' IPv4 addresses (RFC 3927, Windows calls this "APIPA", Automatic Private IP Addressing and uses it if it can't get an IP from a DHCP server).

Fri Apr 28, 2017 4:04 pm

Version 6.39 and 6.40rc has been released:
viewtopic.php?f=21&t=121196
viewtopic.php?f=21&t=121198

Who is online