<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#c3">Comment # 3</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:pablo@netfilter.org" title="Pablo Neira Ayuso <pablo@netfilter.org>"> <span class="fn">Pablo Neira Ayuso</span></a>

</span></b>

        <pre>(In reply to Pablo Neira Ayuso from <a href="show_bug.cgi?id=1742#c2">comment #2</a>)

<span class="quote">> (In reply to Antonio Ojea from <a href="show_bug.cgi?id=1742#c1">comment #1</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)</span >

Workaround makes sense, because branch depends on NFQA_CFG_F_GSO flag:

        case NFQNL_COPY_PACKET:

                if (!(queue->flags & NFQA_CFG_F_GSO) &&

                    entskb->ip_summed == CHECKSUM_PARTIAL &&

                    skb_checksum_help(entskb))

                        return NULL;

if set on, the checksum calculation is skipped.

For filtering (only dropping), enabling NFQA_CFG_F_GSO makes perfect sense

(unless your heuristic is based on the real packet as seen in the wire, that

is, GRO does not interference with the filtering criteria)</pre>

        </div>

      </p>

      <hr>

      <span>You are receiving this mail because:</span>

      <ul>

          <li>You are watching all bug changes.</li>

      </ul>

    </body>

</html>