MikroTik

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

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.

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.

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.

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

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.

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.

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.

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)

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.

Please read the documentation.

ok. where?

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

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.

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.

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.

[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.

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.

I have a MIKRO TIK RBwAPG-60ad KIT.

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

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 ?

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)

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

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 !

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)

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.

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.

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)

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

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

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)?

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.

New version 6.43.12 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=145204