MikroTik

Posted: **Fri Jun 26, 2020 12:29 pm**

CRS326-24G-2S+ after upgrade to 6.47 only available 10% of HDD space !

Capture.PNG

Capture1.PNG

Posted: **Fri Jun 26, 2020 12:44 pm**

CRS326-24G-2S+ after upgrade to 6.47 only available 10% of HDD space !

And before upgrade?
These numbers are not so bad for a 16MB device with additional package(s) installed, right?

Posted: **Fri Jun 26, 2020 4:42 pm**

We need more people to contribute to this Cloudflare thread I created about DoH issues:
https://community.cloudflare.com/t/clou ... e/184158/6

Posted: **Fri Jun 26, 2020 4:43 pm**

*) port - removed serial console port on hEX S;

- How can I re-enable the "serial console" manually on hEX S, if it has been disabled in 6.47 please?
- Why has it been disabled in 6.47 on the hEX S?

+1... there is NO GOOD REASON to do this.
Same for all other boards with UART pins on board, this port should be available and console spawn on it by default.

Posted: **Fri Jun 26, 2020 4:55 pm**

Antenna gain should not be changed, especially for devices with built-in antennas. What were you trying to achieve anyway?
If your signal is too weak, fix position or alignment. Playing with antenna gain is not the right way and can be illegal.

Hi, tested on hAP ac lite RB952Ui-5ac2nD.
What are we trying to achieve - make basic wireless configuration.
1. Frequency Mode -> regulatory-domain. (If apply is pressed after this step, it is accepted.)
2. Country -> select country (in my case Bulgaria).

2020-06-26_16-44-55_winbox64.png

3. Press Apply -> error returned: "minimal antenna-gain for this country is 2 (6)".

2020-06-26_16-45-01_winbox64.png

(Workaround)
It is worth to note that the CLI shows and allows the setting of the antenna-gain parameter (value-name).
/interface wireless> print advanced
Example:
2 name="wlan5" mtu=1500 l2mtu=1600 mac-address=C4:AD:34:xx:xx:xx arp=enabled disable-running-check=no interface-type=Atheros AR9888
radio-name="C4AD3XXXXXX" mode=ap-bridge ssid="5GHz" area="" frequency-mode=regulatory-domain country=no_country_set
installation=any antenna-gain=0 frequency=5180 band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX secondary-channel=""
scan-list=default wireless-protocol=802.11 rate-set=default …….

The default value is 0: antenna-gain=0.

After changing the value through CLI to 2, the above settings are accepted.
The default value for antenna-gain is 0 for both 2.4 and 5 GHz.

Apart from the issues with working with Tx power, I would suggest that If the country is supposed to be set through WinBox (GUI), then an internal software check should be made and the corresponding antenna-gain value for the respective country be set automatically, so the country change is accepted. If the value is the same for all

, then it should be easier.

Posted: **Fri Jun 26, 2020 5:02 pm**

We need more people to contribute to this Cloudflare thread I created about DoH issues:
https://community.cloudflare.com/t/clou ... e/184158/6

It is probably only your ISP or setup issue, we are using DoH Cloudflare without problems.
Please check your setup, this should work normally, as mentioned before several times:

/tool fetch url=https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem
/certificate import file-name=DigiCertGlobalRootCA.crt.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes servers=""

Posted: **Fri Jun 26, 2020 5:12 pm**

We need more people to contribute to this Cloudflare thread I created about DoH issues:
https://community.cloudflare.com/t/clou ... e/184158/6
It is probably only your ISP or setup issue, we are using DoH Cloudflare without problems.
Please check your setup, this should work normally, as mentioned before several times:
Code: Select all
/tool fetch url=https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem
/certificate import file-name=DigiCertGlobalRootCA.crt.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes servers=""

Yes, I followed those exact same instructions and still have issues with DoH on MikroTik. I don't think it's ISP since reachability isn't a problem as stated in that Cloudflare thread.

Maybe it's my IPv6 config? Please take a look: viewtopic.php?f=13&t=162930

Posted: **Sat Jun 27, 2020 4:25 am**

Definitely not an ISP issue. 1.1.1.1 works great but when I go to use it for DOH my 2011 throws errors out at me usually the (6) and the (13)'s. Once in a while the 4011 will error but not as bad as the 2011 will. And a reboot will usually take care of it for a while then it comes back eventually

This one of those, it either works or it doesnt. If it doesnt, you know right away when you look at your logs. But mine will run for days and then start throwing stuff out at me. Once I turn off the DOH, all is well.

Now I have only tested with Cloudflare, I cant attest to how the other DNS providers fair.

Posted: **Sat Jun 27, 2020 10:15 pm**

Hi,
I'm facing with such errors
DNS warning DoH max concurrent queries reached, ignoring query
and
DNS error DoH server connection error: Network is unreachable

mikro.png

Mikrotik ac2, ROS 6.47
Once per day or two, router drops down L2TP connection because it can't resolve L2TP server's name.

Any ideas how to resolve my issue besides turning DOH off?

Posted: **Sun Jun 28, 2020 2:39 pm**

Upgraded my my home root switch CRS326-24G-2S+ from 6.46.6 to 6.47. This router has 2 x 10 GbE S+RJ10 connected to 2 x CSS326-24G-2S+RM (SwOS 2.11) also with 10 GbE S+RJ10 GBICs. Everything has been stable so far. After upgrading to 6.47 stable all hell broke loose. The link to 1 of the CSS326-24G-2S+RM suddenly starts to go down permantly. Only way to recover was to pull out the ethernet cable or reboot the switch. This event was happening several times a day, and made my home network unusable. Had do degrade the firmware to 6.45.9 (long-term) and everything was stable again. The last stable version was 6.46.6.

I think the problem is that the this CRS326-24G-2S+ switch could not recover after a short link down. I have to admit that the distance between these two switches are on the fringe how far you can have a 10 Gb connection, but this hasn't been an issue before because the these switches recovered quite well. The other connection was stable with 6.47 but that link was only on 5 Gb because the distance is to far for a 10 Gb connection.

Is this a known issue with firmware 6.47 with Mikrotik S+RJ10 GBIC is unstable and can't recover well? If this issue isn't addressed I have to live forever with 6.46.6 or 6.45.9 (long-term).

Also upgraded my RB3011 internet router to 6.47 stable, but hasn't had any issues with that router, but this router of course has no S+RJ10 GBIC.

Posted: **Sun Jun 28, 2020 3:13 pm**

For those having issues flushing the dns cache, from my experience, this is due to a winbox bug IMO.

If I have a large cache (a few mb) then through winbox the cache will never clear.

If I run a /ip dns cache flush, it works. I also tested with disabling remote requests, flush cache, and enabling remote requests via a script.

It's worth a try for those having this issue.

EDIT:

It seems it only worked yesterday. Perhaps there are connections to the dns server stopping it from purging the cache consistently.

Posted: **Mon Jun 29, 2020 9:58 am**

Also SMB is not available from Windows PC (7 and 10)

Installing SMB 1.0 also does not help.

By some reason Kyocera MFP can successfully scan documents to SMB share located on Mikrotik.

Checked on hEX S and RB1100AHx4 DE

Posted: **Mon Jun 29, 2020 10:19 pm**

hi this first post i made, i am trying using this new feature DoH DNS using Adguard DNS, seem everything work fine, but it seem using full DNS cache, i even tried to increasing the cache to 10000 KiB, it full in no time, i tried too flush the cache but it seem cache used still not decreasing, does this normal behavior for DoH DNS?reso.JPGdns static.JPGcache.JPGsert.JPG

Same or similar issue with hAP AC^2 - using Google's DoH (not sure if it's DoH related, just to mention for completeness).

Reported "cache used" was a bit high, e.g. 1200 - 1500 K for 500-600 entries, and kept growing over time.

Once it reached 2048K (the default limit) - the router started flushing the cache, but this did not reset "cache used". Because of this, the router started flushing the cache every few seconds few seconds, again and again.

Flushing the cache manually (in web ui or Android app) is the same - "cache used" does not reset.

This effectively disabled DNS caching.

PS - ticket SUP-20427 - with supout.rif attached.

Posted: **Mon Jun 29, 2020 10:22 pm**

For those having issues flushing the dns cache, from my experience, this is due to a winbox bug IMO.

[ ... ]

If I run a /ip dns cache flush, it works.

Not for me (hAP AC^2, 6.47). Same as flushing the cache in web UI or Android app - the cache does get cleared, but the "Cache Used" value is not reset.

Consequently, the router keeps flushing the cache over and over again, making the cache useless.

Posted: **Tue Jun 30, 2020 1:29 pm**

GRE is still handled incorrectly in connection tracking. No GRE "connection" ever appears in the firewall->connections tab.
An explicit match with protcol GRE is required before any drop rule for state "invalid".

Posted: **Tue Jun 30, 2020 5:25 pm**

LOST ALL BRIDGES AND PORTS

on update from 6.46.6 to 6.47. It's a CCR1009-7G-1C-1S+ (Tile 9 Core).

Luckily I have another Internet uplink in that network, so I can reconfigure remotely. Will revert to 6.46.6 to check if settings are still there.

Edit: In addition to bridges and bridge ports, Capsman settings (including manager) was gone as well. However:

Reverting and then doing another reboot brings everything back.

So, if you want to upgrade, do a full config export before and only do it if you have time for reconfig and another remote access.

Posted: **Wed Jul 01, 2020 12:13 pm**

Why is the router connecting every hour to upgrade.mikrotik.com and fetching the LATEST.6 file?

No reply to this one, anyone else experiencing this? Why would the router (with all settings disabled in /ip cloud) regularly connect to the upgrade server?
Is there an auto-update mechanism? Or some desire to keep a statistic of versions in use over the world?

Try this:

/ip firewall address-list
add address=upgrade.mikrotik.com list=upgrade

/ip firewall filter
add action=accept chain=output comment="Upgrade server" dst-address-list=\
    upgrade dst-port=80 log=yes log-prefix=upgrade protocol=tcp

To see if you are affected as well...
(it will log attempts by the router to connect the upgrade server. you can add it to the forward chain as well when you have internal MikroTik devices)

Posted: **Wed Jul 01, 2020 5:13 pm**

So, if you want to upgrade, do a full config export before and only do it if you have time for reconfig and another remote access.

Did the update to 6.47 on the same router 28 days ago and had no problem.
My CCR1009-7G-1C-1S+ is still up without any fault (current uptime 28d 23:34:00)

-faxxe

Posted: **Wed Jul 01, 2020 6:01 pm**

I did not have any issue updating two very differently configured CCR1009 either! It must be something particular to his config. I use many bridges as well.
Remember on the CCR1009 you can always use partitions to be able to go back to previous config. Many users do not know about it, it seems.

Posted: **Wed Jul 01, 2020 10:05 pm**

The port numbers returned in SNMP OID .1.3.6.1.2.1.17.4.3.1.2 are not correct anymore.
When doing an snmpwalk of that OID you should get a number of values for each MAC address in the bridge/switch table and each value should be an INTEGER with the interface number.
This used to work OK, but now the number returned is garbage.

Posted: **Wed Jul 01, 2020 10:34 pm**

@erchegov and company, I was curious about your L2TP/IPsec issue here, so I've configured a network of four CHRs the following way:

CHR-47 is a L2TP/IPsec server running ROS 6.47, with several WAN IPs in the same subnet
CHR-3 is a "client router" whose WAN is connected to CHR-47's WAN and does a src-nat for out-interface-list=WAN
CHR-1 and CHR-2 run and L2TP/IPsec client interface each, connecting each to another WAN IP of the CHR-47's, connected as LAN hosts of the CHR-3

I believe this is a copy of your configuration - two clients connecting from behind the same "public" IP to the same server, but each to another public IP of the server.

CHR-1, CHR-2, CHR-3 all run 6.45.9.

The result is no fault found. Both clients connect, get their IP addresses, and are pingable through the tunnels. Both the IPsec security associations carrying the L2TP sessions have the same dst-address (the WAN IP of CHR-3), but they are distinguishable from one another by the server side IP addresses. Can someone of the affected gentlemen spawn a dedicated topic for this issue, post the export of their working server-side configuration there, and post a link to that new topic here in order to offload the current topic from this rather specialized discussion?

Posted: **Thu Jul 02, 2020 10:46 am**

@sindy they are having issues with plain L2TP without IPsec encryption. I can confirm there is an issue but I am still struggling to reproduce the issue in a controlled environment even with all the debug information and configurations provided to me.

Posted: **Sat Jul 04, 2020 5:20 pm**

/tool profile cpu=all
show 100% cpu usage on all cores in x86 vm on proxmox 5.4-3
Upgrade was done at 16:00.

Posted: **Sun Jul 05, 2020 8:36 pm**

@sindy they are having issues with plain L2TP without IPsec encryption. I can confirm there is an issue but I am still struggling to reproduce the issue in a controlled environment even with all the debug information and configurations provided to me.

How about creating four builds -- each with one of the four L2TP changes in the changelog reverted. Then, those of us having the issues can test and confirm which change introduced the issue. That could then help you focus your investigation.

The only other suspicious change is "*) interface - improved system stability when receiving bogus packets." Without more insight into what exactly that change is referring to, I have no Idea if it could be related.

Posted: **Sun Jul 05, 2020 9:36 pm**

i had some wireless problems with this version, my battery powered wireless devices (phones, tablets, ipad) started to drain battery fast, i had to rollback to 6.46.6 to fix that. my setup is a hap ac2 as capsman manager/cap and a cap ac as a cap, here's more info

viewtopic.php?f=7&t=163262

anyone with the same problem?

Posted: **Mon Jul 06, 2020 9:01 am**

another bug ... when going under IP/IPSec/Policy, and opening an existing one seems to exit winbox/crash winbox.

Or adding new one. You simply cannot edit/create ipsec policies using winbox on 6.47. Winbox just crashes without any error message.

Update: Mea culpa. I thought I had the latest Winbox (3.24) but I made a mistake replacing the target file of my shortcut. It works OK with Winbox 3.24.

Posted: **Mon Jul 06, 2020 9:19 am**

My hope.
6.46 - > long term
6.47 - > stable
6.48.. no, no more 6 series
7.01 - > testing

+1, although it looks like there will be a 6.48beta b/c they need to have one in order to introduce point releases for 6.47. It is probably not a big deal for them to do this because most of the fixes can be rolled up into v7, which is fine, and so it benefits both versions. I would just rather not have to wait another few years to see the topic "v7.00 [stable] is released!"

Posted: **Mon Jul 06, 2020 10:45 am**

i had some wireless problems with this version, my battery powered wireless devices (phones, tablets, ipad) started to drain battery fast, i had to rollback to 6.46.6 to fix that. my setup is a hap ac2 as capsman manager/cap and a cap ac as a cap, here's more info

viewtopic.php?f=7&t=163262

anyone with the same problem?

Me too. Although I'm not sure if every device here has this problem

Posted: **Mon Jul 06, 2020 11:07 am**

another bug ... when going under IP/IPSec/Policy, and opening an existing one seems to exit winbox/crash winbox.
Or adding new one. You simply cannot edit/create ipsec policies using winbox on 6.47. Winbox just crashes without any error message.

thaaats interesting. I just recreated from scratch our site-to-site VPNs on 2 routers running 6.47 and there was no crash.
Are you using latest winbox? there must be something particular triggering the bug.

To be specific - I opened old policies (migrated from 6.45), then deleted them (including all peers and peer identities) and created new ones (several times, because I have really bad knowledge of ipsec). I also tried to open and copy dynamic policies, peers and peer identities created by EoIP . All worked fine.

Posted: **Mon Jul 06, 2020 11:41 am**

another bug ... when going under IP/IPSec/Policy, and opening an existing one seems to exit winbox/crash winbox.
Or adding new one. You simply cannot edit/create ipsec policies using winbox on 6.47. Winbox just crashes without any error message.

Update your WinBox to the latest version (3.24).

Posted: **Mon Jul 06, 2020 12:00 pm**

Update your WinBox to the latest version (3.24).

Cannot do that until the "mouse down in window which has active updates (like counters)" bug is fixed.
It was introduced in 3.22 so I am still running 3.21. The bug is described and confirmed in all the Winbox release topics since 3.22 but nothing is being done about it.

Posted: **Mon Jul 06, 2020 12:31 pm**

I did not have any issue updating two very differently configured CCR1009 either! It must be something particular to his config. I use many bridges as well.

Sure not everyone seems to have this problem, otherwise we'd all be screaming right? Just saying take precautions, because for some installations, this isn't just "some update". It might actually blow up in your face. I think that's valuable info on anything resembling a stable branch.

My config isn't even that strange I would say. That said, the problem will probably depend on something in the config, otherwise everyone would get it. I'm thinking it's some sort of legacy thing in there not being "translated" right between updates. The router is now several years old and has seen a considerable number of config changes on many different versions. I also sometimes changed between stable and long-term, which might have something to do with it as well.

Posted: **Mon Jul 06, 2020 12:55 pm**

I did not have any issue updating two very differently configured CCR1009 either! It must be something particular to his config. I use many bridges as well.
Sure not everyone seems to have this problem, otherwise we'd all be screaming right? Just saying take precautions, because for some installations, this isn't just "some update". It might actually blow up in your face. I think that's valuable info on anything resembling a stable branch.

That is just standard practice for any update, be it to a stable version or not, of an important device (especially when it is difficult to access).
I always use partitioning and copy the current version just before upgrade so I can immediately go back when disaster occurs.
And yes, it has happened that it booted the new version, paniced, and auto-switched to the alternate partition.
Still, it does not seem that many users use (or even know about) that precaution...

Posted: **Mon Jul 06, 2020 1:15 pm**

Still, it does not seem that many users use (or even know about) that precaution...

because 95% of us are stuck with 16MB of space...

Posted: **Mon Jul 06, 2020 1:58 pm**

Update your WinBox to the latest version (3.24).
Cannot do that until the "mouse down in window which has active updates (like counters)" bug is fixed.
It was introduced in 3.22 so I am still running 3.21. The bug is described and confirmed in all the Winbox release topics since 3.22 but nothing is being done about it.

Unable to reproduce. Tried on Linux, MacOS and Windows. Must be something specific on your end. What wine version are you running?

Posted: **Mon Jul 06, 2020 9:02 pm**

Update your WinBox to the latest version (3.24).
Cannot do that until the "mouse down in window which has active updates (like counters)" bug is fixed.
It was introduced in 3.22 so I am still running 3.21. The bug is described and confirmed in all the Winbox release topics since 3.22 but nothing is being done about it.
Unable to reproduce. Tried on Linux, MacOS and Windows. Must be something specific on your end. What wine version are you running?

Wine version: wine-4.0 (Debian 4.0-2) (running on Debian 10, updated to latest version)
Same issue on another system running Debian 9 and Wine version wine-1.8.7 (Debian 1.8.7-2)
Cha0s confirmed he has the same issue in Windows 10: viewtopic.php?f=21&t=161320#p802314 and on Windows 7 (2 articles above that one).

To reproduce: open a window which has continuous updates, e.g. the IP->Firewall->Filters window on a router which is passing traffic (counters are updating)
Then hold down mouse to either change a column width or to move a rule. At the next update, the mouse pointer will jump and the column gets a wrong width or the rule is moved to an unwanted position.

Posted: **Mon Jul 06, 2020 11:44 pm**

To reproduce: open a window which has continuous updates, e.g. the IP->Firewall->Filters window on a router which is passing traffic (counters are updating)
Then hold down mouse to either change a column width or to move a rule. At the next update, the mouse pointer will jump and the column gets a wrong width or the rule is moved to an unwanted position.

Well, at least can't repeat it on MacOS with Wine-5.7...

Posted: **Tue Jul 07, 2020 6:58 am**

After activating the DNS over https, a memory leak occurs. Here are the graph data from the monitoring system. Router Model RBD52G-5HacD2HnD

Posted: **Tue Jul 07, 2020 8:08 am**

@itforeverru

It looks like you are inn to some. Here is memory usage on MT 6.47 (running on a vmware)
This router only do DoH and used for testing only.
A reboot was done 5 July

Memory leak.jpg

My RB750Gv3 that is much more loaded, does not show this behaviour. 6.45.9

Memory leak2.jpg

Posted: **Tue Jul 07, 2020 12:20 pm**

Wine version: wine-4.0 (Debian 4.0-2) (running on Debian 10, updated to latest version)
Same issue on another system running Debian 9 and Wine version wine-1.8.7 (Debian 1.8.7-2)
Cha0s confirmed he has the same issue in Windows 10: viewtopic.php?f=21&t=161320#p802314 and on Windows 7 (2 articles above that one).

To reproduce: open a window which has continuous updates, e.g. the IP->Firewall->Filters window on a router which is passing traffic (counters are updating)
Then hold down mouse to either change a column width or to move a rule. At the next update, the mouse pointer will jump and the column gets a wrong width or the rule is moved to an unwanted position.

Try:
* clearing cache
* connecting to a router with clean session ("<none>")
* connecting to a different device
* upgrading Wine
If all fails, please make a screen capture of the issue.

Posted: **Tue Jul 07, 2020 12:53 pm**

I added more info to the Winbox 3.24 topic about this issue. [again at 14:35 after more testing]
It appears it requires a complex/busy router to reproduce.

Posted: **Wed Jul 08, 2020 3:59 pm**

RouterOS version 6.47 has been released in public "stable" channel!
...
*) wireless - fixed Nstreme wireless protocol performance decrease;
...

Does anybody knows when this decrease was introduced?
We have two links with 6.45.9, 802.11ac, dual chain, -48, 20/40/80, CCQ around 100% and we cannot get more than 140mbits with nstream (when the radios are connected on 650 mbits).

Posted: **Wed Jul 08, 2020 4:19 pm**

RouterOS version 6.47 has been released in public "stable" channel!
...
*) wireless - fixed Nstreme wireless protocol performance decrease;
...
Does anybody knows when this decrease was introduced?
We have two links with 6.45.9, 802.11ac, dual chain, -48, 20/40/80, CCQ around 100% and we cannot get more than 140mbits with nstream (when the radios are connected on 650 mbits).

Issue was introduced in all 6.46.x versions, everything was fine in all 6.45.x versions. So in switch from 6.45 to 6.46 ...

Posted: **Wed Jul 08, 2020 8:43 pm**

Does anyone has problem with CRL with this release?

It seems that my router does not get the latest crl as the last date of update is older and now the crl appears as invalid in the crl tab.

The only error I got is the DoH server connection error. SSL handshake failed: unable to get certificate CRL.
If I uncheck Verify DoH Certificate in the DNS setting tab, it works.

I am using cloudflare DOH and I have uploaded the cloudflare certificate. All the regular DOH DNS queries work normally even with the verify DOH certificate option. Only CRL download does not.

Posted: **Thu Jul 09, 2020 2:41 am**

Had the same issue. Stopped using DOH and cloudflare until they sort it out. Guess you could use it without certs and not validate the certs you have and it would be fine. It appears that the certs expire before it can renew them and once they expire you are basically locked out of cloudflare unless you turn off using the cert validation or just use the normal 1.1.1.1 to get DNS to allow you to download the new CRL files and then you can turn things back on again.

Posted: **Thu Jul 09, 2020 5:09 pm**

...
I am using cloudflare DOH and I have uploaded the cloudflare certificate. All the regular DOH DNS queries work normally even with the verify DOH certificate option. Only CRL download does not.

Not having any issues with DoH cert validation (AC^2, 6.47).

I uploaded certs for both Google DNS and 1.1.1.1 - but not the leaf certs, rather the intermediate and root certs.

For Google, the intermediate is "GTS CA 1O1" expires "Dec/15/2021" and its root cert is "GlobalSign Root CA - R2" expires "Dec/15/2021".

For Cloudflare, it's " DigiCert ECC Secure Server CA" expires "Mar/08/2023" and "DigiCert Global Root CA" expires "Nov/10/2031".

Both chains can be obtained using a web browser and doing "export certificate chain" from viewing the site's properties and then certificate (at least that's the UI in Chrome).

The intermediate certs are probably not needed since they're sent by both (Google and CloudFlare) servers, only the root certs should be necessary, but I've already got both imported...

Posted: **Thu Jul 09, 2020 11:31 pm**

I can confirm that cloudflare https://1.1.1.1/dns-query works perfectly only with root cert "DigiCert Global Root CA".

Posted: **Fri Jul 10, 2020 12:53 am**

Pea, I can also confirm that it 'did' work using the proper URL and CRL's. But over time I would start getting errors and it was because the router could not download the updated CRL info cause the old ones were perhaps not valid, so basically I was locked out from getting the downloads since the router could not query cloudflare with the certs I had downloaded previously. I had to disable DOH and let the router just use 1.1.1.1 as normal DNS and then it downloaded the CRL info and once I turned DOH back on, it was fine again...until the next event where it happened again.

Posted: **Fri Jul 10, 2020 9:13 am**

New version 6.47.1 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=163482

MikroTik

v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: Antenna Gain issue

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!

Re: v6.47 [stable] is released!