MikroTik

I had this problem going from v6.38.4 to 6.38.5 on the RB3011 also. Unfortunantly the router is one of my main routers, and I didn't have a spare so I couldn't debug.

In that scenario it is not wise to run RC software... I hope at least you make backups and/or exports and store them on another computer.

I had this problem going from v6.38.4 to 6.38.5 on the RB3011 also. Unfortunantly the router is one of my main routers, and I didn't have a spare so I couldn't debug.

In that scenario it is not wise to run RC software... I hope at least you make backups and/or exports and store them on another computer.

What's new in 6.39rc4 (2016-Dec-30 07:16):

!) ppp - completely rewritten internal fragmentation algorithm (when MRRU is used), optimized for multicore;
*) capsman - added CAP discovery interface list support;
*) ethernet - renamed "rx-lose" to "rx-loss" in ethernet statistics;
*) health - report fan speed for RB800 and RB1100 when 3-pin fan is being used;
*) led - show warning on print when "modem-signal-threshold" is not available;
*) lte - added error handling for remote AT execute;
*) wAP ac - improved 2.4GHz wireless performance;
*) wireless - added "station-roaming" setting (cli only);
*) wireless - show comment on "security-profile" if it is set (cli only);

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.

Hello,

*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;

this problem still persists with version 6.39rc58

please fix

it is also not necessarily related to iphone 6s devices but occurs randomly (could be that a 6s is walking by, but thats just guessing)

Thank you

*) ethernet - fixed rare switch chip hang (could cause port flapping);

Version 6.39rc62 has been released.
*) wireless - added PEAP authentication support for wireless station mode;

Version 6.39rc62 has been released.
*) wireless - added PEAP authentication support for wireless station mode;

Wow, finally nice

Hello,

*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;

this problem still persists with version 6.39rc58

please fix

it is also not necessarily related to iphone 6s devices but occurs randomly (could be that a 6s is walking by, but thats just guessing)

Thank you

This should get fixed in rc59, MikroTik had access to my hAP AC and after a few debug firmwares the problem was no longer reproducible with my 6s.

Version 6.39rc62 has been released.

Changes since previous version:
!) firewall - discontinued support for p2p matcher (old rules will become invalid);
*) capsman - added "extension-channel" XX and XXXX auto matching modes;
*) capsman - added "keepalive-frames" setting;
*) capsman - added "skip-dfs-channels" setting;
*) capsman - added ability to specify multiple channels in frequency field;
*) capsman - added DFS support;
*) capsman - added support for "background-scan" and channel "reselect-interval";
*) capsman - changed channel "width" name to "control-channel-width" and changed default values;
*) fastpath - fixed rare crash on devices with dynamic interfaces;
*) smips - reduced RouterOS main package size;
*) tile - optimized hardware encryption;
*) tr069-client - added firewall NAT support using vendor Parameters;
*) tr069-client - added support for uploading/downloading factory script;
*) webfig - correctly specify routing filter prefix;
*) winbox - allow to specify "route-distance" in "dhcp-client" if "special-classless" mode is selected;
*) winbox - do not allow Packet Sniffer "memory-limit" lower than 10KiB;
*) winbox - fixed "Montly" typo to "Monthly" in Graphing menu;
*) winbox - hide health menu on RB450;
*) winbox - properly show "dhcp-server" warnings;
*) winbox - properly show IPSec "installed-sa" "enc-algorithm" when it is aes-gcm;
*) winbox - set default "dhcp-client" "default-route-distance" value to 1;
*) winbox - show PoE-OUT current, voltage and power only on devices which can report these values;
*) wireless - added PEAP authentication support for wireless station 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.

*) tr069-client - added support for uploading/downloading factory script;

*) capsman - added ability to specify multiple channels in frequency field;

*) capsman - added ability to specify multiple channels in frequency field;

Is this so that Auto-Channel will only select one of the frequencies listed ?

still not fixed in 6.39rc62

Hello,

*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;

this problem still persists with version 6.39rc58

please fix

it is also not necessarily related to iphone 6s devices but occurs randomly (could be that a 6s is walking by, but thats just guessing)

Thank you

This should get fixed in rc59, MikroTik had access to my hAP AC and after a few debug firmwares the problem was no longer reproducible with my 6s.

*) capsman - added support for "background-scan" and channel "reselect-interval";

*) capsman - added support for "background-scan" and channel "reselect-interval";

How does background-scan works? In winbox I still can't run background scan on capsman interfaces.

failure: background scan not supported in this state

Version 6.39rc62 has been released.

Changes since previous version:
*) wireless - added PEAP authentication support for wireless station mode (CLI only);

When I start background scan on cap it tells me:

failure: background scan not supported in this state

I ran it from cap router, not from capsman router.

When I start background scan on cap it tells me:

failure: background scan not supported in this state

I ran it from cap router, not from capsman router.

It will be only supported from the CAPsMAN side.

When I start background scan on cap it tells me:

failure: background scan not supported in this state

I ran it from cap router, not from capsman router.

It will be only supported from the CAPsMAN side.

Then how to run that scan?

Version 6.39rc62 has been released.

Changes since previous version:
*) wireless - added PEAP authentication support for wireless station mode (CLI only);

Ok, CLI only was added later... I was checking via WebFig.
How is it done?

/interface wireless security-profiles
add name="peap" mode=dynamic-keys authentication-types=wpa2-eap eap-methods=peap

now I still have to config the "anonynous identity", "username" and "password".
Do I use the existing fields supplicant-identity mschapv2-username and mschapv2-password
for that? (meaning the only thing missing from Webfig is the eap-methods=peap in the pulldown?)
Or is there some other place to enter anonymous identity?

still not fixed in 6.39rc62

Hello,

*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;

this problem still persists with version 6.39rc58

please fix

it is also not necessarily related to iphone 6s devices but occurs randomly (could be that a 6s is walking by, but thats just guessing)

Thank you

This should get fixed in rc59, MikroTik had access to my hAP AC and after a few debug firmwares the problem was no longer reproducible with my 6s.

Please tell us more info what causes the DFS this time? iPhone 6S or some other device? Maybe you could provide us with the remote access to the AP so we could monitor that?

Is there any possibility in future, that we could set other modes in cap settings than ap mode? I wish there was a station mode...

Yes, you need to specify the mschapv2-username/password setting. Also I suggest to set the tls-certificate=do-not-verify-certificate option.
Outer TLS identity is used from the supplicant-identity and inner TLS identity is used the mschapv2-username.

First of all: I had the problems with version 6.39rc60 not rc62. I now upgraded to rc62 and will check again.
the problem occured mainly in the middle of the day when I am not there or in the middle of the night, so I have no clue which device it could have been. there is no iPhone 6s present. the problem first appeared upgrading from 6.38.3 to 6.38.5.

a side note: the throughput from 6.38.5 to 6.39rc62 is now much better. in 6.38.5 I could barely get 100Mbps http throuput at 866MBit/s Phy-Rate. Now I am able to get almost 200 Mbps. This is not as great as it was with pre 6.38.x but much better than with 6.38.x

First of all: I had the problems with version 6.39rc60 not rc62. I now upgraded to rc62 and will check again.
the problem occured mainly in the middle of the day when I am not there or in the middle of the night, so I have no clue which device it could have been. there is no iPhone 6s present. the problem first appeared upgrading from 6.38.3 to 6.38.5.

a side note: the throughput from 6.38.5 to 6.39rc62 is now much better. in 6.38.5 I could barely get 100Mbps http throuput at 866MBit/s Phy-Rate. Now I am able to get almost 200 Mbps. This is not as great as it was with pre 6.38.x but much better than with 6.38.x

The problem is still present in 6.39rc62, it occured in the middle of the night (3:30)

Does the black list function in the discover info window of the dude client for windows work right in this build? In 6.38.3, and previous versions I don't see the . or ... buttons shown in the manual here.

http://wiki.mikrotik.com/wiki/Manual:Th ... _discovery

There is a related bug where dude discovers phantom devices on the broadcast and subnet IP addresses during discovery discussed here:
http://forum.mikrotik.com/viewtopic.php?f=8&t=118250

*) tr069-client - added support for uploading/downloading factory script;

Does the black list function in the discover info window of the dude client for windows work right in this build? In 6.38.3, and previous versions I don't see the . or ... buttons shown in the manual here.

http://wiki.mikrotik.com/wiki/Manual:Th ... _discovery

There is a related bug where dude discovers phantom devices on the broadcast and subnet IP addresses during discovery discussed here:
http://forum.mikrotik.com/viewtopic.php?f=8&t=118250

It seems this is not fixed even in 6.39rc62. How/where can we specify black list for discovery?

Hi,
After the upgrade, my hEX PoE lite(RB750UPr2) is keep forgetting the configuration after every reboot.
This is a know problem?
Have anybody a workaround for this or i have to wait for a new rc release (im already downgraded, no problem)?

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.

We link two RB433GL routers together by interconnecting ether2, then setup VLAN 10 on one and VLAN 11 on the other. We then finally add the VLAN interfaces to separate bridges and would expect each bridge to be root independently but they don't:

Router 1:

Code: Select all

/interface vlan
  add interface=ether2 name=vlan10 vlan-id=10
/interface bridge
  add name=bridge-vlan10
/interface bridge port
  add bridge=bridge-vlan10 interface=vlan10

Router 2:

Code: Select all

/interface vlan
  add interface=ether2 name=vlan11 vlan-id=11
/interface bridge
  add name=bridge-vlan11
/interface bridge port
  add bridge=bridge-vlan11 interface=vlan11

Status on Router 1:

Code: Select all

[admin@Router 1] > int bridge monitor bridge-vlan10
                  state: enabled
    current-mac-address: 00:0C:42:F5:8D:7D
            root-bridge: yes
         root-bridge-id: 0x8000.00:0C:42:F5:8D:7D
         root-path-cost: 0
              root-port: none
             port-count: 1
  designated-port-count: 1

Status on Router 2:

Code: Select all

[admin@Router 2] > int bridge monitor bridge-vlan11
                  state: enabled
    current-mac-address: D4:CA:6D:78:4A:8A
            root-bridge: no
         root-bridge-id: 0x8000.00:0C:42:F5:8D:7D
         root-path-cost: 10
              root-port: vlan11
             port-count: 1
  designated-port-count: 0

This was validated on both 6.38.5 and 6.39rc68. When downgrading to 6.37.5 it works as it should:
Status on Router 1:

Code: Select all

                  state: enabled
    current-mac-address: 00:0C:42:F5:8D:7D
            root-bridge: yes
         root-bridge-id: 0x8000.00:0C:42:F5:8D:7D
         root-path-cost: 0
              root-port: none
             port-count: 1
  designated-port-count: 1

Status on Router 2:

Code: Select all

                  state: enabled
    current-mac-address: D4:CA:6D:78:4A:8A
            root-bridge: yes
         root-bridge-id: 0x8000.D4:CA:6D:78:4A:8A
         root-path-cost: 0
              root-port: none
             port-count: 1
  designated-port-count: 1

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

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.

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.

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.

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?

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.

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

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

• - 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?

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.

Thoughts?

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

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

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.

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 

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)

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.

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

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.

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.

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

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

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

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.