Software Flow Offloading breaks the connections list in Luci's STATUS -> REALTIME GRAPHS -> CONNECTIONS?

Recently upgraded to gigabit ISP service, and my old router couldn't keep up with the speed. Enabled Software Flow Offloading, then things got a little better.

But it seems the list of currently active connections becomes all messed up in Status -> Realtime Graphs -> Connections. I sometimes use the list to eyeball if someone is trying to hack into my network, whether I have set up my VPN client correctly, stubby connection validation, and what not. So I know something about the list is seriously off.

I would like to know if either there is a fix to make the list work once again, or if I can put something else into the network to get a similar list... will something like pfsense help? (never used pfsense before and I assuming using pfsense would mean I get a device that runs pfsense then place it somewhere so it can sniff all traffic to/from gateway??).

Enabling flow offloading will introduce an [OFFLOAD] flag into the conntrack entries within /proc/net/nf_conntrack, maybe this is throwing off some parsing routine.

Could you describe the "all messed up" in more detail, or provide a screenshot?

For example, I have two OpenVPN clients in my LAN. Before switching on Software Flow Offloading the top two lines of the list would almost always be from these two OpenVPN clients to port 1194 of the external VPN servers. Top two because all of my devices in my network connect to the outside world through them, so they generate most of the traffic.

With Software Flow Offloading, these two lines are nowhere to be found.

Okay, so it's more about entries not being present and not some garbled output. Can you compare with cat /proc/net/nf_conntrack on the cli? Can you find the OpenVPN entries there?

You are right, not messed up as in totally garbled, but things that should be there aren't, and connections that I am sure don't actually exist appear.

Just checked /proc/net/nf_conntrack for the OpenVPN entries, yes it is there, and growing too in terms of bytes sent/received as I 'cat' the file repeatedly !

Allright, then the parser is tripping over some syntax elements, likely the [OFFLOAD] marker. Can you send me two or three affected lines for reference? I'll fix it up in LuCI then

... also I noticed there is an [OFFLOAD] in that line

Thanks so much.... here you go !

ipv4     2 tcp      6 src= dst= sport=52757 dport=443 packets=18 bytes=9003 src= dst= sport=443 dport=52757 packets=16 bytes=10057 [OFFLOAD] mark=0 zone=0 use=3
ipv4     2 tcp      6 src= dst= sport=56574 dport=443 packets=1055 bytes=71419 src= dst= sport=443 dport=56574 packets=747 bytes=78369 [OFFLOAD] mark=0 zone=0 use=3
ipv4     2 tcp      6 src= dst= sport=57650 dport=443 packets=898 bytes=52441 src= dst= sport=443 dport=57650 packets=614 bytes=83869 [OFFLOAD] mark=0 zone=0 use=3
ipv4     2 tcp      6 src= dst= sport=51951 dport=443 packets=72 bytes=10741 src= dst= sport=443 dport=51951 packets=74 bytes=18897 [OFFLOAD] mark=0 zone=0 use=3
ipv4     2 udp      17 src= dst= sport=59291 dport=4500 packets=280327 bytes=141978012 src= dst= sport=4500 dport=59291 packets=340395 bytes=193630560 [OFFLOAD] mark=0 zone=0 use=3
ipv4     2 tcp      6 src= dst= sport=52754 dport=443 packets=11 bytes=3058 src= dst= sport=443 dport=52754 packets=11 bytes=6031 [OFFLOAD] mark=0 zone=0 use=3
ipv4     2 udp      17 src= dst= sport=6971 dport=45557 packets=67 bytes=5064 src= dst= sport=45557 dport=6971 packets=5056 bytes=424704 [OFFLOAD] mark=0 zone=0 use=3
ipv4     2 udp      17 src= dst= sport=58409 dport=1194 packets=38808124 bytes=42935041285 src= dst= sport=1194 dport=58409 packets=45144540 bytes=44378418751 [OFFLOAD] mark=0 zone=0 use=3
ipv4     2 tcp      6 src= dst= sport=52752 dport=443 packets=12 bytes=3538 src= dst= sport=443 dport=52752 packets=12 bytes=6164 [OFFLOAD] mark=0 zone=0 use=3

1 Like

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