Here you can read about the lead up to this "trimming":I have a problem with ipsec and xauth. If the xauth user name is longer than 30 characters, in the log you can see "Trimming Xauth user name". The Xauth login fail. If I cut the Xauth name to 30 characters or less, the Xauth login succeed. The original Xauth user name was "Luedenscheid_luedenscheid-aussenstellen".
With RouterOS 6.37.4 there is no problem.
11:15:58 ipsec,info respond new phase 1 (Identity Protection): 111.11.56.87[500]<=>99.231.204.198[500]
11:15:58 ipsec,info ISAKMP-SA established 111.11.56.87[4500]-99.231.204.198[4500] spi:6a36407b8d013957:e691c0e0be04100d
11:15:58 ipsec,error Trimming Xauth user name
11:15:58 ipsec,info No mode-cfg configured
11:15:58 ipsec,info XAuth login failed for user: Luedenscheid_luedenscheid-auss
11:16:02 ipsec,info respond new phase 1 (Identity Protection): 111.11.56.87[500]<=>99.231.204.198[500]
11:16:02 ipsec,info ISAKMP-SA established 111.11.56.87[4500]-99.231.204.198[4500] spi:436a58d94cf6c650:75a152295ad122d1
11:16:02 ipsec,info XAuth login succeeded for user: Luedenscheid_luedenscheid-a
11:21:18 system,info device added by admin
Thanks, but I have the problem with the Xauth user and not with the password!Here you can read about the lead up to this "trimming":I have a problem with ipsec and xauth. If the xauth user name is longer than 30 characters, in the log you can see "Trimming Xauth user name". The Xauth login fail. If I cut the Xauth name to 30 characters or less, the Xauth login succeed. The original Xauth user name was "Luedenscheid_luedenscheid-aussenstellen".
With RouterOS 6.37.4 there is no problem.
11:15:58 ipsec,info respond new phase 1 (Identity Protection): 111.11.56.87[500]<=>99.231.204.198[500]
11:15:58 ipsec,info ISAKMP-SA established 111.11.56.87[4500]-99.231.204.198[4500] spi:6a36407b8d013957:e691c0e0be04100d
11:15:58 ipsec,error Trimming Xauth user name
11:15:58 ipsec,info No mode-cfg configured
11:15:58 ipsec,info XAuth login failed for user: Luedenscheid_luedenscheid-auss
11:16:02 ipsec,info respond new phase 1 (Identity Protection): 111.11.56.87[500]<=>99.231.204.198[500]
11:16:02 ipsec,info ISAKMP-SA established 111.11.56.87[4500]-99.231.204.198[4500] spi:436a58d94cf6c650:75a152295ad122d1
11:16:02 ipsec,info XAuth login succeeded for user: Luedenscheid_luedenscheid-a
11:21:18 system,info device added by admin
viewtopic.php?f=21&t=116354&p=576081&hi ... th#p576081
RB433UAH 6.39rc35 microSD, 2x USB Flash disk, (power 24V 2A)
one USB Flash disk lost (6.38.1. works)
Thanks! Can't yet try it; is the dhcp-server already configured by the time the script runs?as a workaround:I LOVE the new script property of DHCP client. But something very basic seems to be missing - in my case the DHCP server is _not_ the gateway. However I don't see the gateway-address or like variable available. Any chance this can be added soon?Code: Select all:put [ /ip dhcp-server network get [ find $leaseActIP in address ] gateway ];
Thanks for the hint, Chupaka, used it to make the code that actually works for the usecase.Code: Select all:put [ /ip dhcp-server network get [ find $leaseActIP in address ] gateway ];
:local gatewayAddress [/ip dhcp-client get [find dhcp-server=$"server-address"] gateway]
Huh, my bad, I was thinking about dhcp-server when I was writing the answer. Glad you still found it usefulThanks for the hint, Chupaka, used it to make the code that actually works for the usecase.Code: Select all:put [ /ip dhcp-server network get [ find $leaseActIP in address ] gateway ];
Code: Select all:local gatewayAddress [/ip dhcp-client get [find dhcp-server=$"server-address"] gateway]
What is the reason to drop it ?!) firewall - discontinued support for p2p matcher (old rules will become invalid);
I think that is because it not so much efficient in this days any moreWhat is the reason to drop it ?!) firewall - discontinued support for p2p matcher (old rules will become invalid);
RB493G - THE SAME - BRICKED! after update to 6.39rc45.CHR v6.39rc45 update error, the interfaces are missing.
console error- info failed: std failure: timeout (13)
system reboots at 16% when trying to run supout.
restored from backup (6.39rc41) and retried the package update, same results.
Three reasons:
1. None of the protocols in the p2p filter are used today. Limeware? Kazaa? Really ... ?
2. This matcher also caught non-p2p traffic and interrupted normal communcations
3. You can duplicate the functionality with l7 filters. In fact, p2p filter is the same as L7 filter, but L7 has more customisation
RB493G - THE SAME - BRICKED! after update to 6.39rc45.CHR v6.39rc45 update error, the interfaces are missing.
console error- info failed: std failure: timeout (13)
system reboots at 16% when trying to run supout.
restored from backup (6.39rc41) and retried the package update, same results.
Its...... loading and ...reboots ... loading and ...reboots ... loading and ...reboots ... loading and ...reboots
Only Netinstall to 6.38.3 - helped.
So - version 6.39rc45 have a BIG BUG!
you are searching for troubles messing with RC while being 250 miles away...RB1100aHX2 BRICKED, man, this is a RC, not an alpha, can't even think how this happend.
Trying to downgrade to earlier version, unfortunately at this time i'm 250 miles away from the RB, so only can connect through layer2 (MAC) and i'm lossing the connection every X seconds and I can't upload de 11MB system file.
Just checked, I got a 450g updated normal to 45,so this crash is very specific.I have 433,433ah, Chr, crs125, base no 2, upgrade to. 45 ok.
But I get 450g that I lost access after updating,
I think is some configuration, that cause the crash and not related to hardware
Enviado de meu XT1580 usando Tapatalk
By any chance, did you have PCQ simple queues on the affected 450G?Just checked, I got a 450g updated normal to 45,so this crash is very specific.I have 433,433ah, Chr, crs125, base no 2, upgrade to. 45 ok.
But I get 450g that I lost access after updating,
I think is some configuration, that cause the crash and not related to hardware
Enviado de meu XT1580 usando Tapatalk
Enviado de meu XT1580 usando Tapatalk
No,By any chance, did you have PCQ simple queues on the affected 450G?Just checked, I got a 450g updated normal to 45,so this crash is very specific.I have 433,433ah, Chr, crs125, base no 2, upgrade to. 45 ok.
But I get 450g that I lost access after updating,
I think is some configuration, that cause the crash and not related to hardware
Enviado de meu XT1580 usando Tapatalk
Enviado de meu XT1580 usando Tapatalk
Can you tell what is causing?Seems that we have managed to reproduce this crash which was introduced in last rc release. We will try to fix it as soon as possible and release new version with fix included.
Yeap, I'll prefer to name them like that.The trouble is, MikroTik's naming is not exactly what many people expect. Personally I'd call their "RC" beta if I'd like to be nice, or alpha if I want to be safe.
Lesson learned with Mikrotik.you are searching for troubles messing with RC while being 250 miles away...RB1100aHX2 BRICKED, man, this is a RC, not an alpha, can't even think how this happend.
Trying to downgrade to earlier version, unfortunately at this time i'm 250 miles away from the RB, so only can connect through layer2 (MAC) and i'm lossing the connection every X seconds and I can't upload de 11MB system file.
I was having issues with the DHCP offered lease without success, that is why I took the risk."Lesson lerned ...."
There are three branches: bugfix, current and RC (read it as beta/alpha/test version)
It should be obvious that production system should not go further than "current" despite the name of device manufacturer.
Good morning!!) www - fixed http server vulnerability;
please add more details!!!
version affected?
what type of vulnerability?
thanks.
Is it about the pppoe-server or just the client?!) pppoe - added fastpath support when MRRU and MLPPP are enabled;
I guess this is client only.Is it about the pppoe-server or just the client?
Try contacting support by email. They may know of a way to do this, or get you a custom package (especially if you're buying hundreds of CPEs).A friendly bump on my request to have the IPv6 package enabled by default in the main RouterOS package.
We want to get purchasing and rolling out hundreds of MikroTik TR-069 routers to our customers but are holding off until we are able to do this.
I think too much to MUMGood morning!!) www - fixed http server vulnerability;
please add more details!!!
version affected?
what type of vulnerability?
thanks.
viewtopic.php?f=21&t=119308
We also need a proper set of firewall rules, simply enabling ipv6 is not enoughA friendly bump on my request to have the IPv6 package enabled by default in the main RouterOS package.
We want to get purchasing and rolling out hundreds of MikroTik TR-069 routers to our customers but are holding off until we are able to do this.
Can you tell more about this?Version 6.39rc51 has been released.
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
This is specifically for the CCR series (both problem and solution). More information here: viewtopic.php?f=1&t=112545Can you tell more about this?Version 6.39rc51 has been released.
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
Does this also improve IPsec on other multicore platforms like RB750GR3?
Did anyone else experienced the issue that the complete NAT configuration was gone after rebooting into rc51?Version 6.39rc51 has been released.
Changes since previous version:
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
*) tr069-client - fixed write for "Device.ManagementServer.URL";
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
No problem over here with the NAT or any other rules.Did anyone else experienced the issue that the complete NAT configuration was gone after rebooting into rc51?Version 6.39rc51 has been released.
Changes since previous version:
!) tile - fixed IPsec hardware acceleration out-of-order packet problem, significantly improved performance;
*) tr069-client - fixed write for "Device.ManagementServer.URL";
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
I had to manually rebuild the whole NAT cfg :/
is any chance for fix for recent linux breach ?
eg this one:
https://security-tracker.debian.org/tra ... -2017-2636
... in the Linux kernel through 4.10.1...
I think the issues you mentioned may be related to what I mentioned in #260. Infuriating.CAPSMAN controller: CCR1009
Wifi CAPS: WAP AC + HAP AC
v6.36.4:
working fine, reference speed wireless: 250-260Mbit/s
v6.38.x :
- massive wireless issues with capsman (continous disconnects, slow speeds)
- RSTP causing forwarding issues (traffic not forwarding, DHCP not getting through)
v6.39rcXX-51:
- Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)
well, since "3.2 and above(up to 4.11?)" listed as "vulnerable" unless "particular security fix" delivered - it IS VULNERABLE, i guess.is any chance for fix for recent linux breach ?
eg this one:
https://security-tracker.debian.org/tra ... -2017-2636RouterOS v6 uses v3.3.6 and don't have hdlc ...you are safe.Code: Select all... in the Linux kernel through 4.10.1...
have you seen HDLC protocol frames anywhere in RouterOS? I haven't...well, since "3.2 and above(up to 4.11?)" listed as "vulnerable" unless "particular security fix" delivered - it IS VULNERABLE, i guess.
how do you Know(!) that ROS lack "drivers/tty/n_hdlc" in it ?
do you had ROS source-code access ?
I have had issues like you on several of the networks I manage and learned the hard way to disable rstp on every mikrotik bridge in the network if using 6.38.x or later version ... guess something is severely broken in bridge rstp. It just doesn't work as expected and makes other devices disappear from network. You will find many posts regarding this issue on the forum. It is not a solution, because rstp is there for a reason but only a workaround if you really need IKEv2.6.38.x severe issues.
Alright, I'm very furious. So much wasted time and no profit. What's going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.
I do not follow how this can be let to happen in a "current" version. My setup is fairly simple and I'm no veteran. I had always had the impression that Mikrotik devices are utilized in corporate environments, schools, banks, etc. and this issue caused major outages. Worst of all I was oblivious to it, not realizing it could be a version issue due to a certain sequence of events. If it had been a simple "I upgraded, and issue started appearing" then I would have suspected its a version issue.I have had issues like you on several of the networks I manage and learned the hard way to disable rstp on every mikrotik bridge in the network if using 6.38.x or later version ... guess something is severely broken in bridge rstp. It just doesn't work as expected and makes other devices disappear from network. You will find many posts regarding this issue on the forum. It is not a solution, because rstp is there for a reason but only a workaround if you really need IKEv2.6.38.x severe issues.
Alright, I'm very furious. So much wasted time and no profit. What's going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.
JF.
Well here's the thing. I'm guessing 90% of those corporate, school, bank, whatever networks are definitely _not_ running "current" or "rc" code. In fact, I believe most of them aren't even running "bugfix" code, but even more well-proven, older releases (even if Mikrotiks standard response to literally every single problem report ever is "try current version to see if it is fixed"). I know of several decently-sized ISP networks even that still run on ROS 5.x for that reason.I do not follow how this can be let to happen in a "current" version. My setup is fairly simple and I'm no veteran. I had always had the impression that Mikrotik devices are utilized in corporate environments, schools, banks, etc. and this issue caused major outages.
Did you read the changelog before upgrading? The big warning they have? The issues you are having really sound like they are related to that change:I do not follow how this can be let to happen in a "current" version. My setup is fairly simple and I'm no veteran. I had always had the impression that Mikrotik devices are utilized in corporate environments, schools, banks, etc. and this issue caused major outages. Worst of all I was oblivious to it, not realizing it could be a version issue due to a certain sequence of events. If it had been a simple "I upgraded, and issue started appearing" then I would have suspected its a version issue.I have had issues like you on several of the networks I manage and learned the hard way to disable rstp on every mikrotik bridge in the network if using 6.38.x or later version ... guess something is severely broken in bridge rstp. It just doesn't work as expected and makes other devices disappear from network. You will find many posts regarding this issue on the forum. It is not a solution, because rstp is there for a reason but only a workaround if you really need IKEv2.6.38.x severe issues.
Alright, I'm very furious. So much wasted time and no profit. What's going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.
JF.
Anyway, as mentioned in post #260, I would like to share what made me think the CRS went faulty.
Initially, the setup was 1x Hex, 1x CRS, 1x WAP AC. Everything was working. I had decided to upgrade to the latest version before deploying more WAP AC and HAP AC. I had upgraded the Hex & WAP AC and they worked. From winbox on the HEx router, I used mac telnet to access the CRS. I tried to initiate the upgrade on the CRS by doing /system package update download which I did on WAP AC and it says "downloading now or something".. but this time it complained being unable to connect and then /system package update install which also complained the same thing. It was only then I realized I had forgotten to set the DNS on the switch. Here's the thing, RIGHT AFTER doing a /ip dns set address=8.8.8.8, i lost connectivity to the switch. WAP AC and clients connected to the switch were still pingable however. It was only a bit later I realized by "neighbors" that the version had been upgraded to 6.38.5. HEre's where I thought I did a bad flash. After resetting the device configuration several times, the device was pingable which also led me to believe that it had a borked flash. The point is: Why the heck did the upgrade happen when it complained that it can't locate the download server which is understoodable because there was no DNS set. Why did upgrade happen on its own after setting DNS? I even thought that bad flash happened because I keyed in the command twice (in similarity)
In other words, you needed to upgrade the spoke device first (probably the WAP), followed by the CRS and then the Hex, or disable STP first.What's new in 6.38 (2016-Dec-30 11:33):
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.
To avoid STP/RSTP compatibility issues with older RouterOS versions, upgrade RouterOS to v6.38 on all routers in Layer2 networks with VLAN and STP/RSTP configurations.
The recommended procedure is to start by upgrading the remotest routers and gradually do it to the Root Bridge device.
If after upgrade you experience loss of connectivity, then disabling STP/RSTP on RouterOS bridge interface will restore connectivity so you can complete upgrade process on your network.
Actually I've been looking/waiting for you on IRC for two days.Did you read the changelog before upgrading? The big warning they have? The issues you are having really sound like they are related to that change:I do not follow how this can be let to happen in a "current" version. My setup is fairly simple and I'm no veteran. I had always had the impression that Mikrotik devices are utilized in corporate environments, schools, banks, etc. and this issue caused major outages. Worst of all I was oblivious to it, not realizing it could be a version issue due to a certain sequence of events. If it had been a simple "I upgraded, and issue started appearing" then I would have suspected its a version issue.I have had issues like you on several of the networks I manage and learned the hard way to disable rstp on every mikrotik bridge in the network if using 6.38.x or later version ... guess something is severely broken in bridge rstp. It just doesn't work as expected and makes other devices disappear from network. You will find many posts regarding this issue on the forum. It is not a solution, because rstp is there for a reason but only a workaround if you really need IKEv2.6.38.x severe issues.
Alright, I'm very furious. So much wasted time and no profit. What's going on here? is 6.37.x = stable ; 6.38 = beta while 6.39 = alpha? Does Mikrotik warrant their users for such trouble? ALSO Lost a lot of credibility by my client here. I still look forward to IKEv2 so staying on 6.37 is really no solution.
JF.
Anyway, as mentioned in post #260, I would like to share what made me think the CRS went faulty.
Initially, the setup was 1x Hex, 1x CRS, 1x WAP AC. Everything was working. I had decided to upgrade to the latest version before deploying more WAP AC and HAP AC. I had upgraded the Hex & WAP AC and they worked. From winbox on the HEx router, I used mac telnet to access the CRS. I tried to initiate the upgrade on the CRS by doing /system package update download which I did on WAP AC and it says "downloading now or something".. but this time it complained being unable to connect and then /system package update install which also complained the same thing. It was only then I realized I had forgotten to set the DNS on the switch. Here's the thing, RIGHT AFTER doing a /ip dns set address=8.8.8.8, i lost connectivity to the switch. WAP AC and clients connected to the switch were still pingable however. It was only a bit later I realized by "neighbors" that the version had been upgraded to 6.38.5. HEre's where I thought I did a bad flash. After resetting the device configuration several times, the device was pingable which also led me to believe that it had a borked flash. The point is: Why the heck did the upgrade happen when it complained that it can't locate the download server which is understoodable because there was no DNS set. Why did upgrade happen on its own after setting DNS? I even thought that bad flash happened because I keyed in the command twice (in similarity)
In other words, you needed to upgrade the spoke device first (probably the WAP), followed by the CRS and then the Hex, or disable STP first.What's new in 6.38 (2016-Dec-30 11:33):
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.
To avoid STP/RSTP compatibility issues with older RouterOS versions, upgrade RouterOS to v6.38 on all routers in Layer2 networks with VLAN and STP/RSTP configurations.
The recommended procedure is to start by upgrading the remotest routers and gradually do it to the Root Bridge device.
If after upgrade you experience loss of connectivity, then disabling STP/RSTP on RouterOS bridge interface will restore connectivity so you can complete upgrade process on your network.
1) RouterOS is not affectedwell, since "3.2 and above(up to 4.11?)" listed as "vulnerable" unless "particular security fix" delivered - it IS VULNERABLE, i guess.is any chance for fix for recent linux breach ?
eg this one:
https://security-tracker.debian.org/tra ... -2017-2636RouterOS v6 uses v3.3.6 and don't have hdlc ...you are safe.Code: Select all... in the Linux kernel through 4.10.1...
how do you Know(!) that ROS lack "drivers/tty/n_hdlc" in it ?
do you had ROS source-code access ?
Where can this be found?6.39rc54 has been released.
*) ipsec - show hardware accelerated authenticated SAs;
Thanks. Not sure how I missed that when printing before. Guess I was looking for a yes/no value, not flag. Makes sense.I don't see anything in WinBox, but CLI has new flag "H - hw-authenc" in "/ip ipsec installed-sa print".
Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?*) ipsec - show hardware accelerated authenticated SAs;
You mean putting this information into winbox? https://wiki.mikrotik.com/wiki/Manual:I ... encryption. Couldn't hurt. I could see it being useful to make that information more readily available in the data sheets/brochures on routerboard.com too.Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?*) ipsec - show hardware accelerated authenticated SAs;
Yes, exactly.You mean putting this information into winbox? https://wiki.mikrotik.com/wiki/Manual:I ... encryption. Couldn't hurt. I could see it being useful to make that information more readily available in the data sheets/brochures on routerboard.com too.Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?*) ipsec - show hardware accelerated authenticated SAs;
Probably best requested as new reply in viewtopic.php?f=1&t=45934 or topic in viewforum.php?f=1 (might already exist too)- Wireless + CAPSMAN: what about airtime fairness and bandsteering?
I have requested this a few times, and each time I get pointed at the Wiki..Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?*) ipsec - show hardware accelerated authenticated SAs;
This is not fixed, the problem still persists.6.39rc54 has been released.
*) wireless - fixed false positive DFS radar detection caused by iPhone 6s devices;
I had a problem on one of my WAP ac where the wlan interfaces are not added to the bridge. Clients can connect but there is no communication with the router. And the protocol mode was set to none...!) bridge - fixed BPDU rx/tx when protocol-mode=none
can we have more information on this? thanks
I´m in the same situation: throughput is rather low. I have CAPSMAN with WAP AC devices.CAPSMAN controller: CCR1009
Wifi CAPS: WAP AC + HAP AC
v6.36.4:
working fine, reference speed wireless: 250-260Mbit/s
v6.38.x :
- massive wireless issues with capsman (continous disconnects, slow speeds)
- RSTP causing forwarding issues (traffic not forwarding, DHCP not getting through)
v6.39rcXX-51:
- Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)
We need more info how to reproduce this problem. Step by step so we could try to reproduce this problem.v6.39rcXX-51:
- Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)
So I tested with CAPSMAN => Configuration => Distance set to indoors AND CAPSMAN => Configuration => Rates empty setting.We need more info how to reproduce this problem. Step by step so we could try to reproduce this problem.v6.39rcXX-51:
- Wireless speed issue: speed only half (~ 140Mbit/s; half speed compared to v6.36.4; downgrading back to 6.36.4 results in higher speed)
What wireless packages you used on the 6.36.4 and did you downgrade both CAPsMAN and CAP?
What does "all other RouterOS priorities" mean?*) ethernet - reversed poe-priority on hEX PoE and OmniTIK 5 PoE to make "poe-priority" consistent to all other RouterOS priorities;
Does this apply to upgrading from 6.38 as well? Currently it clears all configuration when upgrading as wellBackup should be restored to same version of ROS as i have been made.
You should try /export your configuration if you want to restore it to the newer version of ROS
I has this same issue. I think it may be from the addition of the partition support.A RB3011 with a regular configruation when upgraded from v6.38.5 to v6.39.55 or v6.39.58 device becomes unusable: reboots again and again until it is recovered with reset and netinstall.
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. I did have extra packages installed and was running dude.A RB3011 with a regular configruation when upgraded from v6.38.5 to v6.39.55 or v6.39.58 device becomes unusable: reboots again and again until it is recovered with reset and netinstall.
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.
What is wrong with "zcybercomputing"?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.
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.xIn 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.
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.
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.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
Does this fix is related to [Ticket#2017032822000978]?*) ethernet - fixed rare switch chip hang (could cause port flapping);
Wow, finally niceVersion 6.39rc62 has been released.
*) wireless - added PEAP authentication support for wireless station mode;
Hooray!!! Finally we can phase out PSK!Wow, finally niceVersion 6.39rc62 has been released.
*) wireless - added PEAP authentication support for wireless station mode;
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.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
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.
Wow! That's excellent! How??*) tr069-client - added support for uploading/downloading factory script;
Hi Strods,*) capsman - added ability to specify multiple channels in frequency field;
Yes, it will choose one of the specified frequencies.Is this so that Auto-Channel will only select one of the frequencies listed ?*) capsman - added ability to specify multiple channels in frequency field;
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?still not fixed in 6.39rc62
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.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
How does background-scan works? In winbox I still can't run background scan on capsman interfaces.*) capsman - added support for "background-scan" and channel "reselect-interval";
Winbox support for all the new CAPsMAN Features are not made yet. You need to use console.How does background-scan works? In winbox I still can't run background scan on capsman interfaces.*) capsman - added support for "background-scan" and channel "reselect-interval";
I ran it from cap router, not from capsman router.failure: background scan not supported in this state
Ok, CLI only was added later... I was checking via WebFig.Version 6.39rc62 has been released.
Changes since previous version:
*) wireless - added PEAP authentication support for wireless station mode (CLI only);
It will be only supported from the CAPsMAN side.When I start background scan on cap it tells me:I ran it from cap router, not from capsman router.failure: background scan not supported in this state
Then how to run that scan?It will be only supported from the CAPsMAN side.When I start background scan on cap it tells me:I ran it from cap router, not from capsman router.failure: background scan not supported in this state
From the CAPsMAN:Then how to run that scan?It will be only supported from the CAPsMAN side.When I start background scan on cap it tells me:I ran it from cap router, not from capsman router.failure: background scan not supported in this state
Yes, you need to specify the mschapv2-username/password setting. Also I suggest to set the tls-mode=do-not-verify-certificate option.Ok, CLI only was added later... I was checking via WebFig.Version 6.39rc62 has been released.
Changes since previous version:
*) wireless - added PEAP authentication support for wireless station mode (CLI only);
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?
First of all: I had the problems with version 6.39rc60 not rc62. I now upgraded to rc62 and will check again.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?still not fixed in 6.39rc62
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.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
Current CAPsMAN implementation doesn't support that and we do not plan to add that in near future.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...
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.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.
The problem is still present in 6.39rc62, it occured in the middle of the night (3:30)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
Then we would need remote access to install a debug package.The problem is still present in 6.39rc62, it occured in the middle of the night (3:30)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
It seems this is not fixed even in 6.39rc62. How/where can we specify black list for discovery?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
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.*) tr069-client - added support for uploading/downloading factory script;
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.It seems this is not fixed even in 6.39rc62. How/where can we specify black list for discovery?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
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.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)?
/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
/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
[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
[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
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
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 beingSpanning 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:Router 2: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
Status on Router 1: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 2: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
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:Status on Router 2:Code: Select allstate: 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
Code: Select allstate: 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
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
And fix reboot loop on hAPac ? Because I have no EoIP or IPIP tunnels.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.
I wrote to the support.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.
At the top of the 6.38 changelog there is this answer to your issue: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.
and what's the answer?At the top of the 6.38 changelog there is this answer to your issue: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.
Since 6.38 BPDUs are sent and processed with out the VLAN tag.and what's the answer?At the top of the 6.38 changelog there is this answer to your issue: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.
He said its broken, so what's the fix?Since 6.38 BPDUs are sent and processed with out the VLAN tag.and what's the answer?At the top of the 6.38 changelog there is this answer to your issue: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.
int vlan add name=vlanXXX interface=bridge vlan-id=XXX
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.
Too little context to say anything meaningful!Thoughts?
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.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.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
Seems to got same issue on my RB951Ui-2HnD. Updated from 6.39rc62 to 6.39rc72, now IKEv2 functionality is lost.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
If you're still running the v72 maybe you can put the IP someware in strongswan to if that differs.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'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: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)
Oops. Seems that not only my fault.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.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.
Come on! rc72 was released last week!What's going on? Mikrotik stopped updating? Update stopped on rc72
Could you please shed some light on the changes?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;
.
+1Is there a chance to get the rpfilter matcher assuming it is not yet available?
viewtopic.php?f=2&t=120863
Having same issue on RB953GS-5HnT,I am also suffering from this symptom.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
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.