Hi,

Quite some time ago I have found very strange firewall behavior (at least in my case), which I believe could potentially be a bug in the system. I have described it also in forum topic (you can find it here: viewtopic.php?t=205171), but I was not expecting users trying to reproduce this behavior on running systems for obvious reasons.

So, I have opened bug report in Mikrotik support system hoping that developers and testers could easily check described behavior and see if it can be reproduced. I have described all step by step, I have added some extra information that could help them, but I have never got any reply. I have created bug report 4th of March, so in two weeks it will be 3 months without reply.

I could understand that reaction to bug report, reported by home router consumers could take longer time to react, but surely not 3 months. I was expecting at least get the reason why this report is not investigated. But nothing. Then I thought that this ticket might be lost somehow in the system, so I have sent an email to support@mikrotik.com nearly two months ago. I've got no reply to that either.

I have actually created another support request around same time, and that was solved in no time and very professionally. I'm now wondering what could be wrong with my bug report.

It would be interesting to hear what is other users experience with this. Have you ever had that you got no reply to support request and no explanation why?

Regards,

I asked if you could state what the traffic flow requirements were for this bug, what user traffic was affected.
You failed to answer.

So I suspect that this falls into the category of not knowing how to config the router and not a bug and that is why MT didnt respond.
They should probably change their feedback process. by making such conclusions clear, vice simply closing reports.

Hi anav,

To be very honest, I did not understand your question back then in the forum.

But to be super honest, I was just experimenting with dsr-addr-type and src-add-type and then I have noticed that strange behavior. I have stated, what I believe, very clearly how to reproduce it and in which chain that should be done. Rules as such are useless and have no meaning, but they clearly shows system behavior. They are not related to any traffic or real life environment. I though that this behavior might impact some other area, should the same behavior also be discovered by Mikrotik.

I have been dealing with Mikrotik since 2005 I believe, it is very professional company and I do not believe they will just not answer because my request is missing info. They would reply and ask for extra information, or at least tell me "sorry, that does not make any sense, we close your request". Not replying means some other reason. At least I believe so.

This is why I created this post just to hear other users experience. If that is normal or I'm missing something here.

Regards,

When you have an actual use case for traffic flow and the functionality does not work, I would be interested.
In other words, where in a bonafide user requirement config, is dst-address-type=local or dst-address-type=!local NOT WORKING.
Without context, its meaningless.
However just messing around is not a reason for me to look at it, and I suspect, MT support quickly determined it was nonsensical.

Seems like be a potentially funny YouTube video, "How Mikrotik deals with support cases".

Hi anav,

It was not about actual rules or traffic. It was more about how operating system of Mikrotik deals with removing rule conditions.
makes packet maching counter to stop. Which is correct. But when you remove from the rule (returning to initial rule), counter still does not work. In order to make it work again, you first need to set which makes counter match packets again as in initial rule, and only then you can remove src-address-type completely.

That is suspicious behavior and could be potential bug. Why removing completely does not return rule to initial state? Why you need first to set before removing it completely? That does not make sense. And that has nothing to do with users, flow, traffic and real life environment. It just shows how strange 7.x ROS behaves. It is even more suspicious when 6.x ROS does not have this issue.

I do not see why it should sound strange that I ask Mikrotik to test this behavior and see if it is the way it should be.

Regards,

Okay I understand, sounds more like incomplete programming then a bug, but very low on the priority list of things they need to do........

It was more about how operating system of Mikrotik deals with removing rule conditions.

Code: Select all

dst-address-type=local AND src-address-type=local

makes packet maching counter to stop. Which is correct. But when you remove

Code: Select all

src-address-type=local

from the rule (returning to initial rule), counter still does not work. In order to make it work again, you first need to set

Code: Select all

src-address-type=””

which makes counter match packets again as in initial rule, and only then you can remove src-address-type completely.

The quick answer is you're using the wrong syntax to clear them. Either using set with the "!" before attribute name, or the "unset" operations to actually remove it as part of the filter match.
Those are an "array" type in RouterOS script & there is a difference between an empty list (here, src-address-type="", or a [:toarray ""] operation elsewhere). So with the "" (empty list), you actually saying match src-address-type that has NONE of those known value. And so "" that's different than just not having src-address-type AT ALL in the filter/mangle rule.

Basically any attribute that appears in the config when export the firewall is part of the matcher used for packets. so x-attriute-name="" is says match something of length 0. That not same as "don't match" on the field.

Hi Amm0,

Well, I have used script code in the example, but in reality I use Winbox. Same issue here. The problem is that I need to do wrong in order to put back rule in original state. If I just remove from the rule, it does not come back to original state, hence it does not match packets as original rule. So, in order to put back rule into original state I must first set it incorrectly src-address-type=”” and then remove src-address-type=”” completely. Only then rule works again as in original state.

It is just an example, that brings me some thoughts and questions:

1. Is it only address-type that has this behavior?
2. Is it only local type that has this issue?
3. How to find out now rules where I have had address type enabled before and then I changed rule by removing address-type? With this issue, it won't actually be removed and address-type still be in the rule even though it is not visible.

Okay I understand, sounds more like incomplete programming then a bug, but very low on the priority list of things they need to do........

Yes, but it would be super nice to get reply within 3 months stating that it is low priority and we will get back as soon as possible

Seems what Ammo is saying is that once you put a condition on, to remove it, you need specific commands to reverse the condition. Your expectation of how to undo the command is not realistic and when it doesnt work you found a work around to get it to where you want to be. In other words use the work around or do it the proper way.

In routeros there is a difference been "not set" and being set to "empty" & that's how it work. In winbox you can use the black arrow on the right clear to clear it the like "unset" does at CLI.

So if you have it set, there are "few arrows" on the right of controls.... You can see the difference between empty list state (i.e. src-address-type="") here... And it actually being unset here...

What I'm trying to say is the intervening step may not be useful for much, but it is a state (i.e. match if "none of the choices").

1. Is it only address-type that has this behavior?
2. Is it only local type that has this issue?

The dst/src-address-type is NOT a common pattern in RouterOS. i.e. "a list, with a not, that's accept empty". Specifically on the *-address-type=... It comes from Linux *tables for firewall, and the Linux CLI uses a "!" operator - which is even weirder for a Linux CLI if you ask me.

3. How to find out now rules where I have had address type enabled before and then I changed rule by removing address-type? With this issue, it won't actually be removed and address-type still be in the rule even though it is not visible.

I'm not sure of your question. Do you want to find place where it's set to empty? i.e. /firewall/filter/print where src-address-type=""?

I guess I'm saying the UI for could be improved, but winbox shows it's an "empty", and in CLI if the variable appears in export it's set. Perhaps usability could be improved, but that's true everywhere in RouterOS... So I guess I'm not sure why your insisting there a problem here.

Hi,

100% agree, but the problem is that I might have changed this way some rules before I discovered this issue. Now I have no clue what rules I have that does not work as I expect, even though they look correct.

I'm not sure of your question. Do you want to find place where it's set to empty? i.e. /firewall/filter/print where src-address-type=""?

Yes and no. I used to remove src-address-type not by setting it to empty, but by completely removing src-address-type option without setting it to "" before completely removing it. This is why I will never find rules where I removed option src-address-type without setting it to "" first. And that means, based on my experience, that src-addres-type option stays there or at least somehow impacts packet matcher.

Also, please remember that this issue is not existing in ROS v.6.x.x. It means that I'm not inventing problems They are there is ROS v7.x

I have made short video, please check attached. The rule you see in the video is rule number 1 in input chain and I'm sending constant ping to the router. As you can see, I can't just fully remove src-address-type option. I first need to set it to "" and only then remove it completely. When you look at the rule, it seems that it should not match src-address-type anymore, but for some reason it does, because src-address-type option was removed in the way that ROS v7.x does not like. This is what does not make sense to me and this is what works without any issues on ROS v6.x.

Update:
Just want to clarify, that my issue is not workarounds, extra actions I need to do or that src-address-type is rarely used. Real issue here is that operating system allows us to end up in the situation where visual rule description does not correspond to what actually rule does. Just look at the video. Rule that is in the very beginning of video and rule that is shown at 0:30 are the same rules visually (looks the same when you use /print command), but the latter one does not match packets while it actually should. That is the biggest issue here and that is why I was expecting support to somehow react to this.

Regards,