Chris Vine <chris@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > > 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.
Grrr. Right. This is because if you have single
-m recent --name DEFAULT ..
iptables-save > foo
then edit foo to bump the hitcount, then run
iptables-restore < foo
we'll find the existing DEFAULT entry with the old hitcount.
It works for something like 11 -> 13 since we're internally
tracking a count of 16 (mask 15).
I don't see a simple fix except your patch above plus
-static unsigned int ip_pkt_list_tot __read_mostly;
+static unsigned int ip_pkt_list_tot __read_mostly = 32;
To work around this.
This causes us to ignore hitcount in the check completely, at additional
memory cost.
I'll see if we can fix this in a better way.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
