v6.45.7 [stable] is released!

emils · Mon Oct 28, 2019 4:10 pm

RouterOS version 6.45.7 has been released in public "stable" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.45.7 (2019-Oct-24 08:44):

MAJOR CHANGES IN v6.45.7:
----------------------
!) lora - added support for LoRaWAN low-power wide-area network technology for MIPSBE, MMIPS and ARM;
!) package - accept only packages with original filenames (CVE-2019-3976);
!) package - improved package signature verification (CVE-2019-3977);
!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);
----------------------

Changes in this release:

*) capsman - fixed frequency setting requiring multiple frequencies;
*) capsman - fixed newline character missing on some logging messages;
*) conntrack - properly start manually enabled connection tracking;
*) crs312 - fixed combo SFP port toggling (introduced in v6.44.5);
*) crs3xx - correctly display link rate when 10/100/1000BASE-T SFP modules are used in SFP+ interfaces;
*) crs3xx - fixed management access when using switch rule "new-vlan-priority" property;
*) export - fixed "bootp-support" parameter export;
*) ike2 - fixed phase 1 rekeying (introduced in v6.45);
*) led - fixed default LED configuration for RBLHG5nD;
*) lte - fixed modem not receiving IP configuration when roaming (introduced in v6.45);
*) radius - fixed open socket leak when invalid packet is received (introduced in v6.44);
*) sfp - fixed "sfp-rx-power" value for some transceivers;
*) snmp - improved reliability on SNMP service packet validation;
*) system - improved system stability for devices with AR9342 SoC;
*) winbox - show SFP tab for QSFP interfaces;
*) wireless - added "canada2" regulatory domain information;
*) wireless - improved stability when setting fixed primary and secondary channels on RB4011iGS+5HacQ2HnD-IN;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

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 some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

R1CH · Mon Oct 28, 2019 8:30 pm

!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);

Could you give some more info about the exploitability of this? Are all situations where RouterOS parses a DNS packet vulnerable? Eg router used in typical setup - DNS server for LAN and sends queries to the internet (allow-remote-requests=yes) and router used only for local DNS (allow-remote-requests=no)?

bbs2web · Mon Oct 28, 2019 9:09 pm

Full 'disclosure':
https://medium.com/tenable-techblog/rou ... e0b07c0b21

doneware · Mon Oct 28, 2019 11:01 pm

Could you give some more info about the exploitability of this?

"Simply disabling Winbox mitigates all of these attacks." - i couldn't agree more with this approach.
i understand that winbox was a key for many happy current RouterOS users to get acquainted with networking, as for many the CLI still kind of scary, and it is still doing it.
on the other hand, it is hard (if not impossible) to keep all these management interfaces (CLI, webfig, winbox, API) consistent and trouble-free. winbox is a great example for lacking behind in new features. i notoriously disable winbox on each unboxed device, i kept doing this since i laid my hands on the very first RouterOS device i encountered - i never liked to rely on windows, but that's just a personal preference.
I don't despise the existence of GUI tools, i just think that if there's something like winbox, it should rely on a 'standards-based' interface, like the API-SSL. or even based on SSH. i cannot imagine how hard it is to carry out such a drastic change to an existing ecosystem though.

never the less, the package system related exploits would have been still dangerous, as DNS queries are easily manipulated (a DNSSEC aware resolver and DNSSEC signed zone for mikrotik.com would be a good way forward). thanks for the fixes in such a short time.

Sob · Tue Oct 29, 2019 12:15 am

RouterOS without WinBox is like car without seats, it still runs, but it's not enjoyable ride. But it's clear now that it's not good idea to let it be exposed to whole world. I though that it shouldn't be a problem anymore, that MikroTik surely fixed it, to require robust authentication first before allowing to do anything else, but clearly not. Why was that DNS proxy functionality even there?

darkmanlv · Tue Oct 29, 2019 12:21 am

Hello everyone.

Device: RouterBOARD 941-2nD
Version installed: 6.45.6
Can`t upgrade to 6.45.7, not enough space to upgrade

how to upgrade?

krafg · Tue Oct 29, 2019 12:27 am

*) lte - fixed modem not receiving IP configuration when roaming (introduced in v6.45);

Very interesting. I think that is the issue that I had:

download/file.php?id=38244

Regards.

eworm · Tue Oct 29, 2019 9:28 am

*) ike2 - fixed phase 1 rekeying (introduced in v6.45);

This is supposed to fix "ipsec,error Mikrotik: got fatal error: INVALID_SYNTAX"?

Works well on all my devices. Thanks Mikrotik for the update!

Kindis · Tue Oct 29, 2019 10:44 am

Updated 4011, 3011, wAP AC, RB750gr3 and hAP AC2 without issues.

CsXen · Tue Oct 29, 2019 10:45 am

Hi.

RouterOS version 6.45.7 has been released in public "stable" channel!
!) package - accept only packages with original filenames (CVE-2019-3976);
!) package - improved package signature verification (CVE-2019-3977);
!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);

Since when exists these vulnerabilities ? Or which versions affected ? v5.xx ? v6.xx ?
If I set max cache time to 0s... can it prevent the cache poisoning ?
If I set static resolver names... can it prevent the cache poisoning ?

Will you these fixes backport to mipsle branch ?

Best regards: CsXen

Tue Oct 29, 2019 10:54 am

see https://blog.mikrotik.com

mszru · Tue Oct 29, 2019 11:10 am

Can`t upgrade to 6.45.7, not enough space to upgrade

how to upgrade?

You may try downgrade first to an earlier stable version (e.g. 6.43.7) which takes less space on the device and then upgrade to 6.45.7

mada3k · Tue Oct 29, 2019 12:01 pm

"Simply disabling Winbox mitigates all of these attacks." - i couldn't agree more with this approach.
i understand that winbox was a key for many happy current RouterOS users to get acquainted with networking, as for many the CLI still kind of scary, and it is still doing it.
on the other hand, it is hard (if not impossible) to keep all these management interfaces (CLI, webfig, winbox, API) consistent and trouble-free. winbox is a great example for lacking behind in new features. i notoriously disable winbox on each unboxed device, i kept doing this since i laid my hands on the very first RouterOS device i encountered - i never liked to rely on windows, but that's just a personal preference.
I don't despise the existence of GUI tools, i just think that if there's something like winbox, it should rely on a 'standards-based' interface, like the API-SSL. or even based on SSH. i cannot imagine how hard it is to carry out such a drastic change to an existing ecosystem though.

I couln't agree more.

Being tied to Windows and specific client versions is just troublesome. You don't see Cisco & Juniper putting much effort on GUI clients for their stuff (altough it exists).

florid · Tue Oct 29, 2019 12:06 pm

My hex Poe upgrade from 6.45.6 to 6.45.7, the avg processor CPU increases to 5% from 2% before. Librenms snmp has a very clear graph.
Edit: CPU became normal after 1 hour and 10 min. No idea what it was doing. Everything else looks normal at that time. No spike of traffic. Maybe recalculate address list or run some scripts after firmware upgrade?

R1CH · Tue Oct 29, 2019 12:26 pm

At a high level, “messages” sent to the Winbox port can be routed to different binaries in RouterOS based on an array-based numbering scheme.

Sigh... who designed this braindead protocol that allows UNAUTHENTICATED USERS to invoke whatever binary they want?! Any programmer could see what a terrible idea this is. It seems the Winbox protocol needs to be scrapped and rebuilt with security in mind from day one rather than band-aid patches for vulnerability after vulnerability.

mozerd · Tue Oct 29, 2019 12:48 pm

RouterOS without WinBox is like car without seats, it still runs, but it's not enjoyable ride. But it's clear now that it's not good idea to let it be exposed to whole world. I though that it shouldn't be a problem anymore, that MikroTik surely fixed it, to require robust authentication first before allowing to do anything else, but clearly not. Why was that DNS proxy functionality even there?

+10,000
Could not agree more

emils · Tue Oct 29, 2019 12:49 pm

*) ike2 - fixed phase 1 rekeying (introduced in v6.45);
This is supposed to fix "ipsec,error Mikrotik: got fatal error: INVALID_SYNTAX"?

Works well on all my devices. Thanks Mikrotik for the update!

Yes.

danunjaya123 · Tue Oct 29, 2019 1:09 pm

Is there any updates on IPv6 related ?

RouterOS version 6.45.7 has been released in public "stable" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.45.7 (2019-Oct-24 08:44):

MAJOR CHANGES IN v6.45.7:
----------------------
!) lora - added support for LoRaWAN low-power wide-area network technology for MIPSBE, MMIPS and ARM;
!) package - accept only packages with original filenames (CVE-2019-3976);
!) package - improved package signature verification (CVE-2019-3977);
!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);
----------------------

Changes in this release:

*) capsman - fixed frequency setting requiring multiple frequencies;
*) capsman - fixed newline character missing on some logging messages;
*) conntrack - properly start manually enabled connection tracking;
*) crs312 - fixed combo SFP port toggling (introduced in v6.44.5);
*) crs3xx - correctly display link rate when 10/100/1000BASE-T SFP modules are used in SFP+ interfaces;
*) crs3xx - fixed management access when using switch rule "new-vlan-priority" property;
*) export - fixed "bootp-support" parameter export;
*) ike2 - fixed phase 1 rekeying (introduced in v6.45);
*) led - fixed default LED configuration for RBLHG5nD;
*) lte - fixed modem not receiving IP configuration when roaming (introduced in v6.45);
*) radius - fixed open socket leak when invalid packet is received (introduced in v6.44);
*) sfp - fixed "sfp-rx-power" value for some transceivers;
*) snmp - improved reliability on SNMP service packet validation;
*) system - improved system stability for devices with AR9342 SoC;
*) winbox - show SFP tab for QSFP interfaces;
*) wireless - added "canada2" regulatory domain information;
*) wireless - improved stability when setting fixed primary and secondary channels on RB4011iGS+5HacQ2HnD-IN;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

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 some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

anav · Tue Oct 29, 2019 1:33 pm

If I dont use winbox externally and I change the default port to something else, where is the risk from this latest vulnerability?

If I was to use winbox externally via VPN ( IKEv2), where is the risk?

PS........ ARM zip main package damaged? I had to use the all 'extra' packages.

Tue Oct 29, 2019 2:13 pm

RouterOS without WinBox is like car without seats, it still runs, but it's not enjoyable ride. But it's clear now that it's not good idea to let it be exposed to whole world. I though that it shouldn't be a problem anymore, that MikroTik surely fixed it, to require robust authentication first before allowing to do anything else, but clearly not. Why was that DNS proxy functionality even there?
+10,000
Could not agree more

Yes. Winbox is a reason to use Mikrotik. Fast easy managment without IP setup is a big deal handling problems in the field. Every box needs filtering anyway ...

mozerd · Tue Oct 29, 2019 2:24 pm

If I dont use winbox externally and I change the default port to something else, where is the risk from this latest vulnerability?
If I was to use winbox externally via VPN ( IKEv2), where is the risk?

@anav
No need to change winbox default port when using winbox internally -- risk is only from compromised workstations as noted below.
When accessing Winbox externally via VPN no risk

Always remember that your greatest risk is an infected workstation [pc/laptop/smart-device] that is infected with malware having the capability to intercept your data that can include everything you do to access whatever. This is not OS agnostic --- all OS's can be compromised so SAFETY is based on common sense security measure and not paranoia.

doneware · Tue Oct 29, 2019 5:38 pm

No need to change winbox default port when using winbox internally -- risk is only from compromised workstations as noted below.

and that risk is huge. people tend to forget, that there is no such thing as "safe network" anymore. in contrary, the network is a constant battlefield, and you & your devices better be prepared to face these challenges. in the good old days, it was like a gun: one side was safe, the other one was dangerous. now the safe side is dangerous as well, admittedly less dangerous based on the rule of scale but still.

please, everyone, this is not a rant against your safe home setup - but imagine a device which you deployed as a networking professional / solution provider into a customers network. you have no control above the infrastructure, no control above the IT environment, their sw update strategies, nothing. it is essentially a minefield. so you better lock the router down as much as possible if you are the one to manage it. having a proper VPN is a good start.

Apropos VPNs: please - as Mikrotik seems to be quite ok with leaving PPTP client/server still available, and many people are quite happy using it as a *secure* means of communication - just consider PPTP doesn't exist anymore, and L2TP doesn't work without IPSec.

doneware · Tue Oct 29, 2019 5:50 pm

Being tied to Windows and specific client versions is just troublesome.

and yet we still have netinstall as a windows only tool. luckily i hardly ever need to use this, but i once considered to reverse engineer it and try to build it with some scripting tools and open source sw so it can be used with unix-like operating systems. if you do stuff on large scale, like commissioning a loads of devices, GUI doesn't scale well. i created my mass provisioning tools to rely on IPv6 & SSH, but still the first step - logging in, enabling ipv6, rebooting the device - is a bit painful. sure it can be scripted - i did it, but having IPv6 enabled right out of the box is just satisfying.

my biggest pain is not able to update the device's default configuration (the one to it reverts upon user reset) without netinstall.
OS recovery or conditionless automated OS installation would be my next pain-point.

if anyone listens: we need tools that can be used in headless automated environments.

darkmanlv · Tue Oct 29, 2019 10:58 pm

You may try downgrade first to an earlier stable version (e.g. 6.43.7) which takes less space on the device and then upgrade to 6.45.7

thanks, hap lite upgraded to 6.45.7 first upgrading to 6.43.7 and then to newest one

mjraiha · Tue Oct 29, 2019 11:36 pm

I have Telit LM940+adapter card connected to RBM33G USB3 port. I had to revert back to v6.45.6 to get this LTE card back in use. LTE card stayed in Functionality: minimum. Also, couldn't give any AT commands on CLI as it said that "it's not supported".

eddieb · Wed Oct 30, 2019 9:09 am

updating to 6.45.7 went smooth ... from 6.45.6 to 6.45.7 done thru the dude

No problems so far

Keyko · Wed Oct 30, 2019 10:12 am

Cannot update cap points RB951G-2HnD . Sending upgrade request from the controller's capsman - writes - I can't find a file with an update, "..... no such file".
I go to points - in "Packages" - and it finds updates.

mkx · Wed Oct 30, 2019 11:28 am

When doing CAP upgrades via CAPsMAN, you have to manually upload needed packages to the place configured in /caps-man manager ... in particular properties package-path= and upgrade-policy= (that's a directory on CAPsMAN device itself, I don't know if it's possible to set it to some external resource). CAP won't search for upgrade packages on usual internet sources.

I successfully upgraded RB951G being a CAP (with RBD52G as CAPsMAN) from 6.45.1 to 6.45.7 by first uploading upgrade packages for MIPSBE to CAPsMAN and later upgrading CAPsMAN (using usual check-for-upgrades procedure).

pekr · Wed Oct 30, 2019 11:47 am

"Simply disabling Winbox mitigates all of these attacks." - i couldn't agree more with this approach.
i understand that winbox was a key for many happy current RouterOS users to get acquainted with networking, as for many the CLI still kind of scary, and it is still doing it.
on the other hand, it is hard (if not impossible) to keep all these management interfaces (CLI, webfig, winbox, API) consistent and trouble-free. winbox is a great example for lacking behind in new features. i notoriously disable winbox on each unboxed device, i kept doing this since i laid my hands on the very first RouterOS device i encountered - i never liked to rely on windows, but that's just a personal preference.
I don't despise the existence of GUI tools, i just think that if there's something like winbox, it should rely on a 'standards-based' interface, like the API-SSL. or even based on SSH. i cannot imagine how hard it is to carry out such a drastic change to an existing ecosystem though.
I couln't agree more.

Being tied to Windows and specific client versions is just troublesome. You don't see Cisco & Juniper putting much effort on GUI clients for their stuff (altough it exists).

Guys, please stop it. There is no Mikrotik without a Winbox. Web interface, though comparable in funcitonality, is still not there. Kill Winbox and I am done with MT. Maybe you should ask Cisco and Juniper then, why they are so lame in their GUI tools care. There's more to the security, than just the GUI tools.

Keyko · Wed Oct 30, 2019 12:16 pm

When doing CAP upgrades via CAPsMAN, you have to manually upload needed packages to the place configured in /caps-man manager ... in particular properties package-path= and upgrade-policy= (that's a directory on CAPsMAN device itself, I don't know if it's possible to set it to some external resource). CAP won't search for upgrade packages on usual internet sources.

He give points the command to download the file himself. Why are some points (hAP AC + HEX poe) updated without any problems, while others (RB951G+ hEX/RB3011) write that they can't find the file?

jimmer · Wed Oct 30, 2019 1:01 pm

Hi all,

Not sure if this has been noted or not but i'm getting the following error if I click on the Winbox download link from webfig on 6.45.7:

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>7A47BBA10EFFA2E7</RequestId>
<HostId>
GIj6ycRxN9Xte72z8CYEUUr+uf6IVSHkMqSuiUAbymbQ+955btcsZAP5KrxfOwmtdyl6Nyx+qYs=
</HostId>
</Error>

When i click winbox, I am directed to this URL:

https://download2.mikrotik.com/winbox.exe

Anyone else seeing this?

Also seeing the same error if you click on the Winbox icon on the login screen, could be a site config problem at Mikrotik?

Edit: This is on the MIPSBE Platform - RB2011iUAS-RM

Kind Regards,
Jim.

pe1chl · Wed Oct 30, 2019 1:14 pm

!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);
Could you give some more info about the exploitability of this? Are all situations where RouterOS parses a DNS packet vulnerable? Eg router used in typical setup - DNS server for LAN and sends queries to the internet (allow-remote-requests=yes) and router used only for local DNS (allow-remote-requests=no)?

It looks like those scenarios are not really vulnerable. The only risk is allowing others than the admin access to the Winbox port (8291).
As many times before, the winbox protocol has a vulnerability and it remains advisable to restrict access to winbox to as small a group as possible.
(at the very least allow it only from trusted networks and not from internet, but when you do not trust your internal users/visitors even restrict it further to an admin system/network)

mkx · Wed Oct 30, 2019 1:25 pm

Why are some points (hAP AC + HEX poe) updated without any problems, while others (RB951G+ hEX/RB3011) write that they can't find the file?

The mentioned devices are not all the same architecture: hAP AC and hEX PoE are both MIPSBE, so it is RB951G, but hEX (the current one - RB750Gr3) is MMIPS and RB3011 is ARM. All in all that's 3 distinct sets of files that you have to provide.

If, for example, hAP AC is CAPsMAN and HEX PoE is a CAP, then uploading MIPSBE packages to hAP AC allows to upgrade both devices.

If, on the other hand, RB951G is CAPsMAN and hEX and/or RB3011 are CAP, then you have to upload packages for all 3 different architectures to CAPsMAN ... one architecture for upgrading itself and other architectures to upgrade CAPsMAN devices.

Sunlight · Wed Oct 30, 2019 1:37 pm

RB4011iGS+5HacQ2HnD

photo_2019-10-30_14-26-59.jpg

Keyko · Wed Oct 30, 2019 1:45 pm

mkx
The mentioned devices are not all the same architecture: hAP AC and hEX PoE are both MIPSBE, so it is RB951G, but hEX (the current one - RB750Gr3) is MMIPS and RB3011 is ARM. All in all that's 3 distinct sets of files that you have to provide.

Wow! Thank you for that information!

Kraken2k · Wed Oct 30, 2019 3:02 pm

Upgraded RB2011, RB1100AHx4, hAP ac without any problems and running ok for few days already.

For hAP lite, I had to delete all extra files on router, including config backups to make the update work, but after that also no problems.

doneware · Wed Oct 30, 2019 5:08 pm

Guys, please stop it. There is no Mikrotik without a Winbox. Web interface, though comparable in funcitonality, is still not there. Kill Winbox and I am done with MT.

don't want to turn the thread into a flame war. i agree, a lot of people need GUI, a lot of people love the look&feel of winbox, sure thing. not like i'd have the power or the will to take away your tools. in some parts winbox app is directly responsible for the popularity of RouterOS because it made the 'mystic networking stuff' accessible for the masses.
my point was merely to kill the "winbox protocol" and rather move the communication stack of the "well known and beloved" GUI tool over API or SSH. the convenient point-and-click thingie could remain there forever in unchanged visual format, given the large and loyal user base.

if it is documented - like SSH and API are - others can build similar GUI tools for different operating systems, and you would not need to rely on emulation/virtual machines just to have access to your device from a non windows environment. the protocol winbox uses is basically a black box, researchers are reverse engineering it with more or less success.

but i'm just stating my opinion, that's all.

pe1chl · Wed Oct 30, 2019 5:59 pm

my point was merely to kill the "winbox protocol" and rather move the communication stack of the "well known and beloved" GUI tool over API or SSH. the convenient point-and-click thingie could remain there forever in unchanged visual format, given the large and loyal user base.

if it is documented - like SSH and API are - others can build similar GUI tools for different operating systems, and you would not need to rely on emulation/virtual machines just to have access to your device from a non windows environment. the protocol winbox uses is basically a black box, researchers are reverse engineering it with more or less success.

Well, winbox could of course use API to do what it is doing now... no idea why a separate protocol is used for this, it could be that it is more efficient, it could be due to history.
But it is a clear fact that the winbox protocol sucks and that its implementation in the router sucks even more.
It is a bit worrying that for every non-authenticated exploit found and fixed, there is at least one more found by the malvolents. And they all appear to be similarly-structured.
You would expect that after such an exploit becomes known (generic: some RPC function that has side-effects or can retrieve sensitive info can be called without authentication), someone at MikroTik is tasked with going along the entire winbox RPC table to make sure that this can not happen anymore, but that apparently is too much to expect.

maryaadmins · Thu Oct 31, 2019 11:19 am

hi
we have dhcp-server behind cisco router (dhcp-relay server)
after upgrade dhcp-server stops giving leases and fills leases with mac-address 00:00:00:00:00:00 and status conflict
disabling conflict detection resolves the issue

jacekes · Thu Oct 31, 2019 11:26 am

Why do both v6.45.x and v7beta keep appearing in turns in the development channel?

flameproof · Thu Oct 31, 2019 12:13 pm

After upgrading a CCR1016 to 6.45.7, I have "lost" all access to RADIUS settings. From WebFig, RADIUS tab shows no entries (I had three, one dhcp and two ppp, with one being UDP and the other RADSEC).

From cli, /radius print just hangs, no output. /radius remove [ find ] also hangs.

From WinBox, nothing shows either, and trying to add results in absolutely nothing happening.

RADIUS is the forgotten child, many versions ago WebFig stopped showing RADIUS statistics, all being stuck on 0, and it has never been fixed. Now RADIUS totally dies. Please fix!!

emils · Thu Oct 31, 2019 12:19 pm

jacekes Should be fixed now.

Sunlight, flameproof Please send supout.rif file to support@mikrotik.com

maryaadmins Check if addresses are not given out by the Cisco router. In most cases, your described issue is caused by another DHCP server in your network.

jacekes · Thu Oct 31, 2019 12:40 pm

Thanks Emils!

flameproof · Thu Oct 31, 2019 1:05 pm

jacekes Should be fixed now.

Sunlight, flameproof Please send supout.rif file to support@mikrotik.com

maryaadmins Check if addresses are not given out by the Cisco router. In most cases, your described issue is caused by another DHCP server in your network.

Have just sent a supout and export verbose, thank you!

roe1974 · Thu Oct 31, 2019 2:35 pm

SORRY WRONG HERE .... i use 6.44.6 longterm

I had a problem after upgrade on LtAP with DHCP Server and the raspberry on the ETH Port.
I took 2-3 LtAP reboots so that the Raspberry finally got a IP adresse from DHCP ( always ETH down/ETH up/ETH down/ETH up ....)

Richard

Didzito · Fri Nov 01, 2019 9:50 am

When will be fixed that Ipsec tunnels hung up? It starts from 6.45.4 and continues. Helps only clear connection.

sindy · Fri Nov 01, 2019 10:09 am

When will be fixed that Ipsec tunnels hung up?

Can you be more verbose regarding what you refer to? 6.45.4 is a factory-only release, and all your other posts refer to BGP. IPsec is important for me so I am really interested in the details.

Other than that, have you sent the related supout.rif to support@mikrotik.com? Developers cannot resolve an issue they cannot reproduce.

Didzito · Fri Nov 01, 2019 10:19 am

When will be fixed that Ipsec tunnels hung up?
Can you be more verbose regarding what you refer to? 6.45.4 is a factory-only release, and all your other posts refer to BGP. IPsec is important for me so I am really interested in the details.

Other than that, have you sent the related supout.rif to support@mikrotik.com? Developers cannot resolve an issue they cannot reproduce.

Yes, after deeper monitoring i became to conclusion that BGP failure coming from Ipsec Hung up. When its happens next time I ll sent suppout.rif

Fri Nov 01, 2019 10:29 am

6.45.7 is a free upgrade, please install it, it is much better than what you use now.

sindy · Fri Nov 01, 2019 10:46 am

after deeper monitoring i became to conclusion that BGP failure coming from Ipsec Hung up. When its happens next time I ll sent suppout.rif

That statement gives no details regarding what actually happens and what IPsec configuration you use - there are many possible variants of IPsec configuration and only some of them may be affected. You may want to open a dedicated topic and post a network diagram and anonymized configuration exports there.

Didzito · Fri Nov 01, 2019 11:16 am

after deeper monitoring i became to conclusion that BGP failure coming from Ipsec Hung up. When its happens next time I ll sent suppout.rif
That statement gives no details regarding what actually happens and what IPsec configuration you use - there are many possible variants of IPsec configuration and only some of them may be affected. You may want to open a dedicated topic and post a network diagram and anonymized configuration exports there.

It happens again, I sent suppout.rif to support email. This problem starts after v6.45.3. I use Gre over ipsec with BGP routing.

sindy · Fri Nov 01, 2019 12:34 pm

I use Gre over ipsec with BGP routing.

Can you post the peer configuration and profile and policy proposal you use? E.g. IKE(v1) and IKEv2 are very different internally. Also, GRE has problems of its own, I had problems with startup of GRE over IPsec if the tunnel was enabled before the firewall rules were set up at both ends.

Deantwo · Fri Nov 01, 2019 2:46 pm

Didzito, sindy: It might be better if you two take that issue to a new thread, since it doesn't sound like it is directly related to this update.

Kazek · Sat Nov 02, 2019 4:49 pm

I'm using CapsMan to upgrade all the nodes in the network. It's quite common that some of them fail to upgrade and the old firmware is left in its memory. If the memory is full this is not letting the nod to upgrade. The only workaround is to log in manually to it and remove the files.
Maybe it's worth adding to the os to flush old firmware from memory while upgrading from Capsman?

sindy · Sun Nov 03, 2019 12:11 am

Had an issue upgrading from 6.43.12 directly to 6.45.7 on a single RB1100AHx4 - the information in /ip ipsec peer wasn't properly split into the /ip ipsec peer and /ip ipsec identity parts, the latter was missing completely. In 6.43.12, auth-method pre-shared-key and pre-shared-key-xauth were used together with exchange-mode=ike2. Upgrade of another RB1100AHx4 from 6.43.16 didn't suffer from this issue, neither did an upgrade of CHRs from 6.43.7, 6.43.8 and 6.43.16.

Sunlight · Sun Nov 03, 2019 4:06 pm

Sunlight, flameproof Please send supout.rif file to support@mikrotik.com

The problem was resolved with /interface wireless reset-configuration wlan1,wlan2
Old config:

/interface wireless security-profiles
set [ find default=yes ] disable-pmkid=yes eap-methods="" \
    supplicant-identity=MikroTik
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" \
    management-protection=allowed mode=dynamic-keys name=Net \
    supplicant-identity="" wpa2-pre-shared-key=********
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" \
    management-protection=allowed mode=dynamic-keys name=Smart \
    supplicant-identity="" wpa2-pre-shared-key=********
/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac channel-width=\
    20/40/80/160mhz-Ceeeeeee disabled=no frequency-mode=superchannel \
    installation=indoor mac-address=76:4D:28:5A:9C:74 mode=ap-bridge name=\
    wlan1-net2-5G security-profile=Net ssid=Net_5G \
    wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
set [ find default-name=wlan2 ] band=2ghz-b/g/n disabled=no installation=\
    indoor mac-address=76:4D:28:5A:9C:76 mode=ap-bridge name=wlan2-net1-2G \
    security-profile=Net ssid=Net tx-power=30 tx-power-mode=\
    all-rates-fixed wireless-protocol=802.11 wmm-support=enabled wps-mode=\
    disabled
add keepalive-frames=disabled mac-address=76:4D:28:5A:9C:75 master-interface=\
    wlan1-net2-5G multicast-buffering=disabled name=wlan1-net1-5G \
    security-profile=Net ssid=Net wds-cost-range=0 wds-default-cost=0 \
    wmm-support=enabled wps-mode=disabled
add disabled=no keepalive-frames=disabled mac-address=86:25:19:1A:1E:82 \
    master-interface=wlan2-net1-2G multicast-buffering=disabled name=\
    wlan2-smart-2G security-profile=Smart ssid=Smart \
    wds-cost-range=0 wds-default-cost=0 wmm-support=enabled wps-mode=disabled

LeftyTs · Sun Nov 03, 2019 9:50 pm

No issues here so far in a few dozen MT devices. Seems like some really old problems with CRS switches with low speed interfaces or high speed ones loosing IP connectivity have been addressed and resolved. Good job. Keep it up that way.

Tue Nov 05, 2019 7:14 pm

Guys, please stop it. There is no Mikrotik without a Winbox. Web interface, though comparable in funcitonality, is still not there. Kill Winbox and I am done with MT.
don't want to turn the thread into a flame war. i agree, a lot of people need GUI, a lot of people love the look&feel of winbox, sure thing. not like i'd have the power or the will to take away your tools. in some parts winbox app is directly responsible for the popularity of RouterOS because it made the 'mystic networking stuff' accessible for the masses.
my point was merely to kill the "winbox protocol" and rather move the communication stack of the "well known and beloved" GUI tool over API or SSH. the convenient point-and-click thingie could remain there forever in unchanged visual format, given the large and loyal user base.

if it is documented - like SSH and API are - others can build similar GUI tools for different operating systems, and you would not need to rely on emulation/virtual machines just to have access to your device from a non windows environment. the protocol winbox uses is basically a black box, researchers are reverse engineering it with more or less success.

but i'm just stating my opinion, that's all.

may be you dont like Winbox that your opinion

Many of us love Winbox, go yourself and disable winbox on machines under your management, its your choice

don't talk For the rest of us, many of us like and need winbox and hope it to be constantly improved and maybe extended to be a cloud service , that's the trend of the industry, friendly graphical cloud interface available from anywhere and any kind of device

of course the idea behind this is the free to choose

tawhwat · Tue Nov 05, 2019 8:44 pm

On 6.43.11:
I have a script containing the following command:

:resolve $hostname server=$NS

I set "read, write, test" permission on this script, run without error

On 6.45.7:
When the same script run into the command

:resolve $hostname server=$NS"

it caused the "not enough permissions (9)" error.
When I remove the portion "server=$NS", it runs normally.
I tried to remove all permission setting, add all permission setting, and even added "Don't Require Permissions", all in vain.

Most probably a bug in new version.

sindy · Tue Nov 05, 2019 11:17 pm

On 6.45.7:
Most probably a bug in new version.

What architecture? I've just tested that on my arm (hAP ac²) and there is no issue:

[me@MyTik] > system script print where name~"test"
Flags: I - invalid
0 name="test" owner="me" policy=read,write,test dont-require-permissions=no last-started=nov/05/2019 18:10:19 run-count=3
source=local dnsServer 9.9.9.9 ; put [resolve nationalgeographic.com server=$dnsServer]
[me@MyTik] > system script run test
23.60.72.183

I even ran the script while logged as different user than the script owner, still doing fine.

tawhwat · Wed Nov 06, 2019 5:44 am

On 6.45.7:
Most probably a bug in new version.
What architecture? I've just tested that on my arm (hAP ac²) and there is no issue:

[me@MyTik] > system script print where name~"test"
Flags: I - invalid
0 name="test" owner="me" policy=read,write,test dont-require-permissions=no last-started=nov/05/2019 18:10:19 run-count=3
source=local dnsServer 9.9.9.9 ; put [resolve nationalgeographic.com server=$dnsServer]
[me@MyTik] > system script run test
23.60.72.183

I even ran the script while logged as different user than the script owner, still doing fine.

Thanks for your insight.
I further tested the symptom and find that this problem is not related to the version upgrade, this is a bug for Mikrotik to resolve CNAME record and it is also happened in lower version.

alexanderpilch · Wed Nov 06, 2019 11:34 am

Had an issue upgrading from 6.43.12 directly to 6.45.7 on a single RB1100AHx4 - the information in /ip ipsec peer wasn't properly split into the /ip ipsec peer and /ip ipsec identity parts, the latter was missing completely. In 6.43.12, auth-method pre-shared-key and pre-shared-key-xauth were used together with exchange-mode=ike2. Upgrade of another RB1100AHx4 from 6.43.16 didn't suffer from this issue, neither did an upgrade of CHRs from 6.43.7, 6.43.8 and 6.43.16.

We have a similar problem. IKEv2 with pre-shared-key and xauth is no longer supported after 6.43.16. Most likely, that's the reason you were left with an incomplete setup after upgrading.

As we have hundreds of devices with this setting, we cannot upgrade from 6.43.16 without destroying our ipsec setup.
Is there any news on bringing asynchronous authentication for IKEv2 back?
Unfortunately this serious change was not annouced in advance.

sindy · Wed Nov 06, 2019 1:13 pm

Most likely, that's the reason you were left with an incomplete setup after upgrading.
...
As we have hundreds of devices with this setting, we cannot upgrade from 6.43.16 without destroying our ipsec setup.

It's actually not as bad as it seems, but as it is not directly related to 6.45.7, please open a new topic in General like "how to migrate a ike2 pre-shared-key-xauth setup beyond 6.43 with the minimum level of stress", I'll respond there.

anav · Wed Nov 06, 2019 3:46 pm

No issues so far on RB450Gx4, my IKEv2 connection for my iphone kept working without issue (other than operator error).

bgp4 · Thu Nov 07, 2019 4:40 am

RouterOS version 6.45.7 has been released in public "stable" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.45.7 (2019-Oct-24 08:44):

MAJOR CHANGES IN v6.45.7:
----------------------
!) lora - added support for LoRaWAN low-power wide-area network technology for MIPSBE, MMIPS and ARM;
!) package - accept only packages with original filenames (CVE-2019-3976);
!) package - improved package signature verification (CVE-2019-3977);
!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);
----------------------

Changes in this release:

*) capsman - fixed frequency setting requiring multiple frequencies;
*) capsman - fixed newline character missing on some logging messages;
*) conntrack - properly start manually enabled connection tracking;
*) crs312 - fixed combo SFP port toggling (introduced in v6.44.5);
*) crs3xx - correctly display link rate when 10/100/1000BASE-T SFP modules are used in SFP+ interfaces;
*) crs3xx - fixed management access when using switch rule "new-vlan-priority" property;
*) export - fixed "bootp-support" parameter export;
*) ike2 - fixed phase 1 rekeying (introduced in v6.45);
*) led - fixed default LED configuration for RBLHG5nD;
*) lte - fixed modem not receiving IP configuration when roaming (introduced in v6.45);
*) radius - fixed open socket leak when invalid packet is received (introduced in v6.44);
*) sfp - fixed "sfp-rx-power" value for some transceivers;
*) snmp - improved reliability on SNMP service packet validation;
*) system - improved system stability for devices with AR9342 SoC;
*) winbox - show SFP tab for QSFP interfaces;
*) wireless - added "canada2" regulatory domain information;
*) wireless - improved stability when setting fixed primary and secondary channels on RB4011iGS+5HacQ2HnD-IN;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

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 some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

in 6.45.7，the “resolve” command can't work with AAAA records，it returns “not enough permissions (9)”，please fix it

brunoreale · Fri Nov 08, 2019 10:58 am

Hi, I did an RB upgrade to the 6.45.7 version and from that moment the DDNS Cloud, to reach the RB remotely, no longer works. The public address is not tracked.
Having a dynamic public ip, I need to solve the problem. How can I do?
Thanks

Belyache · Fri Nov 08, 2019 4:51 pm

I have been having intermittent lockups on most of my MikroTik routers since I upgraded to 6.45.7.

I am seeing 100% CPU usage on my RB493. It seems that the latest update didn't like me using large list of static DNS entries.
I removed them and so far the routers seem to be behaving. I was seeing multiple reboots when the scripts ran to update the lists as well.

I was using a regex list of "cryptojack" and ad sites. Below is a sample of what was being entered into Static DNS.

This list has around 7300 entries.
:local redirectIP "127.0.0.1"
/system logging disable 0
/ip dns static remove [find comment="sbl cryptojack"]
/ip dns static
/do {ip dns static add regexp="^(.*\\.)\?0-100-boom\\.foxypool\\.cf\$" address="$redirectIP" comment="sbl cryptojack"} on-error={}
/do {ip dns static add regexp="^(.*\\.)\?0-100-lhd\\.foxypool\\.cf\$" address="$redirectIP" comment="sbl cryptojack"} on-error={}
/do {ip dns static add regexp="^(.*\\.)\?02\\.hiveon\\.net\$" address="$redirectIP" comment="sbl cryptojack"} on-error={}
/do {ip dns static add regexp="^(.*\\.)\?02\\.node\\.hiveon\\.net\$" address="$redirectIP" comment="sbl cryptojack"} on-error={}

and an ad list of around 4300 entries.

:local redirectIP "127.0.0.1"
/system logging disable 0
/ip dns static remove [find comment="sbl ads"]
/ip dns static
/do {ip dns static add regexp="^(.*\\.)\?0icep80f\\.com\$" address="$redirectIP" comment="sbl ads"} on-error={}
/do {ip dns static add regexp="^(.*\\.)\?118-oew-181\\.mktoresp\\.com\$" address="$redirectIP" comment="sbl ads"} on-error={}
/do {ip dns static add regexp="^(.*\\.)\?123date\\.me\$" address="$redirectIP" comment="sbl ads"} on-error={}
/do {ip dns static add regexp="^(.*\\.)\?12place\\.com\$" address="$redirectIP" comment="sbl ads"} on-error={}
/do {ip dns static add regexp="^(.*\\.)\?180searchassistant\\.com\$" address="$redirectIP" comment="sbl ads"} on-error={}

These had been working fine for quite some time (years), until this last update.

I have the schedules disabled for now.

Any ideas?

Thanks

Glenn

BoltNetops · Fri Nov 08, 2019 6:06 pm

We have had Some Issues with multipath routing with routing marks we have decided to go back to 6.45.6 but turn off Winbox

here is an idea to help some people mitigate the dns issue

/ip dns set cache-size=64 cache-max-ttl=0

it would really be nice if we could just turn off cache or turn it to 0

alexjhart · Sat Nov 09, 2019 12:28 am

On 6.43.11:
I have a script containing the following command:
Code: Select all
:resolve $hostname server=$NS
I set "read, write, test" permission on this script, run without error

On 6.45.7:
When the same script run into the command
Code: Select all
:resolve $hostname server=$NS"
it caused the "not enough permissions (9)" error.
When I remove the portion "server=$NS", it runs normally.
I tried to remove all permission setting, add all permission setting, and even added "Don't Require Permissions", all in vain.

Most probably a bug in new version.

This is the same issue as this:

in 6.45.7，the “resolve” command can't work with AAAA records，it returns “not enough permissions (9)”，please fix it

Which I am also seeing:
CHR running v6.45.6:

:put [:resolve ipv6.google.com]
2607:f8b0:4004:810::200e

CHR running 6.45.7:

:put [:resolve ipv6.google.com]
not enough permissions (9)

This also happens on arm arch. where just before an upgrade it worked.

haasje · Sat Nov 09, 2019 12:34 am

I just updated my rb4011 to 6.45.7
When i open quick set the screen opens, but is empty. In the top left corner it says unknown and when click on the pulldown button the only option is Ethernet.
there used to be more options. Is this suppose to happen or did something gone wrong. I rebooted a few time, but no change.

FurfangosFrigyes · Sun Nov 10, 2019 8:08 pm

I have updated RB4011 and CRS328-24P-4S+RM and the SFP+ (DAC (S+AO0005)) Rx FCS and Rx Align errors on RB4011 side is solved. Thank you!

subway · Wed Nov 13, 2019 12:13 am

When will be fixed that Ipsec tunnels hung up? It starts from 6.45.4 and continues. Helps only clear connection.

Same thing here on CCR1072. Updated to 6.45.7 (both routerboard and ROS), and it happened after 20 hours. The IPsec tunnel was still up, but no traffic was passing. The solution was to hit "Kill Connections" on the Active Peers tab. The IPsec tunnel is Aes-128-cbc encrypted (IKE2 exchange mode), with ecp384 DH group. Previously happened on 6.45.3 as well.

sindy · Wed Nov 13, 2019 12:44 am

When will be fixed that Ipsec tunnels hung up? It starts from 6.45.4 and continues. Helps only clear connection.
Same thing here on CCR1072. Updated to 6.45.7 (both routerboard and ROS), and it happened after 20 hours. The IPsec tunnel was still up, but no traffic was passing. The solution was to hit "Kill Connections" on the Active Peers tab. The IPsec tunnel is Aes-128-cbc encrypted (IKE2 exchange mode), with ecp384 DH group. Previously happened on 6.45.3 as well.

Please spawn a dedicated topic and provide the complete IPsec configuration there (proposals, peer profiles, identities - everything may matter, just use hide-sensitive while exporting to keep your keys secret, and obfuscate the public IP addresses following the hint in my automatic signature below). If the other peer is not a Mikrotik, describe what it is and provide its configuration too if you have access to it. 20 hours is a weird time interval, as it doesn't match any of the default lifetimes - the phase 1 lifetime is typically 24h whereas the phase 2 lifetime is typically 30m. So if it is not some memory leak, it looks like an unsuccessful phase2 renegotiation, which is an issue which existed in IKEv2 in early 6.43 versions if I remember well. It was easy to spot if you had access to both ends - the ephemeral enc-key values of the installed-sa with the same spi value were different between the peers. If you lose access to the remote peer once this happens and can afford it, just give it 30 minutes and see whether it eventually recovers. Back then, it was happening randomly, not at all peers at the same time.

subway · Wed Nov 13, 2019 12:54 pm

Please spawn a dedicated topic and provide the complete IPsec configuration there (proposals, peer profiles, identities - everything may matter, just use hide-sensitive while exporting to keep your keys secret, and obfuscate the public IP addresses following the hint in my automatic signature below). If the other peer is not a Mikrotik, describe what it is and provide its configuration too if you have access to it. 20 hours is a weird time interval, as it doesn't match any of the default lifetimes - the phase 1 lifetime is typically 24h whereas the phase 2 lifetime is typically 30m. So if it is not some memory leak, it looks like an unsuccessful phase2 renegotiation, which is an issue which existed in IKEv2 in early 6.43 versions if I remember well. It was easy to spot if you had access to both ends - the ephemeral enc-key values of the installed-sa with the same spi value were different between the peers. If you lose access to the remote peer once this happens and can afford it, just give it 30 minutes and see whether it eventually recovers. Back then, it was happening randomly, not at all peers at the same time.

The tunnel was down for 1h 21minutes by the time I killed the connection, so it does not recover after 30 minutes. I am not opening a dedicated topic, as there were many reports in previous versions for similar issues with IPsec, this is nothing new. I can create a supout if it happens again, but to be fair, this is relatively infrequent. We are usually noticing this after a SW upgrade and/or outage, that IPsec tunnels are not recovering, or going down after a couple hours of operation.

sindy · Wed Nov 13, 2019 1:54 pm

We are usually noticing this after a SW upgrade and/or outage, that IPsec tunnels are not recovering, or going down after a couple hours of operation.

Are you saying that only the first negotiation of the tunnel after each upgrade fails, and once you resolve it the way you've described, it then runs well ever until the next upgrade?

As for the dedicated topic, I've seen too many people complaining "it happened again" here but not sending supout.rif to support, so sorry for that.

pe1chl · Wed Nov 13, 2019 3:05 pm

When you want to debug those "IPsec fails shortly after an upgrade" problems it would be useful to just reboot the router without upgrading and see if it does the same thing.
Because it is kind of a "usual problem" with IPsec. I have seen this all the time from when I started using it (like 15 years ago) and on many different makes of routers.
Apparently there is some potential for confusion when at some point while phase1 and phase2 are active one of the sides reboot and starts establishing new ones. Maybe it fails when the original phase2 at the surviving end times out, or similar.
This kind of problems sometimes appears to be solved, then comes back in later releases. That is not something specific for MikroTik, it is more specific for IPsec.

That being said, as of lately I have not seen many problems like that except for 1 case: when the session is through one or more NAT routers between the endpoints.
That can cause all kinds of problems where the IPsec won't work anymore when one end is rebooted, or when the NAT router is rebooted. The cleverer the NAT router the more likely there are problems. The worst are those that can do IPsec themselves, and that may be listening for incoming traffic on UDP port 500 while at the same time allowing clients to do IPsec-over-NAT.

kodiel11 · Wed Nov 13, 2019 8:56 pm

Can Someone help me ?
I have CCR1009-7G-1C-1S+ (tile).
Before i upgrading to 6.45.7, i can login it with winbox v3.20, and after i installing to the latest version (version before 6.42.12) i can't login anymore with winbox v3.
and then i try using winbox v2.18 and it works. can someone help me to solve this problem ?

kelner · Thu Nov 14, 2019 12:54 am

Hi, I did an RB upgrade to the 6.45.7 version and from that moment the DDNS Cloud, to reach the RB remotely, no longer works. The public address is not tracked.
Having a dynamic public ip, I need to solve the problem. How can I do?
Thanks

I have the same problem. I have some dozens of routers and more than half of them can not register in DDNS after upgrade to 6.45.7


[ak@RO-20] >/ip cloud export terse
# nov/14/2019 01:49:13 by RouterOS 6.45.7
# model = RouterBOARD 750G r3
/ip cloud set ddns-enabled=yes update-time=no

[ak@RO-20] >/ip cloud print
          ddns-enabled: yes
  ddns-update-interval: none
           update-time: no
                status: updating...

badziew · Thu Nov 14, 2019 9:31 pm

I also cannot login with winbox after this update. Android app works ok.

notToNew · Fri Nov 15, 2019 7:12 am

Since the Update from previous stable, my phones (moto Z3) cannot use 5Ghz. Im using Capsman with 7 CAP Devices (hap AC and hap ac2). 2.4 GHz works, but my phones cannot find the 5ghz ssid.

Anastasia · Sun Nov 17, 2019 5:42 pm

firewall not work.
the computer is connected to ether 2 (IP: 192.168.1.100), the laptop is connected to ether 3 ((IP: 192.168.1.251).

there is a rule in the firewall, it is the very first, there is nothing above it:

/ip firewall filter
add action=drop chain=forward dst-address=192.168.0.0/16 src-address=192.168.1.224/27

*) this rule does not work for traffic going from a laptop to a computer (ping 192.168.1.100 <= this and other traffic pass without blocking).
*) also i don't see traffic movement in "IP" => "Firewall" => "Connections" (no icmp traffic from 192.168.1.251)
Where is the problem?

P.S. All settings were made from the beginning and the factory settings were reset.

sindy · Sun Nov 17, 2019 6:23 pm

firewall not work.
the computer is connected to ether 2 (IP: 192.168.1.100), the laptop is connected to ether 3 ((IP: 192.168.1.251).

In default configuration ether2 and ether3 are both ports of the same bridge. So if the laptop and the computer both have a netmask of /24 (or shorter) in their IP configuration, they send packets to each other directly, not via the Mikrotik as an IP gateway, so the packets never get to the /ip firewall filter unless you'd force that by telling the bridge to force frames through the IP firewall and disabling hardware-accelerated forwarding.

Anastasia · Sun Nov 17, 2019 6:51 pm

disabling hardware-accelerated forwarding.

I turned off acceleration forwarding. And i am use Firewall (see pic).
Maybe I'm setting it up in the wrong place? where else to look at these settings and correctly configure?

sindy · Sun Nov 17, 2019 7:04 pm

I turned off acceleration forwarding. And i am use Firewall (see pic).

/interface bridge port set [find] hw=no
is the way to disable hardware-accelerated forwarding (accelerated by the switch chip, so the frames don't even get to the CPU so that it could push them through the ip firewall).

But first of all, you should prefer routing when policing the communication among devices on your LAN, and second, this is definitely nothing specific to 6.45.7.

Anastasia · Sun Nov 17, 2019 7:26 pm

I turned off acceleration forwarding. And i am use Firewall (see pic).
/interface bridge port set [find] hw=no
is the way to disable hardware-accelerated forwarding (accelerated by the switch chip, so the frames don't even get to the CPU so that it could push them through the ip firewall).

But first of all, you should prefer routing when policing the communication among devices on your LAN, and second, this is definitely nothing specific to 6.45.7.

Now everything worked. Thanks

Before that, I had an older version and everything worked there, although perhaps before that the laptop was connected via wi-fi and I did not notice it.

mkx · Sun Nov 17, 2019 8:21 pm

Never mind.

jober · Sun Nov 17, 2019 11:37 pm

Is the hotspot still broken on anything over 6.44.6?

danunjaya123 · Mon Nov 18, 2019 1:37 pm

I have got upgraded it but i got issue for IPv6.
Now i have degraded.

mthqwork · Wed Nov 20, 2019 1:35 pm

Moved my post to a separate thread as it's related to multiple versions.

amojak · Fri Nov 22, 2019 10:51 pm

6.45.7 fixes the DNS exploit.

It also seems to have created a port flapping problem on the CCR1036.

What is of interest is that ALL the connected ethernet /SFP ports show the flap simultaneously with the time stamp of when it went "up". but does nto show the down timestamp or add any counter of link downs.

it drops long enough for a winbox session to drop on the lan side and clear the neighbour list. So it definitely drops long enough to annoy a voip call!

The period seems random and when under high traffic. (well not for a ccr1036, it barely breaks a few % CPU load ever and traffic is not near the port limit.

example below >

ccrflap.jpg

and the next time it did it.

Is there a "safe" firmware other than 6.45.7 ?

ccrflap2.jpg

jober · Sun Nov 24, 2019 7:22 pm

To fix hotspot you have to down grade to latest long term.

osc86 · Mon Nov 25, 2019 12:47 am

Today morning my CCR1009 suddenly stopped responding to snmp requests.
Seems that all snmp related settings are gone. No changes were made recently.
An export of /snmp never finishes.

EDIT:
After a reboot it works again, with all my snmp settings restored. I created a supout file before the reboot, just in case this happens again.

Deantwo · Mon Nov 25, 2019 10:33 am

@amojak, Be sure to make a supout and send it to support if you haven't already.

@osc86

Today morning my CCR1009 suddenly stopped responding to snmp requests.
Seems that all snmp related settings are gone. No changes were made recently.
An export of /snmp never finishes.

See if rebooting the router doesn't fix the issue.
But if you are able you should probable make a supout and send it to support first.
I have seen similar issues to other components before, and they are usually fixed after a reboot. If the issue persist, definitely email support with a supout.

saktie · Mon Nov 25, 2019 2:20 pm

On 6.43.11:
I have a script containing the following command:
Code: Select all
:resolve $hostname server=$NS
I set "read, write, test" permission on this script, run without error

On 6.45.7:
When the same script run into the command
Code: Select all
:resolve $hostname server=$NS"
it caused the "not enough permissions (9)" error.
When I remove the portion "server=$NS", it runs normally.
I tried to remove all permission setting, add all permission setting, and even added "Don't Require Permissions", all in vain.

Most probably a bug in new version.
This is the same issue as this:

in 6.45.7，the “resolve” command can't work with AAAA records，it returns “not enough permissions (9)”，please fix it
Which I am also seeing:
CHR running v6.45.6:
Code: Select all
:put [:resolve ipv6.google.com]
2607:f8b0:4004:810::200e
CHR running 6.45.7:
Code: Select all
:put [:resolve ipv6.google.com]
not enough permissions (9)
This also happens on arm arch. where just before an upgrade it worked.

update??

ksteink · Mon Nov 25, 2019 3:13 pm

I do confirm that I have the same issue with IPv6 AAAA records after upgrading the routers that I do support:

[admin@MAK-CD01] > ping [:resolve ipv6.google.com]
not enough permissions (9)

On 6.43.11:
I have a script containing the following command:
Code: Select all
:resolve $hostname server=$NS
I set "read, write, test" permission on this script, run without error

On 6.45.7:
When the same script run into the command
Code: Select all
:resolve $hostname server=$NS"
it caused the "not enough permissions (9)" error.
When I remove the portion "server=$NS", it runs normally.
I tried to remove all permission setting, add all permission setting, and even added "Don't Require Permissions", all in vain.

Most probably a bug in new version.
This is the same issue as this:

in 6.45.7，the “resolve” command can't work with AAAA records，it returns “not enough permissions (9)”，please fix it
Which I am also seeing:
CHR running v6.45.6:
Code: Select all
:put [:resolve ipv6.google.com]
2607:f8b0:4004:810::200e
CHR running 6.45.7:
Code: Select all
:put [:resolve ipv6.google.com]
not enough permissions (9)
This also happens on arm arch. where just before an upgrade it worked.

nicolas94 · Mon Nov 25, 2019 8:39 pm

Hi

I have upgraded my CRS328 yesterday from 6.45.2 to 6.45.7 and now, the switch is extremely noisy. I have read the various changelogs and see that you have changed the way the fan are managed (adjust fan speed based on SFP and CPU temperature) in the 6.45.2. I know that this is not the right thread, but the old one is locked.

This is my current values with two S+RJ10 in sfpplus1 (71°C) & 4 (74°C) slots and only two 1G ports (on

are using POE
temperature: 65C
cpu-temperature: 32C
power-consumption: 11.5W
board-temperature1: 34C
psu1-voltage: 26.4V
psu2-voltage: 52.6V
psu1-current: 0A
psu2-current: 0.2A
fan1-speed: 7770RPM
fan2-speed: 7770RPM

Is it possible to know what has changed between the two firmware and what are the new thresholds ? It there any plan in the next firmware to lower a little the fan ?

Thank you

evince · Wed Nov 27, 2019 11:31 am

Is the hotspot still broken on anything over 6.44.6?

Yes hotspot is still broken, need to install long term version.

faxxe · Thu Nov 28, 2019 6:40 am

RB1100AH4x 6.45.7

nothing special in my configuration. just few firewall rules.

"Router was rebooted after proper shutdown"
Happens now 2 times after 7 and 21 days of running

Really long uptimes i only got with the 6.44.xx

-faxxe

osc86 · Fri Nov 29, 2019 2:15 am

Don't know if this is directly related to 6.45.7 or just another bug in The DUDE.
Never seen this before. Agent and the device to monitor do run the same Version of RouterOS.
Agent is hEX (mmips), the other device is hAP ac^2 (arm).
I only get this error for one device.

Kraken2k · Fri Nov 29, 2019 11:36 am

RB1100AH4x 6.45.7

nothing special in my configuration. just few firewall rules.

"Router was rebooted after proper shutdown"
Happens now 2 times after 7 and 21 days of running

Really long uptimes i only got with the 6.44.xx

-faxxe

Same device, similar time, same problem - my RB1100AH4x with 6.45.7 was unexectedly rebooted after 21 days of running without any problems.

Jeroen3 · Fri Nov 29, 2019 6:56 pm

Is there any known reason why (what looks like) all NAT stops working in 6.45.7 after a few hours?

Where do I even start yo debug this?

mkx · Fri Nov 29, 2019 8:20 pm

My RBD52G is running 6.45.7 with uptime of 3w1d23h31m13s ... and NAT still works. Both a generic src-nat as well as quite a few dst-nat rules are in the mix.

nostromog · Fri Nov 29, 2019 10:59 pm

Is there any known reason why (what looks like) all NAT stops working in 6.45.7 after a few hours?

Where do I even start yo debug this?

I think it could be due to change in the external IP, or even release of the current one due to problems in the DHCP renegotiation, you could look for dhcp messages in logs. I'm assuming that you get an IP through some sort of dhcp. I used to have a connection when in Germany where the provider would change the ip every day or so between 7-9am, which broke all my connections.

Jeroen3 · Sun Dec 01, 2019 1:47 pm

External IP is indeed dhcp, but it is always the same. IPv6 still worked somehow.
I have downgraded to 6.45.6 friday evening, problems have gone. Downgrading works remarkably well, good job.

emils · Tue Dec 03, 2019 12:01 pm

New version 6.46 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=154444

Who is online