v6.39rc [release candidate] is released

picacho99 · Mon Mar 27, 2017 1:14 pm

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 is wrong with "zcybercomputing"?

One may decide to try RC software....Recover the device via netinstall and restore a backup requires no more than 10', and of course we, all, have backups and exports stored on another computer: in RB3011 partitions do not work...yes, it is suposed to work on v6.39.RC5X but no way to try it becuase leaves RB3011 unusable.

A RB3011 bought by the end of 2015, with historical debts (bridges, the announced desktop version with wireless, partitions, hardware encryption, ....)....from the "promissing" new ARM Mikrotik architecture that has never got additional devices launched.

zcybercomputing · Mon Mar 27, 2017 1:32 pm

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 know this is the RC thread, but if you check the version numbers I cited, you may get my point that this particular error also has effected the current releases. A boot loop as a result of firmware upgrade in the current released version is extremely concerning. I hope this gets sorted before this version gets out of RC. I would run the stable release on this router, but I need the new dude features of v6.38.x

Since this event, I have begun frequent full export, backup, and file system downloads...

None of the features I am using has caused the problem to resurface, but I will not upgrade or reinstall the extra packages I wanted to play with until this appears to be resolved.

jspool · Tue Mar 28, 2017 2:43 am

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.

Its so nice to be able to connect to Rest API's with the new post method!!! My Mikrotiks are now happily sending me SMS alerts via API. It does come back with "failure" in the terminal when I run the command however it actually does work fine. cURL reports success but Mikrotik does not show success but it does seem to work fine. Thanks for adding this feature. Look forward to it hitting the stable release.

moep · Wed Mar 29, 2017 3:39 pm

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

athurdent · Wed Mar 29, 2017 3:45 pm

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.

dash · Thu Mar 30, 2017 5:01 pm

I am facing issues with the 6.39rc58 on an RB952 (6.39rc58 port1) which is POE powered from an RB3011 (6.38.5, LAN port 10). After updating the RB952 with the rc58 frimware POE does not turn it on again. I had to use the standard 24v power supply to get it up and running before i was able to downgrade to the 6.38.5 package. In 6.38.5 POE works with no issue...

jondavy · Sat Apr 01, 2017 12:13 am

when i set:

/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-vlan=yes

is not catching VLAN QinQ traffic into firewall

Mon Apr 03, 2017 3:17 pm

Verison 6.39rc60 has been released.

Changes since previous version;
*) dhcpv4-server - by default make server â€œauthoritativeâ€;
*) ethernet - fixed "loop-protect" on "master-port";
*) ethernet - fixed rare switch chip hang (could cause port flapping);
*) ike2 - fixed ctr mode;
*) ipsec - enable aes-ni on i386 and x64 for cbc, ctr and gcm modes;
*) ipsec - renamed "hw-authenc" flag to "hw-aead";
*) log - do not show changes in packet if NAT has not been used;
*) tr069-client - fixed XML special character parsing;
*) tr069-client - hide "Device.PPP.Interface.{i}.Password" value;
*) tr069-client - make more Parameters deny active notifications;
*) wireless - fixed crash while running "spectral-scan";
*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;

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.

dyke · Mon Apr 03, 2017 4:54 pm

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

Does this fix is related to [Ticket#2017032822000978]?

Tue Apr 04, 2017 5:34 pm

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 (CLI only);
*) capsman - added "keepalive-frames" setting (CLI only);
*) capsman - added "skip-dfs-channels" setting (CLI only);
*) capsman - added ability to specify multiple channels in frequency field (CLI only);
*) capsman - added DFS support;
*) capsman - added support for "background-scan" and channel "reselect-interval" (CLI only);
*) capsman - changed channel "width" name to "control-channel-width" and changed default values (CLI only);
*) 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 (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.

paulct · Tue Apr 04, 2017 5:38 pm

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

Wow, finally

nice

pe1chl · Tue Apr 04, 2017 6:03 pm

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

Hooray!!! Finally we can phase out PSK!

moep · Tue Apr 04, 2017 6:57 pm

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.

Marino · Wed Apr 05, 2017 1:09 am

RB750GR3 doesn't boot. Crashes and reboot loop.

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.

mducharme · Wed Apr 05, 2017 3:11 am

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

Wow! That's excellent! How??

Wed Apr 05, 2017 4:51 am

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

Hi Strods,

Can you give an example of how you would use this ?

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

Wed Apr 05, 2017 9:41 am

*) capsman - added ability to specify multiple channels in frequency field;
Is this so that Auto-Channel will only select one of the frequencies listed ?

Yes, it will choose one of the specified frequencies.

Wed Apr 05, 2017 9:43 am

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?

MayestroPW · Wed Apr 05, 2017 1:25 pm

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

Wed Apr 05, 2017 1:34 pm

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

Winbox support for all the new CAPsMAN Features are not made yet. You need to use console.
As soon as the CAP starts to operate in a frequency you can run the background scan on it.

MayestroPW · Wed Apr 05, 2017 1:37 pm

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.

pe1chl · Wed Apr 05, 2017 4:25 pm

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?

Wed Apr 05, 2017 4:33 pm

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.

MayestroPW · Wed Apr 05, 2017 4:40 pm

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?

UPDATE:

Ok, I found scan option, but need to add some channels to list I think.

Wed Apr 05, 2017 4:41 pm

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?

From the CAPsMAN:

[admin@CAPsMAN] /caps-man interface> scan cap1
Flags: A - active, P - privacy, R - routeros-network, N - nstreme, T - tdma, W - wds, B - bridge
ADDRESS SSID CHANNEL SIG NF SNR RADIO-NAME ROUTEROS-VERSION
A R B 00:0C:42:05:01:27 Demo2 5180/20/a -65 -103 38 demo2 6.39rc60

MayestroPW · Wed Apr 05, 2017 4:44 pm

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

Wed Apr 05, 2017 4:49 pm

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?

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

moep · Wed Apr 05, 2017 4:50 pm

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?

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

Wed Apr 05, 2017 4:55 pm

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

Current CAPsMAN implementation doesn't support that and we do not plan to add that in near future.

pe1chl · Wed Apr 05, 2017 5:05 pm

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.

Ok thanks, that is clear to me. I'll try to test it soon. Hopefully you can add the PEAP method to the dropdown list in WebFig soon.
(most config work is done via WebFig here, I never use WinBox and use CLI when required)

moep · Thu Apr 06, 2017 4:03 pm

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)

Thu Apr 06, 2017 5:04 pm

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)

Then we would need remote access to install a debug package.
Please contact support@mikrotik.com

huntah · Thu Apr 06, 2017 11:51 pm

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?

mducharme · Fri Apr 07, 2017 9:55 pm

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

I see info on this is now in the wiki, thanks. Can you confirm that this factory script also activates with the hardware reset button? Or only the software reset command? I am wondering if we still need to use netinstall to get a factory config that is reapplied even with the hardware reset button? The wiki did not make this clear.

Thanks!

picacho99 · Mon Apr 10, 2017 1:44 pm

For these experiencing problems installing 6.39rc on RB3011: in my case it only worked netinstall but using the version associated with the 6.39rc in the software dowloads section (it is named netinstall-6.39rcXX-tile.zip). Stable netinstall (currently named netinstall-6.38.5.zip) does not seems to work.

And yes...partitions appear to work, but I did not test a partition activated and installing a previuos RouterOS version...

huntah · Mon Apr 10, 2017 8:15 pm

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?

It is fixed but It was changed and not documented in the Wiki.. The Address list is now linked to the IP Firewall Address-list.
Got this answer from support. So thanks again for support. This feature is very handy..

kissze · Tue Apr 11, 2017 1:57 pm

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

With kind regards,
Zoltan

Kindis · Tue Apr 11, 2017 3:50 pm

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

Don't know if this is related but I had a similar issue with my RB750Gr3 which turned out to be a storage problem. All changes only got committed to RAM and not to storage. A quick clean of old backups and my config is the same after a reboot.

Tue Apr 11, 2017 4:42 pm

Version 6.39rc68 has been released.

Changes since previous version:
*) 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 support for "background-scan" (CLI only) and channel "reselect-interval";
*) capsman - changed channel "width" name to "control-channel-width" and changed default values;
*) ddns - improved "dns-update" authentication validation;
*) dhcpv4 - fixed string option parser;
*) ike2 - fixed disabled DPD;
*) ike2 - fixed last EAP auth payload type;
*) ike2 - improved logging;
*) ike2 - kill only child SAs which are not re-keyed by remote peer;
*) ipsec - disallow AH+ESP combined policies ;
*) ppp - fixed rare kernel failure when receiving IPv6 address on PPP interface;
*) tr069-client - made any Download RPC overwrite configuration except ".alter";
*) tr069-client - improved LTE monitoring process;
*) winbox - allowed to specify static-dns as list;
*) winbox - do not show "dpd-max-failures" on IKEv2;
*) winbox - fixed CAPsMAN channels frequency (allow to specify a list of them);
*) winbox - fixed IPSec "mode-config" DNS settings;
*) winbox - fixed issue when working IPSec policies were shown as invalid;
*) winbox - improved "/tool torch";
*) winbox - do not allow Packet Sniffer "memory-limit" and "file-limit" lower than 10KiB;
*) winbox - show "A" flag for IPSec policies;
*) winbox - show "H" flag for IPSec installed SAs;
*) 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.

nicob · Tue Apr 11, 2017 5:15 pm

I want to report an bootloop using rc68 on my tile. (CCR1009-8G-1S-1S+PC).
All interfaces shutdown after 10 seconds of starting services.

Currently I don't have a serial port on my laptop, so no console output for now

heaven · Tue Apr 11, 2017 5:25 pm

My hap ac lite is bootloop too on rc68

bbs2web · Tue Apr 11, 2017 5:30 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.

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:

/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:

/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:

[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:

[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:

                  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:

                  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

biatche · Tue Apr 11, 2017 5:46 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.

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

I don't know if its related, but i have a hex[gateway]-crs125[switch]-hap/wap ac[access points] setup and with 6.38 on all devices. i use pretty standard default bridges, vlans and the CRS125 loses connectivity whenever theres a 6.38 device attached. i presume that default vlans/bridges do have rtsp enabled. wasted many hours trying to figure out what's wrong. worst of all, mikrotik doesnt seem interested in testing this. we have not heard any response so far on anything related to this in the forums. reverted to 6.37 for the time being

pista · Tue Apr 11, 2017 5:46 pm

After upgrade there is bootloop on hAP ac.

How to repair it?

biatche · Tue Apr 11, 2017 5:48 pm

seriously, rc should be renamed to alpha or testing. while current should be renamed to beta and bugfix to stable.

heaven · Tue Apr 11, 2017 5:53 pm

I try to restore hap ac lite by netinstall but nothing.((((((( how to restore it?

After 40 minutes I already restore it:
but strange situation. If I press reset button and power on there is not install new firmware, when I power on it without reset the router is flashed. The backups is erased on file list(((((

Chupaka · Tue Apr 11, 2017 5:55 pm

On x86, rc68 says 'info failed: std failure: timeout (13)' after Login prompt and does not work

I pressed 'Enter', RouterOS rebooted, I logged in and typed 'ip ad pr'. Router hung.After some time - again 'info failed: std failure: timeout (13)'.

UPD: 'router rebooted because some critical program crashed'

sbeauchamp · Tue Apr 11, 2017 7:14 pm

IPIP and GRE interfaces are no longer working. Upgrading to 6.39.rc68, automatically removed all my IPIP tunnels. If i try to add them back via web or CLI the router crashes and reboots. On the cli i can do /int ipip add name=TUN1 and hit enter, i get the prompt for remote address but after i type it in and hit enter it crashes.

This is on a CCR1009

napismizpravu · Tue Apr 11, 2017 7:36 pm

RB433UAH
update 6.39rc62 > 6.39rc68 => netinstall (install 6.39rc62)

amokkatmt · Tue Apr 11, 2017 7:37 pm

So, I did a downgrade on my 2011 and have logging to disk. Here we go:

17:31:34 system,info verified routeros-mipsbe-6.39rc68.npk 
17:31:34 system,info verified ntp-6.39rc68-mipsbe.npk 
17:31:34 system,info installed routeros-mipsbe-6.39rc68 
17:31:34 system,info installed ntp-6.39rc68 
17:31:34 system,info router rebooted 
17:32:05 snmp,warning timeout while waiting for program 20 
17:33:43 system,info router rebooted 
17:33:44 system,error,critical router rebooted because some critical program crashed 
17:34:13 snmp,warning timeout while waiting for program 20 
17:35:51 system,info router rebooted 
17:35:52 system,error,critical router rebooted because some critical program crashed 
17:36:22 snmp,warning timeout while waiting for program 20 
17:38:00 system,info router rebooted 
17:38:01 system,error,critical router rebooted because some critical program crashed 
17:38:31 snmp,warning timeout while waiting for program 20 
17:40:08 system,info router rebooted

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