From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: netfilter@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: [ANNOUNCE] ipset 6.11 released
Date: Wed, 18 Jan 2012 23:53:56 +0000 [thread overview]
Message-ID: <4F175B94.60001@googlemail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1201160914550.30763@blackhole.kfki.hu>
> ipset is a tool to build up so called sets inside the Linux kernel.
I think I know what ipset is, thank you.
> The
> sets have any use in the kernel side only and there the kernel matches
> single IP addresses and never whole networks.
>
OK, I don't have intimate knowledge of the ipset code and its internal
workings, but it obviously accepts IP ranges since if I have a hash:net
set containing 10.1.0.0/16 for example and then test for that exact IP
range (10.1.0.0/16) then the test returns true, so ipset obviously
processes this IP range and returns a good result. How is that done if
the kernel "matches single IP addresses and never whole networks" then?
One other thing: *if* ipset can only accept single IP addresses instead
of IP ranges (I don't believe this to be the case, but anyway, if it
does), then you could process a single IP address in a loop containing
the whole range to be tested (10.1.12.0/24 in my example - i.e. looping
from 10.1.12.0 until 10.1.12.255 inclusive) and bail out as soon as
there is no match, which would then return 'false' (i.e. no match). You
could even speed things up a bit by implementing batch processing of IP
ranges internally (via a single kernel APIs instead of looping via ipset
and calling the kernel API each time for a single IP address check).
I know this implementation is a bit crude, but since this testing takes
place in userspace then this delay won't matter *that* much. How doable
is that?
next prev parent reply other threads:[~2012-01-18 23:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-14 14:52 [ANNOUNCE] ipset 6.11 released Jozsef Kadlecsik
2012-01-15 17:16 ` Mr Dash Four
2012-01-15 17:27 ` Jozsef Kadlecsik
2012-01-15 18:05 ` Mr Dash Four
2012-01-15 20:21 ` Jozsef Kadlecsik
2012-01-15 22:38 ` Mr Dash Four
2012-01-16 8:27 ` Jozsef Kadlecsik
2012-01-18 23:53 ` Mr Dash Four [this message]
2012-01-19 11:04 ` Jozsef Kadlecsik
2012-01-19 22:00 ` Mr Dash Four
2012-01-20 12:49 ` Jozsef Kadlecsik
2012-01-20 16:45 ` Mr Dash Four
2012-01-21 8:12 ` Amos Jeffries
2012-01-21 14:07 ` Jozsef Kadlecsik
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=4F175B94.60001@googlemail.com \
--to=mr.dash.four@googlemail.com \
--cc=kadlec@blackhole.kfki.hu \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.