BEWARE !
Updating from 5.xx (5.27 I think) to this version will result in inaccessible device ! It will enter reboot loop.
I’ve done it on 15 pcs of rb751 and rb951-2n.
Netinstall will fix if you mess up.
Mikrotik please update your upgrade procedures
You just simply decided on a nice Saturday morning to upgrad from 5.xx over more than 43 releases to an rc version and are surprised that it did not work? I am not. You should expect a problem if you upgrad any software between so many releases.
Hi, thanks for your simphaty.
I’ve tested it on device that had 6.0 prior to this and I saw it fixed wifi problem.
I was so happy.
Then I upgraded others(batch upgrade), and this problem happened.
I understand this is RC, and I wanted to warn others not to do same mistake, as well as mikrotik to fix or disable this type of upgrade.
That is sole purpose of forum community.
Best regards
Thank you for warning but how many people do batch upgrade from such old version?
You have checked procedure with ROS 6.0 and extrapolated that 5.x should work too. You are brave admin.
Have you read changelogs? https://mikrotik.com/download/changelogs
Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface “master-port” configuration into new bridge configuration, and eliminate “master-port” option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus for now.
Please, note that downgrading to previous RouterOS versions will not restore “master-port” configuration, so use backups to restore configuration on downgrade.
BartoszP, this site(hotel) has 200 ap-s dislocated on premises.
I have done previous upgrades from 5.x to 6.x without problems.
This particular release has bug in upgrade procedure.
Routerboard stuck in reboot loop.
It does not have any relation with changelog.
Netinstall to version 6.42 works fine.
Hope it will save time to someone else.
So why you have not upgraded first to 6.40.7 (bugfix) with old bridge implementation?
Why are you upgraded working hotel infrastructure to RC version? RC is test version so upgrade could fail.
It was a sunny and beautiful day. Murphey was out of the town.
Found an other problem with this RC. When I want to add a filter line using a script run at an On-UP event then “Place Before” or the whole script is not executed. The filter line is not added in the Nat table in my case.
When I enter the line manually in Terminal then the line is added without an hitch.
Ticket#2018042122002234
Phone: huawei p9 lite
Problem: slow Wlan throughput and packet loss
Reported: year ago 
Fixed: in v6.43rc3
Speedtest before upgrade: 19mbit / 39mbit
After upgrade: 89mbit/89mbit
Wondering if “auto” channel problems fixed too.
It would be prefferable to merge that fix to current/bugfix branch, so I can rollout updates for my customers.
Did this work in the previous versions? If yes, how exactly does that script line look like (I’m not interested in particular IP addresses but in the way how you obtain the index for ****
place-before
)
I did test upgrade from 5.26 to this version. Just for testing. Everything went well. Upgrade failed for you due to configuration or something like thta. In general it works just fine.
It worked up to 6.42. You can’t find that specific index and then you have to just make it yourself easy. The index is always the second line of the Hairpin in NAT, it pushes down earlier lines. When a VPN connection is severed the then the line is removed, and if not then it is removed on the following connect. I also remove on UP, the specific dead connections that might have not timed out in the meantime for that specific VPN connection.
On-up:
/ip firewall nat remove [find where comment="temp-vpn1"]
/ip firewall connection remove [ find where connection-mark="VPN1"]
:local ip [/ip address get [find where interface="VPNprovider-1"] value-name=address ];
/ip firewall nat add chain=srcnat action=src-nat to-addresses=$ip protocol=tcp src-address-list=PrivateVPN connection-mark=VPN1 comment="temp-vpn1" place-before=1
On-down:
/ip firewall nat remove [find where comment="temp-vpn1"]
Deleted. Wrong thread. Kid control bug in webfig is in current release (not checked RC yet)
That was my suspicion - numeric index can be used to identify a rule only following a ****
print
when doing manual configuration as the index is dynamically generated. Without the previous
print
, index 0 sometimes works but you cannot rely even on that when using it for
place-before
, as some chains contain dynamic rules which must stay at the beginning of the chain so any attempt to place a rule before them fails.
So to stay version-independent, comment the rule before which you want to place your one and use ****
place-before=[find comment="your-comment"]
.
It seems that the “comment” possibility is the BEST thing in RouterOS. Maybe Mikrotik should think of making this way of working official and implement a tag or label available so that comment can just be a comment.
Thanks Sindy for making this clear so the next time we don’t think, WTF is happening now. 
Update: it works like a charm and I have inserted a dedicated passthrough&comment line for this so that I can be sure it will inserted at the correct spot. I will migrate again to 6.43RC now to see if the port +10000 bug is reoccurring.
Update 2: I have implemented the suggestions by Sindy and the new script is:
On-Up:
:local profile "1"
/ip firewall connection remove [ find connection-mark="VPN$profile"]
:local ip [/ip address get [find where interface="permanent-vpn-$profile"] value-name=address ];
/ip firewall nat set [find comment="permanent-vpn-$profile"] disabled=no to-addresses=$ip
On-Down:
:local profile "1"
/ip firewall nat disable [find comment="permanent-vpn-$profile"]
/ip firewall connection remove [find connection-mark="VPN$profile"]
I have more than one connection and to adapt it each time was cumbersome so I defined :local profile “X” to only have to change the number/name to create the script for the new connection.
Using SET instead of ADD to manipulate the lines in the NAT is a great tip by Sindy. https://forum.mikrotik.com/viewtopic.php?f=21&t=133420&p=656006#p656033
VirtIO multi-queue appears to be working:
PS: I have poor connectivity at my present location, the gaps in the graph relate to this,not the release candidate’s performance…
Nice to see MikroTik tying the input and output vCPU assignments to the same core. This correlates to information published here:
https://www.linux-kvm.org/page/Multiqueue-optimization.
Do MikroTik use a flow director, to assign outgoing traffic back to the queue it came in on? Does this subsequently require connection tracking?
Finding a rule by a comment is the last resort, you can find a rule using a unique combination of other parameters as well (if a unique combination exists of course).
And in your case, you don’t need to use another rule as a label holder, you could as well keep your rule in place and just modify it:
On up:
/ip firewall nat set [find comment="permanent-vpn1"] disabled=no to-addresses=$ip
On down:
/ip firewall nat set [find comment="permanent-vpn1"] disabled=yes
or
/ip firewall nat disable [find comment="permanent-vpn1"]
msatter, another solution to your task would be introducing a separate custom chain for your dynamic rules, then jumping to this custom chain at the point where you currently insert your dynamic rules. In the script you then simply add your dynamic rules to the top of your custom chain not worrying about the rule order at all.
He’s dealing with a single rule and needs to remove/modify it. If it is harmless to have a jump to a custom chain which currently doesn’t exist, then yes, he can add the only rule to that chain and remove it from there. Is that what you had in mind? Because the rule order within the chain does matter if there would be more than one.
I did not wanted to post more on this 6.43RC3 thread and put updated information in my previous posting. I have multiple VPN connections active at the same which are on demand activated and disconnect when not being used.
The NAT lines have to be in specific part of the hairpin and the position of each line in the VPN block is not important because connection marking is filtering.
I use now static lines where the address changes depending on which VPN entry point is selected by the randomized DNS list (round robin). I can even use different vpn-providers and only a small percentage of websites do not like that you are coming from everywhere. PCC on the source-port determines which connection is used. Destination port and address-list controls if a site should only be visited from the same VPN.
I have now created a schedule on start-up which switches each static NAT VPN off after a two second delay so it symmetric to the activate script on-up of the VPN connection.
Like it is working now, pleases me. Thanks for all the help on this.