netfilter buglog - Dec 2013 - [Bug 880] New: ipset doesn't refresh the timeout for an existing entry when the table is FULL.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

           Summary: ipset doesn't refresh the timeout for an existing
                    entry when the table is FULL.
           Product: ipset
           Version: unspecified
          Platform: x86_64
        OS/Version: Fedora
            Status: NEW
          Severity: normal
          Priority: P5
         Component: default
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: xose.vazquez at gmail.com
   Estimated Hours: 0.0


ipset doesn't refresh timeout for an existing entry when the table is FULL.


- Version-Release number of selected component:

kernel: 3.11.10-200.fc19.x86_64
ipset: v6.20.1


- Steps to Reproduce:

# ipset create http hash:ip timeout 0 maxelem 5
# ipset add http 192.168.0.1
# ipset add http 192.168.0.2
# ipset add http 192.168.0.3
# ipset add http 192.168.0.4
# ipset list
Name: http
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 5 timeout 0
Size in memory: 16784
References: 0
Members:
192.168.0.3 timeout 0
192.168.0.4 timeout 0
192.168.0.1 timeout 0
192.168.0.2 timeout 0
# ipset add http 192.168.0.5 -exist timeout 60
(wait)# ipset list
Name: http
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 5 timeout 0
Size in memory: 16848
References: 0
Members:
192.168.0.3 timeout 0
192.168.0.4 timeout 0
192.168.0.5 timeout 41
192.168.0.1 timeout 0
192.168.0.2 timeout 0
# ipset add http 192.168.0.5 -exist timeout 60
ipset v6.20.1: Hash is full, cannot add more elements
# ipset list
Name: http
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 5 timeout 0
Size in memory: 16848
References: 0
Members:
192.168.0.3 timeout 0
192.168.0.4 timeout 0
192.168.0.5 timeout 21  <<<<---- It should be 60.
192.168.0.1 timeout 0
192.168.0.2 timeout 0


It works flawlessly when the tables is not full.

# ipset del http 192.168.0.4
# ipset add http 192.168.0.5 -exist timeout 60
(wait)# ipset list
Name: http
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 5 timeout 0
Size in memory: 16848
References: 0
Members:
192.168.0.3 timeout 0
192.168.0.5 timeout 38
192.168.0.1 timeout 0
192.168.0.2 timeout 0
# ipset add http 192.168.0.5 -exist timeout 60
# ipset list
Name: http
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 5 timeout 0
Size in memory: 16848
References: 0
Members:
192.168.0.3 timeout 0
192.168.0.5 timeout 59    <<<<<----- OK
192.168.0.1 timeout 0
192.168.0.2 timeout 0

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

Mathieu Bridon <bochecha at fedoraproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bochecha at fedoraproject.org

--- Comment #1 from Mathieu Bridon <bochecha at fedoraproject.org>
2013-12-04 15:49:15 CET ---
I can reproduce this as well:
kernel-3.11.9-300.fc20.x86_64
ipset-6.20.1-1.fc20.x86_64

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

Jozsef Kadlecsik <kadlec at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |kadlec at netfilter.org

--- Comment #2 from Jozsef Kadlecsik <kadlec at netfilter.org> 2013-12-06
22:20:21 CET ---
There is no simple way to fix it: the system checks whether the set is full,
and if yes, it rejects the action.

It could first test the element in the set and perform the action if it's
there, but that'd mean a new overhead at adding any/all elements.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

jlgms <joseluis.gms at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joseluis.gms at gmail.com

--- Comment #3 from jlgms <joseluis.gms at gmail.com> 2014-01-08 19:46:53
CET ---
(In reply to comment #2)
> There is no simple way to fix it: the system checks whether the set is
full,
> and if yes, it rejects the action.
> 
> It could first test the element in the set and perform the action if
it's
> there, but that'd mean a new overhead at adding any/all elements.
So I don't understand the option '--exist', in my opinion if --exist
is present
the entry must be searched always and refresh the timeout, table full or not.

The idea is manage the set into iptables rules, now we can refresh the timeout
doing this:

... -j SET --del-set http src
... -j SET --ad-set  http src --timeout 60

?Is this less expensive than do it into ipset first seeking the entry
(--exist)?

Thanks.

Jose Luis

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

--- Comment #4 from Xose Vazquez Perez <xose.vazquez at gmail.com>
2014-07-16 12:35:27 CEST ---

"-exist" option doesn't work.

It still happens with kernel: 3.15.5-200.fc20.x86_64 and ipset: v6.20.1,
protocol version: 6.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

--- Comment #5 from Xose Vazquez Perez <xose.vazquez at gmail.com>
2014-09-18 21:31:45 CEST ---
It still happens with:

kernel 3.16.3 (kernel-3.16.3-200.fc20.x86_64)
ipset v6.22, protocol version: 6 (ipset-6.22-1.fc20.x86_64)

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

--- Comment #6 from Jozsef Kadlecsik <kadlec at netfilter.org> 2014-09-23
11:13:38 CEST ---
The issue is fixed in ipset 6.23, which is going to be released today.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

Jozsef Kadlecsik <kadlec at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=880

--- Comment #8 from Xose Vazquez Perez <xose.vazquez at gmail.com> ---
(In reply to Xose Vazquez Perez from comment #7)
> (In reply to Jozsef Kadlecsik from comment #6)
> 
> > The issue is fixed in ipset 6.23, which is going to be released today.
> 
> It looks like this is not fixed in *upstream kernel* yet.
Upstream patch: http://marc.info/?l=netfilter-devel&m=141686196620386

Jozsef, thank you, for your work.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20141125/58fb868c/attachment.html>