netfilter buglog - Sep 2011 - [Bug 744] New: set:list behavior

http://bugzilla.netfilter.org/show_bug.cgi?id=744

           Summary: set:list behavior
           Product: ipset
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: default
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: martinbarrowcliff at gmail.com
   Estimated Hours: 0.0


Call it a enhancement if you like... It's a bug to me.

Linux server.localdomain 3.0.3_mfb #1 SMP Tue Aug 30 11:22:41 EDT 2011 i686
i686 i386 GNU/Linux

root [ /etc/firewall ]# ipset -v
ipset v6.8-genl-xta, protocol version: 96

With previous version I could test/match a setlist for an IP.
Seems this isn't working the same in V6. 

root [ /etc/firewall ]# ipset -L Blacklist
Name: Blacklist
Type: list:set
Header: size 8 
Size in memory: 56
References: 3
Members:
NetDrop
Ignore
Temp
Delay
WebDrop

The match functions in iptables "seems" to work correctly.
But I have multiple set:list and need to "test" against a single IP.
As of this version from xtables-addons, I cannot do that.

root [ /etc/firewall ]# ipset -test Blacklist 123.123.123.123
ipset v6.8-genl-xta: Set to be added/deleted/tested as element does not exist.

Obviously parsing this output is going to fail my scripts every time.

I also was unable to get the userland 6.8 release version to work at all.
The ipset mods in linux-3.0.3 didn't match properly with v6.8. 
Glad to see ipsets in the kernel; sad it didn't work as expected. 

Marty B.


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

http://bugzilla.netfilter.org/show_bug.cgi?id=744


Jozsef Kadlecsik <kadlec at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kadlec at netfilter.org
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #1 from Jozsef Kadlecsik <kadlec at netfilter.org>  2011-09-05
10:14:42 ---
The ipset version (v6.8-genl-xta) and protocol version (96?!) is totally bogus
to me.

I understand your feature request but I'm not going to implement it, because
it'd cost too much, both in effort and resources. The reason is that ipset,
the
userspace tool, has to know what to expect as input for a given set. However,
the list of sets may contain any kind of sets. So if you'd enter

ipset test Blacklist smtp

how should ipset interpret the string "smtp"? As a port from
/etc/services? Or
as a hostname from /etc/hosts (if accidentally there's a host named smtp
there)?
If host, then use the IPv4 or IPv6 address of that host?

The only safe way would be to loop through all of the sets in the list,
interpret the input according to the given subset type, attempt the operation
and return input error only if all the subsets are exhausted. However that'd
require the reworking of a quite large part of ipset.


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

http://bugzilla.netfilter.org/show_bug.cgi?id=744





--- Comment #2 from martin barrowcliff <martinbarrowcliff at gmail.com> 
2011-09-05 15:35:34 ---
I installed ipset-6.8 from xtables-addons which lists the ipset version
(v6.8-genl-xta) and protocol version (96?!). Jan can clarify any confusion on
that.

In V4 a setlist could be tested/matched. I used this heavily for both single
IP sets and Network sets. It worked nice and I liked it. Now I switched to V6. 

Forgive my naive question.
If, in ipset-V6 a set:list cannot be tested, it would seem it cannot be
matched.
Both functions do essentially the same thing, regardless of set types.
And without test/match functionality, how can set:list be used with iptables
????
Seems to me set:list doesn't do anything useful.

As a solution I will add iptables rules to test/match each individual set and
delete the useless set:lists I was using. Solves my problem.

Marty B.


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

http://bugzilla.netfilter.org/show_bug.cgi?id=744





--- Comment #3 from Jozsef Kadlecsik <kadlec at netfilter.org>  2011-09-06
12:16:52 ---
Before ipset 6.x there was no IPv6 support, and other factors changed as well.

But of course the list:set type is useful, only it has got two faces: from
userspace by the ipset tool you can add, delete and *test* subsets as elements,
while in kernel space the match/target is used. In kernel the system works on
packets which are well defined, there's no parsing issue and of course for
example a matching is executed in the subsets.

You could emulate the matching you are looking for in userspace by a simple
shell script like this (untested):

#!/bin/sh

ipset list $1 | tail -n +7 | while read x y; do
    ipset test $x $2
    if [ $? -eq 0 ]; then
        echo "$2 is in set $1"
        exit 0
    fi
done
echo "$2 is NOT in set $1"
exit 1
# eof


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