If I correctly understood, the problem seems to be that there are plenty connections that are not recognized by ROS (those with protocol=0), so these connection cannot be mangled
You almost got there!
Very close. That is what started the whole thing. Lets see if I can give you a better explanation about this thread, if kolorasta
Yes, looks like not recognized, indeed. But if you look at such a simple mangle rule that kolorasta
was using in his first post in this thread, not even a single entry in the connection tracking table could have (none)
in the connection mark field (looking via both winbox or telnet access alike). You can check it by adding the following mangle rules:
/ip firewall mangle
add chain=prerouting action=passthrough comment="" disabled=no
add chain=prerouting action=mark-connection new-connection-mark=everything passthrough=yes comment="" disabled=no
add chain=prerouting action=accept connection-mark=everything comment="" disabled=no
add chain=prerouting action=passthrough connection-mark=!everything comment="" disabled=no
Shouldnt the first and third rules count the same number of packets? I believe the packet flow facility need at least one single packet to know if there will exist a connection to track.
Then, cannot determine if there is a connection without at least one single packet. In the most cases, the router can simply receive and/or simply forward packets that does not belong to any of its own connections. Of course, there are something else that a simple device could do with packets, like traffic priorization and/or traffic filtering. Not talking about NAT, here comes the use of connection tracking I wish to do with MT ROS, a "stateful netfilter".
from the manual
The state of a particular connection could be estabilished meaning that the packet is part of already known connection, new meaning that the packet starts a new connection or belongs to a connection that has not seen packets in both directions yet, related meaning that the packet starts a new connection, but is associated with an existing connection, such as FTP data transfer or ICMP error message and, finally, invalid meaning that the packet does not belong to any known connection and, at the same time, does not open a valid new connection.
Meaning that if you find any different packets counting on both first and third rules, then I think that one of the following explanations must be true:
a) The difference exist because there are some kind of invalid packets opening a valid new connection. Then these packets count as a connection to mark, but just die somewhere else inside the ROS packet flow facility;
b) The difference exist because eventually valid packets keep its own pointer null after receive a mark. Then these packets count as a connection to mark, but simply does not keep any mark.
c) The difference exist because its just a presentation bug. The packet is there, the connections are marked and everything works in background.
I personally think that (a) and (c) are just sick. Well, I see wierd connection tracking things on versions below 2.9.48, including ten thousand times more entries than normal, protocol zero, timeouts equals to the ROS uptime counting clockwise and also entries as (none)
connection marks. I didnt fully tested all my setups on 2.9.48 yet, but seems that the crap has gone (or just...
hidden). Ah yes, ROS 3.0rc9 is even worse, seems nearly the same as 2.9.48, but its insane the variety of packets considered invalid (connection state invalid). There is a huge difference on what both 2.9.48 and rc9 state as invalid, why so? I need QoS, filtering, priorization and more. So, I need all this stuff running smoothly. Please.