You will need to compile a build for your device with kernel 4.14, the module required for flow offload and iptable rule to use said module.
What kind of rule would you use if you want to offload all traffic?
Add a rule to the FORWARD chain with: "-j FLOWOFFLOAD"
1 Like
Which of the following 3 modules are required? And am I missing any?
kmod-ipt-offload
kmod-nf-flow
kmod-nft-offloadSo.... the 2nd rule in the FORWARD chain? Nope.
Thanks, and so she be where some may look:
iptables -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD
Nope: for me it keeps resetting an established connection; my irc client. I will check my image contents again.
With image from config.seed, running on rango target, my irc client(irssi on an ubuntu box) continually resets its connection every few minutes upon installing FLOWOFFLOAD.
Should maybe add that the irc connection is a secure connection.
The latest series of patches addressed this issue, things appear to be working.
The issues should be fixed now. Please try the latest version
iptables -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD
This command messes up w/ NAT Loopback. If I delete it, NAT loopback works again.
What do you mean by "NAT loopback"? Also, please try my staging tree at https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary to see if it fixes those issues.
Hi,
I mean the port forwarding with reflection a.k.a. hairpin NAT. I have a few services that I access using the external IP and it doesn't work with the FLOWOFFLOAD as the first rule in the FORWARD chain.
Still happens on the latest staging build.
Should be fixed now. Please try the latest version
1 Like
Fri Mar 30 09:58:45 2018 kern.warn kernel: [ 178.954091] dst_release: dst:87c41cb8 refcnt:-2035027009
Fri Mar 30 09:58:53 2018 kern.warn kernel: [ 186.999691] dst_release: dst:87c09e00 refcnt:-2026352449
Fri Mar 30 09:58:54 2018 kern.warn kernel: [ 187.995490] dst_release: dst:87c41cb8 refcnt:-2039040705
Fri Mar 30 09:58:54 2018 kern.warn kernel: [ 188.001052] dst_release: dst:87c41cb8 refcnt:-2039040706
Fri Mar 30 09:58:55 2018 kern.warn kernel: [ 188.996663] dst_release: dst:87c41cb8 refcnt:-1
I have log full of this if i enable flowoffload. Xiaomi mini, ramips, mt7620a. Should i fill bugreport or send you email?
Hi,
My device is turris omnia with latest openwrt compiled by myself,and these days when i turn on the "Flow offload",my omnia always got a crash and then reboot itself.
The crash log:
Mar 31 21:58:06 192.168.1.1 pppd[28332]: Connect: pppoe-wan2 <--> lan4
Mar 31 21:58:06 192.168.1.1 kernel: [63771.886868] Unable to handle kernel paging request at virtual address 48000082
Mar 31 21:58:06 192.168.1.1 kernel: [63771.894117] pgd = c0004000
Mar 31 21:58:06 192.168.1.1 kernel: [63771.896850] [48000082] *pgd=00000000
Mar 31 21:58:06 192.168.1.1 kernel: [63771.900441] Internal error: Oops: 5 [#1] SMP ARM
Mar 31 21:58:06 192.168.1.1 kernel: [63771.905072] Modules linked in: ath9k ath9k_common pppoe ppp_async ath9k_hw ath10k_pci ath10k_core ath pppox ppp_mppe ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_u32 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CLASSIFY wireguard usblp slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_netlink macvlan iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat sch_cake act_connmark nf_conntrack act_skbedit
Mar 31 21:58:06 192.168.1.1 kernel: [63771.976644] act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress cryptodev xt_set ip_set_list_set ip_set_hash_netiface ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables ip_gre gre ifb ip6_udp_tunnel udp_tunnel sit tunnel4 ip_tunnel tun ntfs autofs4 nls_utf8 nls_cp950 nls_cp936 sha512_generic sha256_generic md5 ecb authenc vfat fat nls_iso8859_1 nls_cp437 gpio_button_hotplug
Mar 31 21:58:06 192.168.1.1 kernel: [63772.041851] CPU: 1 PID: 9040 Comm: kworker/1:3 Not tainted 4.14.29 #0
Mar 31 21:58:06 192.168.1.1 kernel: [63772.048310] Hardware name: Marvell Armada 380/385 (Device Tree)
Mar 31 21:58:06 192.168.1.1 kernel: [63772.054261] Workqueue: events_power_efficient xt_flowoffload_hook_work [xt_FLOWOFFLOAD]
Mar 31 21:58:06 192.168.1.1 kernel: [63772.062291] task: eea35500 task.stack: e91a6000
Mar 31 21:58:06 192.168.1.1 kernel: [63772.066845] PC is at __nf_unregister_net_hook+0x8/0xcc
Mar 31 21:58:06 192.168.1.1 kernel: [63772.072001] LR is at nf_unregister_net_hook+0x9c/0xc0
Mar 31 21:58:06 192.168.1.1 kernel: [63772.077068] pc : [<c0555734>] lr : [<c0555894>] psr: 20000013
Mar 31 21:58:06 192.168.1.1 kernel: [63772.083353] sp : e91a7f00 ip : 00000000 fp : eefdfc00
Mar 31 21:58:06 192.168.1.1 kernel: [63772.088594] r10: 00000008 r9 : 00000000 r8 : 00000100
Mar 31 21:58:06 192.168.1.1 kernel: [63772.093836] r7 : 00000200 r6 : c0a29400 r5 : e9cdd1c8 r4 : ea63ba30
Mar 31 21:58:06 192.168.1.1 kernel: [63772.100384] r3 : 00000000 r2 : 00000000 r1 : e9cdd1c8 r0 : 48000082
Mar 31 21:58:06 192.168.1.1 kernel: [63772.106931] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Mar 31 21:58:06 192.168.1.1 kernel: [63772.114089] Control: 10c5387d Table: 2bbb004a DAC: 00000051
Mar 31 21:58:06 192.168.1.1 kernel: [63772.119849] Process kworker/1:3 (pid: 9040, stack limit = 0xe91a6210)
Mar 31 21:58:06 192.168.1.1 kernel: [63772.126303] Stack: (0xe91a7f00 to 0xe91a8000)
Mar 31 21:58:06 192.168.1.1 kernel: [63772.130671] 7f00: ea63ba30 c0555894 e9cdd1c0 bf3ba200 bf3ba200 bf3b8398 00000000 01699000
Mar 31 21:58:06 192.168.1.1 kernel: [63772.138868] 7f20: bf3ba2a0 ebba2f80 eefdfc00 eefe2f00 00000000 c01377c4 eefdfc18 ffffe000
Mar 31 21:58:06 192.168.1.1 kernel: [63772.147066] 7f40: ebba2f80 eefdfc00 ebba2f98 eefdfc18 ffffe000 c0a02d00 00000008 c0138760
Mar 31 21:58:06 192.168.1.1 kernel: [63772.155263] 7f60: eea35500 eca5cc00 e91a6000 ea76ab00 00000000 eca5cc1c ebba2f80 c0138430
Mar 31 21:58:06 192.168.1.1 kernel: [63772.163460] 7f80: ea7fbed8 c013ccac e91a6000 ea76ab00 c013cb80 00000000 00000000 00000000
Mar 31 21:58:06 192.168.1.1 kernel: [63772.171656] 7fa0: 00000000 00000000 00000000 c0107a68 00000000 00000000 00000000 00000000
Mar 31 21:58:06 192.168.1.1 kernel: [63772.179852] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Mar 31 21:58:06 192.168.1.1 kernel: [63772.188047] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
Mar 31 21:58:06 192.168.1.1 kernel: [63772.196257] [<c0555734>] (__nf_unregister_net_hook) from [<bf3ba200>] (cleanup_module+0x1c74/0xa74 [xt_FLOWOFFLOAD])
Mar 31 21:58:06 192.168.1.1 kernel: [63772.206807] Code: e28dd00c e8bd8ff0 e92d4010 e3a03000 (e1d0c0b0)
Mar 31 21:58:06 192.168.1.1 kernel: [63772.212933] ---[ end trace 7c38ec001676f581 ]---
Is there anyway to fix this? thanks.
Please try the latest version
I tried it on wrt3200acm and remote desktop is working very bad.
The download and upload where ok (pppoe 980/496), cpu usage was ~2x35%
I don't need this for the wrt but I was just testing to see how it's working
regards
What kind of issue are you having with remote desktop?
sorry for being late on reply
if I do remote desktop without offload, the feeling is smooth, the scrolling in browsing, alt tab, etc is like being in front of the remote computer.
with offload enabled on router (firewall restart, remote desktop reconnect) it jumps and it feels like a really bad lag, like 2-3 seconds, very bad experience, like being on a modem
the bandwidth between routers are like 500mbit up/down, but I test it on a wireless n laptop so, maximum 100+mbit
edit:
OpenWrt SNAPSHOT, r6614-1ef0be3e5b
root@home:~# cat /proc/net/nf_conntrack | grep OFFLOAD
ipv6 10 tcp 6 src=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 dst=xxxx:xxx:xxxx:xxxx:0000:0000:168b:9001 sport=55444 dport=443 packets=2 bytes=132 src=xxxx:xxx:xxxx:xxxx:0000:0000:168b:9001 dst=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 sport=443 dport=55444 packets=1 bytes=72 [OFFLOAD] mark=0 use=3
ipv4 2 tcp 6 src=xxx.xxx.34.124 dst=xxx.xxx.103.95 sport=57782 dport=26000 packets=2 bytes=92 src=192.168.123.118 dst=xxx.xxx.34.124 sport=3389 dport=57782 packets=1 bytes=52 [OFFLOAD] mark=0 use=3
ipv4 2 tcp 6 src=192.168.123.118 dst=151.101.12.133 sport=55430 dport=443 packets=4 bytes=174 src=151.101.12.133 dst=xxx.xxx.103.95 sport=443 dport=55430 packets=1 bytes=52 [OFFLOAD] mark=0 use=3
ipv6 10 tcp 6 src=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 dst=xxxx:xxx:xxxx:xxxx:0000:0000:168b:9001 sport=55438 dport=443 packets=2 bytes=132 src=xxxx:xxx:xxxx:xxxx:0000:0000:168b:9001 dst=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 sport=443 dport=55438 packets=1 bytes=72 [OFFLOAD] mark=0 use=3
ipv4 2 tcp 6 src=192.168.123.118 dst=xxx.xxx.226.250 sport=55448 dport=443 packets=2 bytes=92 src=xxx.xxx.226.250 dst=xxx.xxx.103.95 sport=443 dport=55448 packets=1 bytes=52 [OFFLOAD] mark=0 use=3
ipv6 10 udp 17 src=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 dst=2a00:1450:400d:0807:0000:0000:0000:200e sport=61439 dport=443 packets=2 bytes=2796 src=2a00:1450:400d:0807:0000:0000:0000:200e dst=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 sport=443 dport=61439 packets=1 bytes=86 [OFFLOAD] mark=0 use=3
ipv6 10 tcp 6 src=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 dst=2a00:1450:4014:080c:0000:0000:0000:200a sport=55409 dport=443 packets=6 bytes=376 src=2a00:1450:4014:080c:0000:0000:0000:200a dst=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 sport=443 dport=55409 packets=1 bytes=72 [OFFLOAD] mark=0 use=3
ipv4 2 tcp 6 src=192.168.123.118 dst=xxx.xxx.226.250 sport=55449 dport=443 packets=2 bytes=92 src=xxx.xxx.226.250 dst=xxx.xxx.103.95 sport=443 dport=55449 packets=1 bytes=52 [OFFLOAD] mark=0 use=3
ipv4 2 tcp 6 src=192.168.123.118 dst=151.101.12.133 sport=55431 dport=443 packets=4 bytes=174 src=151.101.12.133 dst=xxx.xxx.103.95 sport=443 dport=55431 packets=1 bytes=52 [OFFLOAD] mark=0 use=3
ipv6 10 tcp 6 src=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 dst=2a00:1450:400c:0c09:0000:0000:0000:00bc sport=55349 dport=443 packets=15 bytes=925 src=2a00:1450:400c:0c09:0000:0000:0000:00bc dst=xxxx:xxx:xxxx:004d:40fa:4f48:0bff:7646 sport=443 dport=55349 packets=1 bytes=72 [OFFLOAD] mark=0 use=3
ipv4 2 tcp 6 src=192.168.123.118 dst=xxx.xxx.197.42 sport=55314 dport=443 packets=2 bytes=92 src=xxx.xxx.197.42 dst=xxx.xxx.103.95 sport=443 dport=55314 packets=1 bytes=52 [OFFLOAD] mark=0 use=3
Regards
@nbd There was a discussion about this in another topic, but I wanted to ask you. Is there any chance you will backport sw flow offload to kernel 4.9? I am interested in ar71xx platform. Those week SoCs would benefit a lot from this feature but upgrading the kernel for that platform to 4.14 seems like a lot of work.
Backporting flow offload is also a lot of work - I don't think it will happen.
The new ath79 target (ar71xx with 4.14, but based on device tree instead of mach files) is actually making progress now, and I think flow offload provides a nice incentive to work on more board support for it...
3 Likes