On Mon, 16 Jul 2012, Mr Dash Four wrote:
> > hash:net,iface is the only type where "in/out" is natural and makes sense.
> > There are nine other types, not counting list:set, where "in/out" simply
> > doesn't fit in.
> >
> I disagree. The use of in/out "makes sense" where the 'iface' part is used (by
> being used I mean where it produces matches, obviously). There are currently
> only 2 sets which are capable of that: hash:net,iface and list:set. That is
> where it "makes sense" to allow in/out. In all other sets, the chances of
> matching against 'iface' are nil and that is why it "makes sense" to not even
> consider introducing in/out there.
What you wrote was:
You:> What I have suggested to you was that you allow in/out to be
You:> *entered*, as input, in a list:set (i.e. in the iptables statement),
You:> but treated internally in the same way as src/dst ('in' to be
You:> treated internally as 'src', 'out' as 'dst' obviously). In that way,
You:> there won't be any discrepancies and the results from both
You:> "solutions" will be the same. In other words (using the example you
You:> gave earlier), typing:
You:>
You:> -bash-~# iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
You:>
You:> and
You:>
You:> -bash-~# iptables -A INPUT -m set --match-set list1 src,src -j ACCEPT
You:>
You:> to be both accepted and 'in', as *entered* above, to be interpreted
You:> in the same way as 'src'. That way there won't be any "different"
You:> results.
So if list1 contains a hash:ip,port type alone, the rule
iptables -A INPUT -m set --match-set list1 src,in -j ACCEPT
is perfectly fine and logical. We circled again and I'm fed up.
> > No. Send your patches according to solution a, that is the "in/out" keywords
> > are allowed only with hash:net,iface type of sets alone and rejected with a
> > proper error message when attempted to use with any other set type.
> >
> You keep banging on about "send me the patches according to solution a", but
> you are unwilling or unable to address the consequences of this and the issues
> I raised in this regard. Once this is done and I am convinced that this is the
> way to go, I'll send you the new patches.
>
> This isn't some sort of Stalin-like republic where you can just order me to
> "send you the patches" and I do as I am told, OK? This is a free forum where
> we, as peers, are allowed to discuss these issues. If you are unable to hold
> to your arguments after I shot them to pieces, do you think that by ordering
> me to "send you the patches" I am going to concede and do as I am told?
>
> Or do you think that just because you've written parts of the ipset code you
> could just order me to "send you the patches" I'll bow my head and say "yes,
> sir, I'll do it sir, right away sir"? Really? Get a grip of yourself Jozsef!
Stop this, now. I don't tolerate your style anymore.
I don't care what you do. I accept patches which I believe fit fine into
the current system.
Bye,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
--
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
