Hello,


On Mar 9 2007 11:54, Amin Azez wrote:
quoted text
>> Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct
>> would increase the struct sizes, and that would penalize users who do
>> not intend to use xt_portscan.
>
>I understand what you say but it sounds a bit like saying: "but we didn't
>make it very good because so few people would use it anyway" which of
>course makes it even less attractive. I realise you have your own
>interpretation but this is how it reads to me.

I just gave the reason why I designed it the way it is now. If you 
really feel it needs to be changed, well, I don't really object to that. 
chaostables has only seen like.. 1 1/2 version announcements (urls to 
tarballs, no patches) to mailing lists, and except for the few users who 
definitely tried it (based on questions I received), there have not been 
any suggestions for changes yet, which either tells me that nobody is 
interested or everything is fine.

quoted text
>> I do not see why the packet/connection marks should not be used to record
>> additional information
>...
>> Almost never I required connection marking myself 
>I guessed as much. I use it heavily, with my xml rule generators.
>> except for this
>> portscanning automaton and perhaps a little MARK here and there for
>> finely-tuned SNAT. Again, things might look different on your side(s).
>
>There's too many things fighting over the same few bits of the mark, and
>in your case you are using it to track internal state of a connection
>that has no relevance to the rest of the iptables/ebtables rules.
>
>I'm suggesting that some of the people who would want to use the chaos
>match, won't because of the mark issue.
>
>This is not a new problem.
>
>http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217

	"""netfilter marks are the solution of last resort. This is
	becoming very painful for those of us who produce general
	Netfilter configuration tools.""" -Toam Eastep

I see. Thank you for the link. I think you are on the way to have me 
convinced.



Jan
-- 
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/