v6.47.9 [long-term] is released!

deadmaus911 · February 13, 2021, 6:15pm

Maybe, in my cases usage of CRL is disabled. I use a Cloudflare DoH servers

Chiverel · February 15, 2021, 8:26am

I see issues with DoH 1.1.1.1 and certificate validation (clickable image in high res), rb4011

Mikhalich · February 15, 2021, 10:28am

hEX PoE with 48V Power Supply still have bug with attached cameras powered by poe. It’s powered on only then PoE out is “Forced On”.

mkx · February 15, 2021, 10:39am

If cable connecting hEX PoE and camera is long, then detecton/negotiation can fail due to excessive cable resistence. In such case forcing PoE out can help but it also depends on voltage drop over cable, 802.3 af/at requires at least 37V at PD (camera).

Mikhalich · February 15, 2021, 10:50am

Unfortunetly not long. About 10 meters.
Netmetal ac can not be turned on from this hEX at 3-4 meters of cable.
System - Health of hEX PoE shows 47.9 Volts.

Znevna · February 15, 2021, 11:41am

The PoE issue was introduced in 6.46.8, as the comments from that release prove it.
Going back to 6.46.7 fixes it. Someone complained in IRC too about that.
One of the reasons I was hoping for a 6.46.9 bugfix release.

Mikhalich · February 15, 2021, 1:56pm

Just tried to install 6.46.7. Same problem… PoE out status - waiting for load.
Maybe it is hardware bug. Mikrotik does not admit this and did not say a word about this problem.

pcunite · February 15, 2021, 2:42pm

Using a hEX PoE to power two Dahua SD1A203T-GN. PoE set to auto on. Firmware v6.47.9 without issue. I think these units are 2 or 3 years old. Factory firmware was 6.42.7.

Mikhalich · February 15, 2021, 3:23pm

I also have only one of many hEX PoE routers which works without problems with the same cameras (Hikvision) in “auto on” PoE mode with ROS 6.47.8. It doesn’t depend on cameras or power supply. I tryed to change it. This gives reason to think this is hardware bug.

xylograde · February 16, 2021, 8:03pm

Interesting… I have big issues with IKEv2 behind NAT on both sides with actual 6.48.1, but still no news from MT. Was you able to run IKEv2 OK with this latest long term? Do you have your responder (server) behind nat on LTE connection? (see my other post http://forum.mikrotik.com/t/ipsec-ikev2-server-for-road-warriors-site-to-site-behind-double-nat-rb4011-and-os6-48-1/146761/21)

wiyat · February 17, 2021, 12:06pm

Hola/Hello from Spain
Bugs 6.47.9 Just-work on 6.46.8
Error: Scripting not global or local variable work
Mikrotik Ticket: SUP-42106

My script: Update DNS and find dns-name where I add ip route rule add

:foreach i in=[/ip dns cache all find where (name~“dns-name”) && (type=“A”) && (data!=“240.0.0.1”)] do={
:local tmpAddress [/ip dns cache get $i address];
delay delay-time=3000ms

:if ( [/ip firewall address-list find where address=$tmpAddress] = “”) do={
:local cacheName [/ip dns cache get $i name] ;
:log info (“added entry: $cacheName $tmpAddress”);

/ip firewall address-list remove [/ip firewall address-list find list=“list_name”];
/ip route rule remove [find table=INTERNET];
/ip route rule add dst-address=1.1.1.1 action=lookup table=INTERNET;
/ip route rule add dst-address=$tmpAddress action=lookup table=INTERNET;
/ip firewall address-list add address=$tmpAddress list=list_name; } }

Best regard,

wiyat

eworm · February 17, 2021, 12:22pm

For me scripting works just fine. Can you be more precise what you think does not (or no longer) work?

wiyat · February 17, 2021, 12:41pm

Hi eworm

can you test my script into your equipment Mikrotik 6.47.9 but remember to replace:
replace dns-name for mikrotik.com
replace list_name for mikrotik1

What do you will be expect after execute my script:
A. /ip route rule print -----> you will be see add two new rule with table=INTERNET
B. /ip firewall address-list -----> you will be see one list=list_name

:foreach i in=[/ip dns cache all find where (name~“dns-name”) && (type=“A”) && (data!=“240.0.0.1”)] do={
:local tmpAddress [/ip dns cache get $i address];
delay delay-time=3000ms

:if ( [/ip firewall address-list find where address=$tmpAddress] = “”) do={
:local cacheName [/ip dns cache get $i name] ;
:log info (“added entry: $cacheName $tmpAddress”);

/ip firewall address-list remove [/ip firewall address-list find list=“list_name”];
/ip route rule remove [find table=INTERNET];
/ip route rule add dst-address=1.1.1.1 action=lookup table=INTERNET;
/ip route rule add dst-address=$tmpAddress action=lookup table=INTERNET;
/ip firewall address-list add address=$tmpAddress list=list_name; } }

When do you finish please let me know if it work for you,

Gracias / Thank you

eworm · February 17, 2021, 1:07pm

The problem is that /ip dns cache does no longer have an attribute “address”, it was renamed to “data”.
So replace that in the line where tmpAddress is assigned.

wiyat · February 17, 2021, 1:36pm

Hi [hola] eworm

Work ok. just replace address by data

:foreach i in=[/ip dns cache all find where (name~“dns-name”) && (type=“A”) && (data!=“240.0.0.1”)] do={
:local tmpAddress [/ip dns cache get $i address];
delay delay-time=3000ms

Question:

How do you know that this attribute changes on this version?
where is the documentation for read it about the changes that affect to the attribute on the new RouterOS version?

Thank you,

Best regards

Ixander · February 17, 2021, 2:53pm

On the version 6.47.9 command repartition (e.g. “/partitions repartition partitions =2”) causes the router’s cyclic reboot (about every 10 seconds). On versions 6.47.x situation the same.
On the version 6.46.X and 6.48.X this command works correctly

Ticket SUP-32199 29/Oct/20 6:33 PM

How could a company release an LTS version with such a bug? And there was a ticket from 29 / Oct / 20

eworm · February 17, 2021, 4:01pm

Just get the column name from CLI, Winbox, Webfig, …

I do not think that the changes are documented. Whenever something breaks you have to investigate and change the script.

sequephonic · February 18, 2021, 6:11am

~~[quote=thomascavinato post_id=843182 time=1612981328 user_id=119533]~~
Hi, today unfortunately we tried to update 3 Haplite and they all crashed after updating to version 6.47.9 from 6.40.8. They no longer respond to the winbox and the connected ethernet ports go up and down continuously.

If instead we switch to version 6.48.1 everything is ok. Has this happened to anyone? this is very concerning.
[/quote]

I also have a similar problem with 2 hap light and 1 hap classic.

The problem is one to one as you describe.

pe1chl · February 26, 2021, 8:55am

The problem must be in your network, maybe one or more of your configured DNS resolvers does not respond.

starlingus · February 26, 2021, 9:20pm

~~[quote=sequephonic post_id=844321 time=1613628676 user_id=147651]~~
~~[quote=thomascavinato post_id=843182 time=1612981328 user_id=119533]~~
Hi, today unfortunately we tried to update 3 Haplite and they all crashed after updating to version 6.47.9 from 6.40.8. They no longer respond to the winbox and the connected ethernet ports go up and down continuously.

If instead we switch to version 6.48.1 everything is ok. Has this happened to anyone? this is very concerning.
[/quote]

I also have a similar problem with 2 hap light and 1 hap classic.

The problem is one to one as you describe.
[/quote]

Hi, is there a confirmation from MikroTik of this issue and if so, is there any plan for fixing long-term stream? I have planned remote upgrade of hap lite devices and want to make sure that it is safe. Thank You