<html>
    <head>
      <base href="https://bugzilla.netfilter.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - using nfqueue breaks SCTP connection (tracking)"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1742#c1">Comment # 1</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - using nfqueue breaks SCTP connection (tracking)"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1742">bug 1742</a>
              from <span class="vcard"><a class="email" href="mailto:antonio.ojea.garcia@gmail.com" title="Antonio Ojea <antonio.ojea.garcia@gmail.com>"> <span class="fn">Antonio Ojea</span></a>
</span></b>
        <pre>

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 <a href="https://github.com/aojea/kube-netpol/issues/8#issuecomment-2039184720">https://github.com/aojea/kube-netpol/issues/8#issuecomment-2039184720</a>


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)</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>