v6.43.11 [stable] is released!

emils · Tue Feb 05, 2019 11:18 am

RouterOS version 6.43.11 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.43.11 (2019-Feb-04 12:24):

Changes in this release:

*) ipsec - accept only valid path for "export-pub-key" parameter in "key" menu;
*) quickset - fixed "country" parameter not properly setting regulatory domain configuration;
*) smb - fixed possible buffer overflow;
*) w60g - fixed disconnection issues in PtMP setups;
*) wireless - improved antenna gain setting for devices with built in antennas;
*) wireless - show indoor/outdoor frequency limitations under "/interface wireless info country-info" command;

What's new in 6.43.10 (2019-Jan-24 07:09):

(factory only release)

What's new in 6.43.9 (2019-Jan-10 07:11):

(factory only release)

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 concrete RouterOS release.

brainy · Tue Feb 05, 2019 11:43 am

Is the 5 GHz issue with RB4011 fixed ?

TimurA · Tue Feb 05, 2019 1:03 pm

Is the 5 GHz issue with RB4011 fixed ?

I have been testing for an hour, it works, it does not fall.

skylark · Tue Feb 05, 2019 1:18 pm

Is the 5 GHz issue with RB4011 fixed ?

Please provide us step by step example how to repeat your mentioned issue with attached supout.rif file to support@mikrotik.com.

nichky · Tue Feb 05, 2019 1:54 pm

*) ipsec - accept only valid path for "export-pub-key" parameter in "key" menu;

Can we have more info about that.

Thanks

emils · Tue Feb 05, 2019 2:06 pm

What kind of more information you require? It simply validates the file-name value when exporting a public key from IPsec Keys menu.

ErfanDL · Tue Feb 05, 2019 3:06 pm

release the 6.44 as stable. don't releasing spam updates !!!

Tue Feb 05, 2019 3:19 pm

Is the 5 GHz issue with RB4011 fixed ?

Newer generation iPhone/iPad issue will be fixed in RouterOS v6.44

mlenhart · Tue Feb 05, 2019 4:18 pm

WW Dish before upgrade: RSSI -49 on both ends, after upgrade -56 on one side, -59 on 2nd side
After a reboot one side was fixed at -49 RSSI again, but 2nd shows MCS 1 and signal level 20, RSSI -59 again.
After another reboot, it is back on -49 on both ends with MCS 8 and signal level 95.

Another issue iswith making supout.rif - after waiting for more than 10 minutes, it was stucked at 1%. When stopped and tried to run again, I just got an error message: Couldn't start - busy.

TimurA · Tue Feb 05, 2019 4:19 pm

Is the 5 GHz issue with RB4011 fixed ?

Yes, the same problems, 5ghz fell - turned off.

nightcom · Tue Feb 05, 2019 4:32 pm

RB3011-RM updated with no problems

pe1chl · Tue Feb 05, 2019 5:39 pm

*) ipsec - accept only valid path for "export-pub-key" parameter in "key" menu;

Can we have more info about that.

They are fixing the places where commands can write to arbitrary files and thus can destroy internal configuration or open the built-in shell.
Another example was the telnet session log that was recently fixed.
Those bugs can be used by malware to cause more trouble and/or prevent removal of the malware, although they do not pose a security problem themselves.

anav · Tue Feb 05, 2019 6:49 pm

release the 6.44 as stable. don't releasing spam updates !!!

One mans spam, is another mans meat.
To put things in perspective, in Newfoundland, the poor folk had to eat sandwiches everyday of lobster meat.
How awful.

If an interim release is deemed required by MT, then so be it.
I am just super happy they ignore ignorant comments.
I just marked your post as spam!

As for the topic at hand. I recently manually inserted a 2DB antenna gain after watching a recent MUM presentation in the UK (on my capacs).
Will the update automatically insert that gain??

RiniA · Tue Feb 05, 2019 9:04 pm

Is the 5 GHz issue with RB4011 fixed ?
Newer generation iPhone/iPad issue will be fixed in RouterOS v6.44

viewtopic.php?f=7&t=139608&start=100#p710222
Says It should be released in the next public beta version.

Already wating long time now

negavoid · Tue Feb 05, 2019 9:47 pm

Aren't you still planning to integrate udpxy from openwrt into RouterOS? It depends only from libc, and compiles under any architecture easily, and a lot of users pleasing you to add, and when you claims "router should do routing and not being overloaded by 3rd party crap" - that's it, just route for my TV's udp multicast to http tcp stream, this action won't eat CPU so much. You are don't giving a chance to do anything, proprietary OS, no toolchains to compile, no ways to create packages, just metarouter - that is not useful on hAP.

mszru · Wed Feb 06, 2019 1:30 am

After upgrading hEX and hAP ac from 6.43.8 to 6.43.11 (ROS and FW) samba got broken.
I got the following message in Windows 10:

\\router.lan\backup is not accessible. You might not have permission to use this network resource...
The parameter is incorrect.

I restored access to samba shares by downgrading hEX back to 6.43.8 and hAP ac to 6.43.10 (factory only release).

i4ko · Wed Feb 06, 2019 7:18 am

Memory leak in proxy on HEX r3 still present. Behavior is the same as described in the 6.43.8 thread

With proxy disabled the memory usage is around 42mb. If you enable the proxy but don't send any traffic the memory consumption stays at 42mb. As soon as you open the web proxy interface in winbox the memory consumption jumps to 64mb (still no traffic via proxy). As soon as any traffic flows via the proxy the memory consumption jumps to 102mb. At the same time, if you go and look at the proxy it says Total RAM Used: 996KiB. So something somewhere is leaking close to 60mb. This did not happen before on 6.42.7 or older versions.

eddieb · Wed Feb 06, 2019 8:57 am

Upgraded from 6.43.8 -> 6.43.11
using dude to push the packages on

CCR1009-8G-1S (2x ipsec/l2tp site-to-site, dhcpd)
CRS125-24G-1S
RB1100
RB962UiGS-5HacT2HnT (10pc)
RB951
RB750GL
RB2011UAS-RM
CHR running dude (CHR running in VirtualBox on OSX)

without any issues

GuntOn · Wed Feb 06, 2019 10:22 am

*) wireless - improved antenna gain setting for devices with built in antennas;

What it exactly means?

pavlan · Wed Feb 06, 2019 10:27 am

I guess it works now.

May be they have some predefined defaults for such devices ?
So users report lower signal after upgrade...

*) wireless - improved antenna gain setting for devices with built in antennas;
What it exactly means?

Wed Feb 06, 2019 10:34 am

Those are indoor devices with 1-2dBi gain antennas. There should be not much actual difference in coverage.

Egert143 · Wed Feb 06, 2019 11:08 am

Hello

*) snmp - added "tx-ccq" ("mtxrWlStatTxCCQ") and "rx-ccq" ("mtxrWlStatRxCCQ") values;

Still not working, any eta on the fix ?

Egert

h17 · Wed Feb 06, 2019 11:21 am

LHG-5HPnD after upgrade (6.43.8 to 6.43.11) antenna gain has been set to 25dB (minimal value I can set), Rx dropped from -60dBm to -85dBm.
I don't get it why you subtract antenna gain from received signal level, but ok... I wouldn't care the numbers if link worked fine, but IT IS NOT.
Stable link became totally unstable. Disconnects about every 30 seconds. Rolled back to 6.43.8.

OndrejHolas · Wed Feb 06, 2019 1:19 pm

LHG-5HPnD after upgrade (6.43.8 to 6.43.11) antenna gain has been set to 25dB (minimal value I can set), Rx dropped from -60dBm to -85dBm.

If the other side was not upgraded also, Rx signal strength shown here seems to be corrected by antenna gain, but this is just number. The problem causing link drops is that Tx power is reduced by antenna gain configured.

6.43.11 sets new minimum for antenna gain based on model. This hardcoded minimum can be retrieved:

[admin@wapac] > /interface wireless info hw-info wlan1
ranges: 2312-2732/5/b,g,gn20,gn40
2484-2484/5/b,g,gn20,gn40
tx-chains: 0,1
rx-chains: 0,1
extra-info: pciinfo:0x0, cid:0, gain:2

You can still increase absolute transmit power by setting country to no_country_set and frequency-mode to superchannel, but unless the antenna is operating in shielded environment, the device probably violates local regulations, as it does with previous version and antenna gain set to 0 dB as well.

Ondrej

Wed Feb 06, 2019 1:20 pm

I don't get it why you subtract antenna gain from received signal level

Both sides of your link have antennas, the gain is subtracted from the TX power (as it should be, according to regulations). The signal dropped by the amount because the TX power on the other end was reduced (also).

pribeiro · Wed Feb 06, 2019 1:42 pm

After upgrade from 6.43.8 to 6.43.11 the "Registration Table" tab that shows the connected users associated is now reporting the interface as "unknown" see screenshots taken from two WLCs one still with the old version and another with the new one.
Could be just a listing problem but it could also affect the awareness of the users by the WLC ...

6.43.8

https://www.dropbox.com/s/pqcusgpzz1rat ... 8.png?dl=0

6.43.11

https://www.dropbox.com/s/h24081alo17j0 ... 1.png?dl=0

Note: Both the WLC (CHR) and the APs (wAP ac) were upgraded.

regards!

bizzy · Wed Feb 06, 2019 2:25 pm

After upgrading hEX and hAP ac from 6.43.8 to 6.43.11 (ROS and FW) samba got broken.
I got the following message in Windows 10:
\\router.lan\backup is not accessible. You might not have permission to use this network resource...
The parameter is incorrect.
I restored access to samba shares by downgrading hEX back to 6.43.8 and hAP ac to 6.43.10 (factory only release).

Confirm issue. Samba lose access after upgrade on firmware 6.43.11. Downgrade on 6.42.11 - restored access.

h17 · Wed Feb 06, 2019 4:08 pm

Both sides of your link have antennas, the gain is subtracted from the TX power (as it should be, according to regulations). The signal dropped by the amount because the TX power on the other end was reduced (also).

So, if I understood you correctly, before 6.43.11 antenna gain was also subtracted, but not enforced to be set whatsoever?
I had 0 there all the time before. Thought it means "default".

Anyway, I have short link (500m) with a few trees in the middle of LOS.
I put LHG-5HPnD (24.5dBi antenna gain) on one side and SXT Lite5 (16dBi) on the other.
Both are elevated. It's only couple of trees in the middle. And it's winter now.
I can't believe, respecting all regulations, my signal would be below -80dBm.
Not with such high gain antennas on so short distance.

To be precise, I (temporarily) upgraded only LHG. It was unbeareable. I was afraid to touch remote SXT,
because I don't have remote hands there and connection was unstable. I had to downgrade.
Any idea what is going on?

h17 · Wed Feb 06, 2019 4:18 pm

If the other side was not upgraded also, Rx signal strength shown here seems to be corrected by antenna gain, but this is just number. The problem causing link drops is that Tx power is reduced by antenna gain configured.
6.43.11 sets new minimum for antenna gain based on model.

Yup, that was my guess. Just couldn't believe the result would be so unpleasant.

You can still increase absolute transmit power by setting country to no_country_set and frequency-mode to superchannel, but unless the antenna is operating in shielded environment, the device probably violates local regulations, as it does with previous version and antenna gain set to 0 dB as well.

I get that. I wrote how my link looks like in the post few minutes ago. So crappy signal received over 500m? It doesn't compute in my head.

eworm · Wed Feb 06, 2019 4:26 pm

*) wireless - improved antenna gain setting for devices with built in antennas;

How is this handled with capsman?

mkx · Wed Feb 06, 2019 4:27 pm

I put LHG-5HPnD (24.5dBi antenna gain) on one side and SXT Lite5 (16dBi) on the other.
Both are elevated. It's only couple of trees in the middle. And it's winter now.
I can't believe, respecting all regulations, my signal would be below -80dBm.
Not with such high gain antennas on so short distance.

Legal limits are about EIRP. EIRP is not Tx power at transmitter's RF connector, it's power at antenna perimeter. And that value is affected by antenna gain. Which is not how most of WiFi users (and, sadly, WISPs) understood things ...

Hence ... if legal limit is, say, 20dBm, substract 24.5dBi gain, add 0.1 dB cable loss and you get -4.4dBm (which is 0.363 mW) Tx power at LHG's power amplifier). Until now, actual Tx power was actually set to 20dBm (not taking antenna gain into account), so actual EIRP was 44.4dBm ...

pe1chl · Wed Feb 06, 2019 4:34 pm

I get that. I wrote how my link looks like in the post few minutes ago. So crappy signal received over 500m? It doesn't compute in my head.

Maybe your link is not as good as you believed it was.
Actually, trees make a lot of attenuation, more so in summer than in winter but still.
And a LOS path is not only defined by "I see the remote antenna", you actually have to take the Fresnel zone into account.
(which means that halfway the path you need a larger unobstructed zone than at the endpoints)

Anastasia · Wed Feb 06, 2019 4:35 pm

IPsec settings are not saved and are reset. If you open through winbox when you log in IPsec - > Peers in one of the settings, the certificate settings are reset and does not save. I change the settings and then after a while they are reset again. when opened in winbox, it shines blue as if I had changed something, but I did not change anything. This is a bug, fix it Please!

Cha0s · Wed Feb 06, 2019 4:49 pm

Legal limits are about EIRP. EIRP is not Tx power at transmitter's RF connector, it's power at antenna perimeter. And that value is affected by antenna gain. Which is not how most of WiFi users (and, sadly, WISPs) understood things ...

I remember attending a Netgear "seminar" back in 2005-2006ish about their WiFi products, and I was trying to explain to the presenter that their products violated the law about EIRP (based on what he was trying to push to us - an access point -with no tx power control- and a high-gain panel antenna to be used together).
He just could not fathom that that's the way you calculate the EIRP

pe1chl · Wed Feb 06, 2019 5:08 pm

Tx power control is another thingie... as far as I know it is mandatory for EU 5.6 GHz outdoor WiFi (like DFS) but it isn't available in MikroTik.

h17 · Wed Feb 06, 2019 5:11 pm

Legal limits are about EIRP. EIRP is not Tx power at transmitter's RF connector, it's power at antenna perimeter. And that value is affected by antenna gain. Which is not how most of WiFi users (and, sadly, WISPs) understood things ...

Hence ... if legal limit is, say, 20dBm, substract 24.5dBi gain, add 0.1 dB cable loss and you get -4.4dBm (which is 0.363 mW) Tx power at LHG's power amplifier). Until now, actual Tx power was actually set to 20dBm (not taking antenna gain into account), so actual EIRP was 44.4dBm ...

I understand all that. Really. Just can't believe Mikrotik (until now) did not respect (or better word would be enforce) local regulations. I saw soooo many radiolinks based on MT with clear LOS (Fresnel zone 1) and signals levels below -70dBm. I'm guessing most of them would now stop working... if ISPs upgraded their MT's firmware. And they will if they do.
I always thought antenna_gain=0 means "set it for me", especially on hardware with built-in antennas.

pribeiro · Wed Feb 06, 2019 5:34 pm

Forget. The problem has disappeared!
I've made a new WEBFIG access a few minutes ago and the interfaces are now correctly listed.
Probably the problem were some old CSS/JS not refreshed in the browser cache.
regards!

After upgrade from 6.43.8 to 6.43.11 the "Registration Table" tab that shows the connected users associated is now reporting the interface as "unknown" see screenshots taken from two WLCs one still with the old version and another with the new one.
Could be just a listing problem but it could also affect the awareness of the users by the WLC ...

6.43.8

https://www.dropbox.com/s/pqcusgpzz1rat ... 8.png?dl=0

6.43.11

https://www.dropbox.com/s/h24081alo17j0 ... 1.png?dl=0

Note: Both the WLC (CHR) and the APs (wAP ac) were upgraded.

regards!

dakotabcn · Wed Feb 06, 2019 8:30 pm

HELP!
i have upgraded the RB4011 wireless and not work
the router flickers the lights of the SFP and the switch but it does not start, I've tried it in every way and it does not happen there, I had the 6.34.8 and updated this version this morning
I need help, because right now it is totally out of service, luckily I still keep the 951G and I can have internet, but I need to recover the RB4011

solved but with a strong dislike
I had to use netinstall to recover it
I have to reinstall everything again, this is not normal, if I had not had the reserve RB951 I would have everything stopped

HarryK · Wed Feb 06, 2019 9:05 pm

After upgrading my RB3011, one of the CPUs peeks at 100% all the time (switches back and forth between CPUs). Anyone else with the same problem?

afhpwnd · Wed Feb 06, 2019 9:20 pm

samba got broken after upgrade rb951ui-2hnd from 6.43.8 to 6.43.11.
When you make speed smb more than 5-6MB\s ?

Kindis · Wed Feb 06, 2019 9:42 pm

After upgrading my RB3011, one of the CPUs peeks at 100% all the time (switches back and forth between CPUs). Anyone else with the same problem?

No both of mine are just fine. Have you updated firmware and rebooted a second time?

florid · Thu Feb 07, 2019 1:21 am

Anyone noticed interface connectivity issue after upgrade?
I have a remote HEX POE. No issue with the firmware upgrade. Rebooted twice and looks good. I can remote access the box via winbox without any issue.
But after a third reboot, I noticed one interface to Synology NAS only has TX packet but very little RX packet. I also have difficulty to access that NAS.
On HEX POE remote, I can ping NAS IP, but no access to any TCP/UDP ports of the NAS. My first thought was there's something wrong with the NAS firewall/iptables that blocked inbound requests. But there's even no outbound traffic from NAS that surprised me. Then I believe it must be some connectivity issue between the router and the NAS.
Because those devices are remote, my last resort is to reboot the HEX POE router forth time. Then everything backs to normal.

Not really sure if it is Mikrotik related. But I am happy to provide support file if Mikrotik is interested.

i4ko · Thu Feb 07, 2019 6:58 am

I put LHG-5HPnD (24.5dBi antenna gain) on one side and SXT Lite5 (16dBi) on the other.
Both are elevated. It's only couple of trees in the middle. And it's winter now.
I can't believe, respecting all regulations, my signal would be below -80dBm.
Not with such high gain antennas on so short distance.
Legal limits are about EIRP. EIRP is not Tx power at transmitter's RF connector, it's power at antenna perimeter. And that value is affected by antenna gain. Which is not how most of WiFi users (and, sadly, WISPs) understood things ...

Hence ... if legal limit is, say, 20dBm, substract 24.5dBi gain, add 0.1 dB cable loss and you get -4.4dBm (which is 0.363 mW) Tx power at LHG's power amplifier). Until now, actual Tx power was actually set to 20dBm (not taking antenna gain into account), so actual EIRP was 44.4dBm ...

Disclaimer, I'm not a radio guy, but I'm not sure that is correct based on what I remember from my army radio training and the radio relay class I had with a vendor from Scandinavia 15 years ago (around 27GHz). Antennas are passive elements, the power radiated at the antenna is always less than the power fed to it. Antenna "gain" describes the efficiency of the antenna to convert radio waves into electricity. It is always less than 1. You do subtract/reduce the antenna gain (though we always expressed it as ratio) only when receiving in order to set your high frequency receive amplifiers correctly to avoid signal clipping on the low frequency side, but there is no such thing when transmitting, as the antenna reduces the signal. Now, that may have been something specific to the antennas and the equipment we were using, but it is physically impossible for an antenna to radiate more power than the amplifier sends to it, e.g. if your amplifier is sending out 10W what gets radiated in the air is always less than those 10W, so you need to increase the power of the amplifier to account for the inefficiency at of the antenna on the transmit side
Though I'm sure the army training is for war time when things like observing radiated power regulations don't have top priority.

Thu Feb 07, 2019 7:24 am

i4ko, EIRP is not so much about the power as about the density of radiation, so for directional antennas the gain may easily be much higher than 1.

i4ko · Thu Feb 07, 2019 7:35 am

i4ko, EIRP is not so much about the power as about the density of radiation, so for directional antennas the gain may easily be much higher than 1.

Thanks Andriys. But isn't EIRP by definition equal distribution in 360 degree in all 3 directions (sphere), hence being called isotropic. A directional antenna will emit in roughly a cone, so if that cone is inside a sphere (same center/top of cone) it can concentrate much more radiation inside the volume of the cone while still having the same total radiation in the volume of the sphere.

mkx · Thu Feb 07, 2019 8:50 am

But isn't EIRP by definition equal distribution in 360 degree in all 3 directions (sphere), hence being called isotropic. A directional antenna will emit in roughly a cone, so if that cone is inside a sphere (same center/top of cone) it can concentrate much more radiation inside the volume of the cone while still having the same total radiation in the volume of the sphere.

A quote from Wikipedia puts it nicely:

Effective radiated power (ERP), synonymous with equivalent radiated power, is an IEEE standardized definition of directional radio frequency (RF) power, such as that emitted by a radio transmitter. It is the total power in watts that would have to be radiated by a half-wave dipole antenna to give the same radiation intensity (signal strength in watts per square meter) as the actual source at a distant receiver located in the direction of the antenna's strongest beam (main lobe).

(it then goes on describing how EIRP differs from ERP, but distinction is not really relevant for this debate).

So, EIRP takes into account antenna gain ... If you think of it, legal limits are set to protect public (or whoever) from high EM field powers (or excess interference to other users in case of ISM bands) and "worst" case should be considered. From that point of view, antenna main lobe is the worst case.

Though I'm sure the army training is for war time when things like observing radiated power regulations don't have top priority.

That's quite right and probably any army around the world follows this principle also in peace-time most of the time

eworm · Thu Feb 07, 2019 9:57 am

Anyone noticed interface connectivity issue after upgrade? [...]

I saw this on a device that had internet detection enabled. Try this:

/ interface detect-internet set detect-interface-list=none;

myhaycracyun · Thu Feb 07, 2019 12:43 pm

I have a MIKRO TIK RBwAPG-60ad KIT.

1.

First time I had 6.42.5 and was with the Master and Slave.
Then I updated from 6.42.5 to 6.43.7 and today at 6.43.11.
Since then (6.45.5) when I want to see the status of both units, the values are updating very very slow or nothing at all. (signal, mcs, PHY Rate, RSSI).
When I had 6.42.5, the values were updating very fast, in real time, when the traffic was high or slow.
Now on 6.43.7 or 6.43.11 as I said, the values are updating very very slow. I have to reboot the units to see real values.
Any ideas?

2.

I have on one unit (receiver): 110 m, signal 95, mcs 8, phy 2.3 Gbps and rssi -56 to - -62.
I have on the second unit (signal with the internet input): signal 65, mcs 8
a. Are good values for this distance? Was it supposed to be better?
b. signal and mcs must be the same on both units?

Sometimes I have to give some more restarts to get good values for the mc and rssi signals. It is normal ?

transmitter.jpg

receiver.jpg

chriscolden · Thu Feb 07, 2019 1:06 pm

Any update on when the access port issue on the RB3011 will be fixed. Only some of the traffic is tagged with a vlan id. I reported to support back in September. Thanks

anuser · Thu Feb 07, 2019 2:02 pm

6.43.11: cAP AC + CCR running as CAPSMAN based forwarding: 2.4Ghz has terrible performance / disconnect issues. Back to 6.43.8

Beone · Thu Feb 07, 2019 4:39 pm

this new 'feature'

*) wireless - improved antenna gain setting for devices with built in antennas;

messes up a lot of things.

When running capsman: it will for example say: 16dbm output power
when checking on the caps (having internal antenna gain of 2.5~3dbm); there it will say 13dbm. We already had manually configured antenna-gain to 3dbm on the cap;
but now it is very confusing on what is really happening and we see an effective drop in output power towards the clients...

Please explain behavior with antenna gain (configured/unconfigured on hap ac for example) connected to capsman controller; also your wiki probably needs an update about this...

Furthermore: iphone 7 is not able to connect to 5Ghz network anymore for RB4011 series wifi. It does however connect to a 2Ghz network on that same RB4011.

Ticket#2019020722006009

pe1chl · Thu Feb 07, 2019 5:13 pm

You have to understand that with a dual-chain radio the output limit is not the power per chain but the added power.
So when you would calculate a 16dBm output power limit for your antenna and local regulations, and it is a dual-chain device, it is correct that it is set to 13dBm.

tsaihungpin · Thu Feb 07, 2019 6:00 pm

I updated my RB3011 to v6.43.11.
There are two site to site IPsec tunnels in my environment and also configured Simple Queues to control bandwidth.
Above configurations are working perfectly at v6.38.
A strange issue w/ v6.43.11 is that I need to run Tools/Torch simultaneously, Or the connectivity of IPsec tunnels will get very very slow and Queue policy won't work.
Connectivity of NAT is ok.

Any suggestions?
Thanks in advance.

pe1chl · Thu Feb 07, 2019 6:49 pm

This is a fasttrack issue. Try to disable fasttrack or limit the connections that are fasttracked to those that do not require IPsec and Queue.

Zikasak · Thu Feb 07, 2019 8:03 pm

This is a fasttrack issue. Try to disable fasttrack or limit the connections that are fasttracked to those that do not require IPsec and Queue.

thanks. Have same problem with Mangle. Disabling fasttrack helps.Hope Mikrotik fix it soon

Thu Feb 07, 2019 8:24 pm

Disabling fasttrack helps.Hope Mikrotik fix it soon

This is not a bug and cannot be fixed. This is how fasttrack works. Please read the documentation.

Zikasak · Thu Feb 07, 2019 8:56 pm

Disabling fasttrack helps.Hope Mikrotik fix it soon
This is not a bug and cannot be fixed. This is how fasttrack works. Please read the documentation.

ok. where?

And if lagging when activating fasttrack and mangle simultaneously is documented it still issue. Mikrotik can write code to automatically disabling fasttrack when user add mangle rule.

pe1chl · Thu Feb 07, 2019 9:22 pm

Fasttrack is a short-circuit around the more advanced features of the router to speed-up the common case of "I only want a simple router with or without NAT".
It is not faster because some handbrake is released, it is faster because a lot of checks made on each packet being routed are not made and the packet is immediately forwarded.

So, when you want to use Mangle, IPsec, Queue (except queue tree), etc etc you CANNOT use fasttrack.
However, fasttrack is a switch that is made per tracked connection, so when you make your fasttrack rule clever you can sometimes route the majority of the traffic using fasttrack and only keep it disabled for some special traffic that is lower in volume. You can do this by adding more conditions to the fasttrack rule.
(e.g. some VPN to another location or some traffic you want to route in a special way)

When this does not apply to you (i.e. you have a complicated mix of traffic that requires those special features all the time) then just forget that fasttrack exists. It is not for you.
Remove the "fasttrack" rule and reboot, then you see the special rule for fasttrack counters at the top is also removed.
And all special features work.

I do this for every MikroTik I receive.

Zikasak · Thu Feb 07, 2019 10:10 pm

Fasttrack is a short-circuit around the more advanced features of the router to speed-up the common case of "I only want a simple router with or without NAT".
It is not faster because some handbrake is released, it is faster because a lot of checks made on each packet being routed are not made and the packet is immediately forwarded.

This description doesn't describe why instead of ignoring applyied (for ex by mangle) changes it apply (for me - route mark) it but with huge delay. Failover? But documentation says that mangle rules not applied to fasstrack.

However I found solution with working mangle and fasttrack without lags (of course not both for one connection)

pe1chl · Fri Feb 08, 2019 12:05 am

Actually fasttrack does the normally short-circuited checks once-in-so-many times (like 1 in 20 packets). This is done to help connection tracking, counters, etc.
So when you have a fasttrack problem it usually does not fail to work completely, it just becomes very slow or inefficient.

Actually this isnt't at all 6.43.11 related, we really should not be discussing it here. However with every new release topic there usually are these comments.
What is happening: in some new versions new support for fasttrack is added. E.g. some time ago fasttrack support for PPPoE client was added.
Now when someone updates in huge leaps (like the fellow above who went from 6.38 to 6.43.11) they suddenly get confronted with fasttrack that wasn't active for them because one or more of their interfaces did not support it before.
Now they blame it to a bug in the new version, but rather it is their lack of understanding of the whole fasttrack thing which wasn't a problem before.

One could argue if fasttrack should be disabled in the default config so it would have to be enabled explicitly and the operator is supposed to know what side-effects that will incur, but understand that router manufacturers want to make their device perform as well as possible in default config, e.g. for benchmarks done in reviews and in their own spec sheets.
There is kind of a conflict between fastest possible performance and most advanced features. The user is supposed to know that.
Automatically disabling fasttrack whenever you touch one of the features it conflicts with is a solution, but it will likely still confuse people, and as I wrote, it is not really required to completely disable fasttrack when you can divide between traffic that does require it to be disabled and other traffic for which it is no problem.

When you read "when I try to capture the traffic or use Torch it works OK" the issue is fasttrack. That is because enabling those features disables fasttrack.

Fri Feb 08, 2019 8:37 am

Please read the documentation.
ok. where?

Here: https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack

Zikasak · Fri Feb 08, 2019 10:37 am

Please read the documentation.
ok. where?
Here: https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack

This article doesn't have any mentions about lags when mangle activated.

pe1chl · Fri Feb 08, 2019 10:52 am

That is because there is no "lags when mangle activated".
The documentation says:

FastTracked packets bypass firewall, connection tracking, simple queues, queue tree with parent=global, ip traffic-flow(restriction removed in 6.33), IP accounting, IPSec, hotspot universal client

So you should have noted that you CANNOT use "/ip firewall mangle" in combination with fasttrack.

The reason you get "lags" instead of complete failure is also explained:

Note that not all packets in a connection can be FastTracked, so it is likely to see some packets going through slow path even though connection is marked for FastTrack.

However I agree that is documentation page is far too vague and should explain a bit more about such topics.

Fri Feb 08, 2019 10:57 am

This article doesn't have any mentions about lags when mangle activated.

Should it? What you call "lags" are symptoms, not the problem itself. The main thing that article tells you is the following:

Warning: Queues (except Queue Trees parented to interfaces), firewall filter and mangle rules will not be applied for FastTracked traffic.

Everything else is just an effect of you trying to apply mutually incompatible technologies to the same traffic. What those effects are depends heavily on your router's configuration, and I don't see documenting every possible symptom being in any way feasible.

pe1chl · Fri Feb 08, 2019 11:17 am

[I don't see documenting every possible symptom being in any way feasible.

Well, the documentation page looks more like a change list item made when the feature was introduced than a useful documentation page for the feature.
It should start with a paragraph that explains what Fasttrack actually is and does, and why.

Many users now seem to believe that this is just a "set and forget" option that only brings you benefits and it would be stupid to turn it off and get worse performance.
Especially because it is enabled by default, and all those places where other features (e.g. mangle in this case) are explained usually do not refer back to fasttrack.
("before you can use this feature, you first need to turn off fasttrack, see https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack")

So it is actually not so surprising that a newish user who is searching for a solution to their particular requirement and finds and configures is, is then surprised that it does not work and it is because fasttrack is still enabled on his router.

Fri Feb 08, 2019 11:43 am

Well, we are getting a bit off-topic here...

To be clear, I'm not saying that the documentation as it is now is perfect. You are right in that it may and should be improved in lots of rather reasonable ways. However complaining about the fasttrack page not telling about "lags when mangle activated" is still silly.

Fri Feb 08, 2019 2:18 pm

I have a MIKRO TIK RBwAPG-60ad KIT.

Data is only updated when beamforming is working - we will fix this in upcoming versions

nookey · Fri Feb 08, 2019 2:49 pm

Hi 2 all! If I'll upgrade mikrotik from 6.42.1 to 6.43.11 with a lot firewall rules, caps-man and vlan created I will get problem that something will not work ?

Beone · Fri Feb 08, 2019 3:39 pm

You have to understand that with a dual-chain radio the output limit is not the power per chain but the added power.
So when you would calculate a 16dBm output power limit for your antenna and local regulations, and it is a dual-chain device, it is correct that it is set to 13dBm.

If this would be true, then a tx power of 17dbm with 3 chains should results in about 12dbm, which it aint, it's 14dbm (still just the minus 3dbm configured antenna gain)

kamillo · Fri Feb 08, 2019 3:47 pm

Hi 2 all! If I'll upgrade mikrotik from 6.42.1 to 6.43.11 with a lot firewall rules, caps-man and vlan created I will get problem that something will not work ?

No one can possibly answer that question. Start with checking changelogs: https://mikrotik.com/download/changelogs

tsaihungpin · Fri Feb 08, 2019 5:37 pm

This is a fasttrack issue. Try to disable fasttrack or limit the connections that are fasttracked to those that do not require IPsec and Queue.

Hi pe1chl
I just want to say "thanks" to you after I removed fasttrack as your suggestion. Everything is working perfectly.
You're a lifesaver !

pe1chl · Fri Feb 08, 2019 6:53 pm

Hi pe1chl
I just want to say "thanks" to you after I removed fasttrack as your suggestion. Everything is working perfectly.
You're a lifesaver !

Ok I hope you also have read the remainder of the discussion that explains how this confusion arises and why it sometimes causes problems.
Completely disabling fasttrack is the safest solution. It may cause some performance hit but modern devices usually have enough performance.
(you can check the CPU load of the router and/or do some speedtest)

Micropower · Sat Feb 09, 2019 9:32 am

Forced to drop back to 6.43.8 on RB4011. Not stable and drop in routing performance with some CAPS and VPN issues.
May have been script specific. Not sure how to downgrade once you update the Routerboard FW. Lucky I had a new spare 4011 in box,
EDIT: Disabling FastTrack fixed all... Thanks !! I'm not clear on possible IPSec changes however.

mkx · Sat Feb 09, 2019 11:20 am

Not sure how to downgrade once you update the Routerboard FW. Lucky I had a new spare 4011 in box,

I don't think there's a limitation that routerboot should not be higher version than ROS.

pe1chl · Sat Feb 09, 2019 6:21 pm

That is right, you can downgrade just the RouterOS, there is no need to downgrade the Routerboard Firmware.
There is usually no change in them anyway. A while ago the unfortunate decision was made to release the Firmware under the same version number as RouterOS itself, but usually there are no changes and the update from 6.43.8 to 6.43.11 in Firmware just changed the version number, nothing else.
(before this, the firmware had a much lower version number that rarely changed. it was probably modified because people when asked "what RouterOS version do you have" sometimes replied with the Firmware version number which was useless)

paoloaga · Sat Feb 09, 2019 7:07 pm

Forced to drop back to 6.43.8 on RB4011. Not stable and drop in routing performance with some CAPS and VPN issues.

In my setup 6.43.11 slows down and cause troubles to VPNs of connections encapsulated in PPPoE that pass through a bridge if I have "/interface bridge settings set use-ip-firewall=yes use-ip-firewall-for-pppoe-yes" to snoop inside pppoe packets and set priorities accordingly (to handle voip QoS).

Setup (things between square brakets are separate devices):
[router] --<pppoe>--[bridge with use-ip-firewall]---[pppoeconcentrator]---->theinternet

isaacgrover · Sat Feb 09, 2019 9:28 pm

Good afternoon from western Wisconsin,

After upgrading my company's CCR1009 to v6.43.11, the local DNS resolver stopped resolving. A rollback to v6.43.4 restored local DNS resolution. Has anyone else experienced this same issue after upgrading to v6.43.11 ?

Thank you in advance,
Isaac Grover

WildRat · Mon Feb 11, 2019 11:06 am

Such power correction based on the antenna gain makes the use of antennas with dbi > 2 practically useless. Since using a high gain antenna, we trade the width of the "beam" into its "concentration" to get the range increase. Then, with such auto correction , we will get almost the same range with degraded spreading. I would like to hear an official opinion of Mikrotik on this matter. Am I right in my reasoning that the use of such antennas when specifying the correct data in the settings is impractical? And the only use for them is commercial use with broadcast licenses and using manual settings (not a regulatory)?

pe1chl · Mon Feb 11, 2019 11:14 am

Such power correction based on the antenna gain makes the use of antennas with dbi > 2 practically useless. Since using a high gain antenna, we trade the width of the "beam" into its "concentration" to get the range increase. Then, with such auto correction , we will get almost the same range with degraded spreading.

That is incorrect. The gain concentrates your TX power in a smaller spot, but it also concentrates your receive spot which means you reduce the interference and you also gain signal.
This increases your performance on point-to-point links, which is what those antennas are for.
The licensing has always specified power as EIRP, Effective Isotropic Radiated Power, which means the 1W EIRP is the same as a 1W transmitter radiating into an antenna with 0dBi gain and when your antenna has gain you should reduce the transmit power.

Note that this change is not something invented by MikroTik who are trying to kill your links.
It is enforced by regulators who have told MikroTik they facilitate illegal use of the bands (even with default settings) and they had to correct this or else stop sales.

emils · Mon Feb 11, 2019 2:50 pm

New version 6.43.12 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=145204

Who is online