From: Chris Vine <chris@cvine.freeserve.co.uk>
To: netfilter-devel@vger.kernel.org
Subject: Re: xt_recent fails with kernel 3.19.0
Date: Thu, 12 Feb 2015 11:09:31 +0000 [thread overview]
Message-ID: <20150212110931.6db17d7c@bother.homenet> (raw)
In-Reply-To: <20150212105145.5e0177c0@bother.homenet>
On Thu, 12 Feb 2015 10:51:45 +0000
Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> On Thu, 12 Feb 2015 10:25:53 +0000
> Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> > Loading 'recent' xtables match support for iptables fails where the
> > following sample rule is appended with SSH_TRIES set to 4:
> >
> > iptables -A SSH_CHAIN -m conntrack --ctstate NEW \
> > -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount
> > $SSH_TRIES -j DROP
> >
> > It fails with this message:
> >
> > kernel: xt_recent: hitcount (4) is larger than packets to be
> > remembered (4) for table DEFAULT
> >
> > This appears to be due to an off-by-one error in testing the hit
> > count in recent_mt_check(). This occurs because nstamp_mask is set
> > to one less than the value of ip_pkt_list_tot (if any) or of
> > hit_count rounded up to a power of two value. When that hit count
> > boundary is actually reached nstamp_mask is therefore exceeded by
> > one.
> >
> > I can't say I fully understand the heuristics of nstamp_mask, but
> > the patch below deals with this and works for me(TM).
> >
> > Signed-of-by: Chris Vine <vine.chris@gmail.com>
> >
> > --- linux-3.19.0/net/netfilter/xt_recent.c~ 2015-02-10
> > 09:18:44.657376355 +0000 +++
> > linux-3.19.0/net/netfilter/xt_recent.c 2015-02-11
> > 17:58:33.311608835 +0000 @@ -378,7 +378,7 @@
> > mutex_lock(&recent_mutex); t = recent_table_lookup(recent_net,
> > info->name); if (t != NULL) {
> > - if (info->hit_count > t->nstamps_max_mask) {
> > + if (info->hit_count > t->nstamps_max_mask + 1) {
> > pr_info("hitcount (%u) is larger than
> > packets to be remembered (%u) for table %s\n", info->hit_count,
> > t->nstamps_max_mask + 1, info->name);
>
> Scrub that. This now fails when SSH_TRIES is set to other than a
> power of two boundary. There seems to be something fundamentally
> wrong with the heuristic employed here.
On more testing I am wrong about that. You seem to need to rmmod
xt_recent to get it to flush the previous setting. With that done, the
patch does indeed seem to work with any values of SSH_TRIES.
Chris
next prev parent reply other threads:[~2015-02-12 11:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 10:25 xt_recent fails with kernel 3.19.0 Chris Vine
2015-02-12 10:51 ` Chris Vine
2015-02-12 11:09 ` Chris Vine [this message]
2015-02-12 11:36 ` Florian Westphal
2015-02-12 11:52 ` Florian Westphal
2015-02-12 17:04 ` Chris Vine
2015-02-12 17:09 ` Florian Westphal
2015-02-12 21:34 ` Chris Vine
2015-02-12 21:40 ` Florian Westphal
2015-02-12 21:57 ` Chris Vine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150212110931.6db17d7c@bother.homenet \
--to=chris@cvine.freeserve.co.uk \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).