[solved] /proc/net/nf_conntrack empty with 18.06.1

Hi:
I am trying install openwrt 18.06.1 at ubnt er-x device. the kernel version is 4.14. and I found that /porc/net/nf_conntrack is empy. and "conntrack -L" show nothing.

in old days if "nf_conntrack_ipv4" is loaded than there will be conntrack entry. I don't know what happened in kernel 4.14. do I need to look conntrack entries elsewhere or I miss something to enable the function?

Hi:
I found if I enable the firewall script, then there is /proc/net/nf_conntrack.
if I stop firewall script, then /proc/net/nf_conntrack is always empty.
so there is some magic behind the scene but I don't know what it is..
I tried to check the firewall script, and I found it call "fw3" to enable/disable the conntrack table.
I tried to compare "sysctl -a" before/after. but I still can not find what's the magic I need to learn.

Perhaps, I misunderstood; but this seems to be normal and expected behavior. If you disable the firewall, [connection tracking of] the firewall entries disappear.

This is not installed by default.

the conntrack table is flushed when firewall disabled. but I don't understand why there is no new entries anymore. it's not the behavior of lede 17,openwrt 15 or earlier versions. so I am curious what's the magic.

and "conntrack" is a normal utility, it can delete single conntrack entry.

This is correct.

Because you turned it off.

fw3 was created...and I do believe this occurred in 17. A developer that worked on it may be able to give more in-depth information (e.g. the commit that changed the behavior).

I never said it wasn't a normal utility, nor did I mention it's function, I only said:

If you need it, you should install it:

opkg update
opkg install conntrack

that's the point and the magic I want to learn. conntrack table is a kernel internal feature. once you load the conntrack module, it should be working. I don't know how to turn it off. and most important, how to turn it on?

sorry for the misunderstanding. what I mention is "conntrack -L" return no entry. I didn't mean the command is missing.

strace fw3 and I got nothing related. so I study the firewall rules and finally I find out the black magic, or black bugs.

with empty iptables rules, command like below:

"echo f > /proc/net/nf_conntrack; ping -c 1 127.0.0.1 ; cat /proc/net/nf_conntrack"

you got no conntrack entries.

now add some iptables rule:

"iptables -t raw -A OUTPUT -d 1.2.3.4 -j CT"

bingo! now "ping -c 1 127.0.0.1 ; cat /proc/net/nf_conntrack" will bring you conntrack entries, although the added rule is not related to the traffic.

rules like "iptables -t nat -A PREROUTING -j DNAT" or "iptables -t nat -A POSTROUTING -J SNAT" will also bring back conntrack entries. but rules like "-j ACCEPT" will not bring anything.

it looks like a bug to me, not a feature..

1 Like

Glad you got it well enough figured out!

At least for me, I'd argue that it's a feature that conntrack doesn't do anything by default if I'm not either implicitly enabling it with firewall rules that require connection tracking (some firewalls are purely static), or through some sysctl or other control. If I don't need it, why should it be chewing up CPU cycles and slowing down my machine? (Think dedicated web servers, for example)

in old days, if you don't need to track something, you can use NOTRACK target to bypass the tracking.
if it is a feature, it should have some sysctl parameters I think. and if you don't need tracking at all, you just don't load the conntrack kernel modules, which is the default for normal distributions like debian or rhel.

as you said, the conntrack is enabled by rules that required tracking. even if the rule is not related to the real traffic. it is strange to me.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.