<html>
    <head>
      <base href="https://bugzilla.netfilter.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Some filters randomly do not work since version 0.8"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1201">1201</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Some filters randomly do not work since version 0.8
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>nftables
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>x86_64
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Gentoo
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>major
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P5
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>nft
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>pablo@netfilter.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>sautier.louis@gmail.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Hello,
Since I upgraded to version 0.8, I have been experiencing weird behaviour with
some filters not matching. I think the issue is only present with filters for
tcp ports but this is just a guess.
Here is what my ip input filter chain looks like:
table ip filter {
        chain INPUT {
                type filter hook input priority 0; policy accept;
                ct state established,related accept
                iifname "eth0" tcp dport { 22, 80, 443 } counter accept
                iifname "lo" accept
                tcp dport 80 counter
                iifname "eth0" tcp dport 80 counter
                iifname "eth0" tcp dport { 80, 111 } counter
                iifname "eth0" tcp dport { 80, 111, 112, 113, 114, 115, 117 }
counter
                reject with tcp reset
                reject
        }
}
The rules with counters at the end are here for debugging purposes, they
shouldn't match a lot of traffic since ports 11* are unused and the third rule
should accept packets sent to port 80.

However, it seems that some rules tend not to match:
                iifname "eth0" tcp dport { 22, 80, 443 } counter packets 0
bytes 0 accept
                tcp dport 80 counter packets 264 bytes 15756
                iifname "eth0" tcp dport 80 counter packets 264 bytes 15756
                iifname "eth0" tcp dport { 80, 111 } counter packets 0 bytes 0
                iifname "eth0" tcp dport { 80, 111, 112, 113, 114, 115, 117 }
counter packets 0 bytes 0


If I reload the rules a few times, I'll sometimes see the expected behaviour:
                iifname "eth0" tcp dport { 22, 80, 443 } counter packets 31
bytes 1852 accept
                tcp dport 80 counter packets 0 bytes 0
                iifname "eth0" tcp dport 80 counter packets 0 bytes 0
                iifname "eth0" tcp dport { 80, 111 } counter packets 0 bytes 0
                iifname "eth0" tcp dport { 80, 111, 112, 113, 114, 115, 117 }
counter packets 0 bytes 0

Sometimes, the accept rule won't match but the { 80, 111 } one will:
                iifname "eth0" tcp dport { 22, 80, 443 } counter packets 0
bytes 0 accept
                tcp dport 80 counter packets 4 bytes 240
                iifname "eth0" tcp dport 80 counter packets 4 bytes 240
                iifname "eth0" tcp dport { 80, 111 } counter packets 4 bytes
240
                iifname "eth0" tcp dport { 80, 111, 112, 113, 114, 115, 117 }
counter packets 0 bytes 0


I am running Gentoo with kernel 4.13.12, I also had the issue with 4.13.11. I
could include my kernel config but I'm pretty sure the problem is with nftables
itself.
My nftables 0.8 is compiled with:
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--disable-dependency-tracking --disable-silent-rules
--docdir=/usr/share/doc/nftables-0.8-r3
--htmldir=/usr/share/doc/nftables-0.8-r3/html --libdir=/usr/lib64
--sbindir=/sbin --disable-pdf-doc --disable-debug --with-cli --without-mini_gmp

I am unable to reproduce the problem with version 0.7 compiled with these (the
same parameters as 0.8 except for docdir and htmldir):
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--disable-dependency-tracking --disable-silent-rules
--docdir=/usr/share/doc/nftables-0.7 --htmldir=/usr/share/doc/nftables-0.7/html
--libdir=/usr/lib64 --sbindir=/sbin --disable-pdf-doc --disable-debug
--with-cli --without-mini_gmp

I may try to run a bisect on this but if someone from the project could help
me, that would save me quite a bit of time.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>