[Bug 1742] using nfqueue breaks SCTP connection (tracking)

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1742

--- Comment #1 from Antonio Ojea <antonio.ojea.garcia at gmail.com> ---


I´ve used this great tool from the cilium project (pwru) to trace the packet
and I can observe that if I don´t use nfqueue I got this trace

0xffff88810983aa00      0 [<empty>(280243)]               ip_forward
netns=4026533169 mark=0x0 iface=168(eth0) proto=0x0800 mtu=1500 len=84
192.168.8.2:0->10.244.2.47:0()
0xffff88810983aa00      0 [<empty>(280243)]             nf_hook_slow
netns=4026533169 mark=0x0 iface=168(eth0) proto=0x0800 mtu=1500 len=84
192.168.8.2:0->10.244.2.47:0()
0xffff88810983aa00      0 [<empty>(280243)]        ip_forward_finish
netns=4026533169 mark=0x0 iface=168(eth0) proto=0x0800 mtu=1500 len=84
192.168.8.2:0->10.244.2.47:0()

and when using it there are some functions that operate on the sctp checksum

0xffff88810749bf00     29 [<empty>(274286)]               ip_forward
netns=4026532933 mark=0x0 iface=47 proto=0x0800 mtu=1500 len=68
10.244.1.47:0->10.244.2.47:0()
0xffff88810749bf00     29 [<empty>(274286)]             nf_hook_slow
netns=4026532933 mark=0x0 iface=47 proto=0x0800 mtu=1500 len=68
10.244.1.47:0->10.244.2.47:0()
0xffff88810749bf00     29 [<empty>(274286)]                 nf_queue
netns=4026532933 mark=0x0 iface=47 proto=0x0800 mtu=1500 len=68
10.244.1.47:0->10.244.2.47:0()
0xffff88810749bf00     29 [<empty>(274286)]               __nf_queue
netns=4026532933 mark=0x0 iface=47 proto=0x0800 mtu=1500 len=68
10.244.1.47:0->10.244.2.47:0()
0xffff88810749bf00     29 [<empty>(274286)]        skb_checksum_help
netns=4026532933 mark=0x0 iface=47 proto=0x0800 mtu=1500 len=68
10.244.1.47:0->10.244.2.47:0()
0xffff88810749bf00     29 [<empty>(274286)]      skb_ensure_writable
netns=4026532933 mark=0x0 iface=47 proto=0x0800 mtu=1500 len=68
10.244.1.47:0->10.244.2.47:0()
0xffff88810749bf00     26 [<empty>(3319058)]               nf_reroute
netns=4026532933 mark=0x0 iface=47 proto=0x0800 mtu=1500 len=68
10.244.1.47:0->10.244.2.47:0()
0xffff88810749bf00     26 [<empty>(3319058)]        ip_forward_finish
netns=4026532933 mark=0x0 iface=47 proto=0x0800 mtu=1500 len=68
10.244.1.47:0->10.244.2.47:0()


The packet captures confirms that when using nfqueue some packet modification
happens https://github.com/aojea/kube-netpol/issues/8#issuecomment-2039184720


As a workaround, if I set the flag NFQA_CFG_F_GSO then the packet is not
modified and connection works perfectly (I´m only using nfqueue for dropping)

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240407/08ac02d7/attachment.html>