In which chain does the TTL decrement happen? Pre, fwd, or post?
Also, I found it odd that when setting up a mangle rule to change TTL, that I had matches on both forward and postrouting chains. I had passthrough disabled on both of them. I have fasttrack and fast path both disabled. Why is my single test stream matching some of both rules, and not identical? Also, it seems that not all bytes are being accounted for, but only a fraction.
Thanks in advance!
Edit: I’m seeing significant “untracked” traffic with the default fasttrack counter rule in firewall, even though fasttrack rule is disabled. There are no rules in Raw except the default dummy rule to count fasttrack.
So to answer with words, the TTL decrement is just after the routing decision, but before the mangle forward chain, that’s why you had matches on both forward and postrouting chains, because the postrouting chain is after the forward chain.
I still am confused about the untracked traffic though. Why would I have so much if fasttrack is disabled?
Also, I think I figured out why the postrouting chain wasn’t catching as much traffic as I expected. I was largely testing one direction but the rule was for the opposite direction. It was late. I’ll retest today with traffic going in the same direction as the rule.
Fasttrack should not affect the logic of connection tracking (and fasttracked traffic is not considered untracked). The amount of untracked traffic depends largely on traffic itself (can router classify it into connections?) and firewall rules …
Ah, didn’t realized untracked traffic wasn’t the same as !fasttracked traffic.
In this case, untracked simply means it’s a new flow that hasn’t been added to the conntrack state table yet, or a flow that isn’t able to be tracked.
I wonder if anyone has a way to sniff the TTL on a RB? It doesn’t seem to show in Torch. If not, I’ll just have to use a mirror port and send it to Wireshark.
