pe1chl, holvoetn - WinBox dependencies are made when it is absolutely necessary. We are not doing this without any reason. Please report problems with WinBox 3.35 to > support@mikrotik.com > so we can fix them. Without knowing them, we can not fix them.
Do you really need a mail to support, incurring extra work for you, to know about problems? Would it not be easier to read the comments on the release topic, as you clearly are doing for the v7 rc releases? Especially when there is a new problem introduced in a winbox release, and everyone is writing about it in the release topic, I would expect that to be looked at at high priority as it is still a fresh change and likely easier to fix.
osc86, pe1chl - If you notice such problems, then please report them to us through the official support channel - > support@mikrotik.com> . Provide examples so we can fix them.
It is difficult to know what you mean by “such problems” when only the username is quoted and the user posted several messages in the topic. I regularly send issues to the Jira system, I suppose that is equivalent to mailing them to support.
Maybe in this case you are referring to “problems with importing a /export file”. I have posted several times here what is wrong with the import mechanism. I hope that once v7 is fixed to have feature completeness and bug counts equal to v6, someone at MikroTik can work on the whole mechanism of importing (both the /import command and the “run script after full reset” feature) which have serious issues that you should be well aware of. As it is now, it is really painful to transfer a config to another device or to rebuild a device after a netinstall (and not wanting to restore a backup).
About the whole “v7” thing…: well, you should be aware of the fact that some devices can only run v7. Also, v7 is presented prominently on the software download page as a stable release, which makes some people do the upgrade at a time they probably should not do that yet.
I surely understand that there is a lot of work to do, but I think many of us would prefer if all efforts are first concentrated on making v7 a worthy replacement of v6, where the same features work at the same quality level, and only then work is done on extending v7 with new features.
We are running a network operated by hobbyists and volunteers, which is heavily relying on BGP functionality, and I am holding my breath as more and more operators “discover” v7 and upgrade to it, causing frequent issues in the network. Sure it would have been better when we had a well functioning contact platform where I could send messages to all users requesting them not to upgrade, but we don’t have that. So I am hoping that BGP will “soon” be again on par with v6 quality.
Question on “kid-control” in 7.2r4! (Not sure I saw this in earlier R7 releases…)
Kid-control adds a very first forward rule into firewall in the forward chain, which jumps straight to the end of rules, to the individual kid-control device rules. They are the last ones in firewall.
But this jump rules seems to apply to ALL TRAFFIC! It is a generic rule and I could not find inside the rule any info why this would apply to the kid-control device only!
How does this rule know which device / interface to use and which not?
It seems the rules between the jump and the jump targets are still hit (counters increase), but I don’t understand why?
I don’t like in firewall things to happen which are not fully understood, especially as the jump target rules are last, there is no drop-all rule
anymore afterwards for forward traffic.
You should understand that the name “jump” is inappropriate (when you have a programming background), it really should have been named “call”.
I.e. it will execute the rules found in the chain kid-control, but when there is no rule that matches the traffic and has an action like “accept” or “drop”, when the end of the rule set is reached it will “return” to the place where the “jump” was done and continue there.
So it is more like a subroutine call than a jump (goto).
Each “chain” in the firewall is separate, the firewall is called at the “forward” (and “input” and “output”) chain but internally it can call other chains as subroutines.
The problem with the irregulary broken fiber connections with 10GB is still present in 7.2RC4.
I´ve updated yesterday all my MikroTik Devices from 6.48.6 over 6.49.4, 7.1.3 (via upgrade) to 7.2RC4. (RB5009, CRS326-24S+2Q+, CRS328-24P-4S+, RB4011, CRS32624G2S+, 5x CAP AC).
After the update the fiber connection between the CRS326-24S+2Q+ and the CRS328-24P-4S+ began to toggle. Every 5 min. the connection was broken. After deactivation of Graphing the disconnection happend ~ every 20-30 min.
This behaviour didn´t happen with ROS 6.48.6 or 6.49.4 and I only upgraded the ROS, nothing else.
Only the deactivation of “Auto Negotiation” and the fixing to 1GB stopped the diconnections to ~1x per day.
The cable between both devices is ~35m (2x)
The problem exists also with 7.0.5, the days where I´ve tried this ROS version I´ve also changed the cables without success. So the problem exists inside ROS 7.X
(https://help.mikrotik.com/servicedesk/servicedesk/customer/portal/1/SUP-71233)
You’re not the only one. Exact same issue here. My ticket is: SUP-68278 which was last updated by Mikrotik Dec. 23. I’ve posted in these threads about it before and been told to create a new support ticket… The same resolution (auto-negotiation off/1G fixed) “works” for me, but this is obviously not a fix.
Today I did some tests with L2TPv3 Ethernet: ROS 7.1.3 and ROS 7.2rc4
After creating an L2TP Ethernet it is not possible to deactivate it, if you try to deactivate it, it activates itself immediately.
L2TPv3 worked for a while but then it fails to establish the tunnel again.
When capturing the packets with Wireshark I have the message Digerst ( Expert Info (Warning/checksum): Incorrect Digest
Many thanks @Znevna for the CCR2216 details.
Would also be nice to have some numbers without l3hw, so that we would know what to expect from this device once hardware table is full (or if l3hw is intentionally disabled).
Same for CCR2116 of course. @MikroTik support ?
And for CCR2116 ipsec numbers, I think we’ll need @MikroTik support, to have their test procedure applied, to get a proper comparison to other models.
Thank you again !
@wispmikrotik: there is no need to quote text to be able to reply in this forum, you can just use the Quick Reply field or the Post Reply button at the bottom of the list.
