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 ?
have you seen HDLC protocol frames anywhere in RouterOS? I haven’t…
Just lets take random piece of code from linux and then just assume that it is used in RouterOS and assume that it has the same vulnerability…
This is ridiculous.
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.
JF.
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.
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)
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.
Once you learn that indeed “bugfix” is the absolute border of what you will want to run in any more-than-lab-sized production network without previous testing, it’s really not too bad. I am running 6.37.5 without any trouble at all on a bunch of different (CHR, x86, mmips, mipsbe, tile) devices and generally never had trouble sticking to the “bugfix” tree. If you really really need a new feature or fix in a current or rc version, give that one a thorough lab test followed by a limited production rollout and another testing period before actually rolling it out everywhere. If you don’t want or can’t follow that procedure, you’re better off waiting for the particular fix or feature to soak down into “bugfix” releases.
It’s not an issue that’s isolated to Mikrotik either. I dare you to go grab the most recent ED IOS versions that Cisco gives away for their kit and carelessly throw it onto your devices. I’m pretty sure something will probably go wrong, somewhere - which is why you’d want to choose a MD branch that’s had a couple rebuilds already. Which is what “bugfix” is, more or less.
I hope banks etc run Cisco, Juniper, or something like this.
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:
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.
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.
Actually I’ve been looking/waiting for you on IRC for two days.
- RouterOS is not affected
- Even if it would be, RouterOS users have no ability to run their own programs. It couldn’t be applicable anyway.
6.39rc54 has been released.
Changes since previous version;
*) ike1 - fixed ph2 ID logging;
*) ipsec - allow mixing aead algorithms in proposal;
*) ipsec - show hardware accelerated authenticated SAs;
*) lte - added initialization for Cinterion;
*) netinstall - fixed typos;
*) ppp-client - added support for Datacard 750UL, DWR-730 and K4607-Zr;
*) snmp - added optical table;
*) snmp - added fan-speed OIDs in “/system health print oid”;
*) snmp - fixed rare crash;
*) snmp - improved getall filter;
*) tr069-client - added “Device.WiFi.NeighboringWiFiDiagnostic.” support;
*) tr069-client - added Upload RPC “2 Vendor Log File” support;
*) tr069-client - fixed “Device.ManagementServer.” value update;
*) tr069-client - fixed crash on =acs-url change special case;
*) userman - allow “name-for-user” to be empty and not unique;
*) 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.
Where can this be found?
I don’t see anything in WinBox, but CLI has new flag “H - hw-authenc” in “/ip ipsec installed-sa print”.
Thanks. Not sure how I missed that when printing before. Guess I was looking for a yes/no value, not flag. Makes sense.
Is there any possibility that WinBox could highlight the algorithms that are hardware accelerated on each platform?
You mean putting this information into winbox? https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Hardware_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.
Yes, exactly.
- Wireless + CAPSMAN: what about airtime fairness and bandsteering?
Probably best requested as new reply in http://forum.mikrotik.com/t/feature-requests/41609/1 or topic in https://forum.mikrotik.com/viewforum.php?f=1 (might already exist too)
I have requested this a few times, and each time I get pointed at the Wiki..
I really wish they would do this, even if it was under “/system resources” and showed which algorithms are accelerated in hardware.. It’s all there in dmesg so the dev’s can easily obtain the information.
Version 6.39rc55 has been released.
Changes since previous version:
!) bridge - fixed BPDU rx/tx when protocol-mode=none;
*) api - fixed double dynamic flags for “/ip firewall address-list print”;
*) console - fixed DHCP/PPP add-default-route distance minimal value to 1;
*) console - fixed “/ip neighbor discovery” export;
*) console - fixed crash;
*) console - fixed incorrect “:put [/lcd get enabled]” value;
*) userman - automatically select all newly created users to generate vouchers;
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.