Mr. Kadlecsik,
--- Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As 2.4.20 comes out with newnat included, I'd like to start to work on the
> debug and notrack tables we talked about at the netfilter workshop in
> Enschede.
Before I go any further, is any of this slated for 2.5 only?
>
> Debug table:
>
> As we agreed about the debug table on the workshop: it will be the very
> first table in the PREROUTING and OUTPUT chains. The packets matching a
> rule in the table will be flagged with the new NFC_DEBUG flag in nfcache.
> Then whenever a packet flagged with NFC_DEBUG matches a rule later in any
> table, it generates a log line with the prefix:
>
> "tablename chainname rulenum"
>
> Any comments on this proposal?
Yes - make sure the NF_IP_DEBUG() macro (or whatever the author of this
system decress) is linked to CONFIG_IP_NF_DEBUG (and CONFIG_IP6_NF_DEBUG, with its
NF6_IP_DEBUG() macro). That way, maximum space-saving can be garnered.
However, I have one additional comment: this idea seems generic enough that
in theory it could be extended. Instead of one macro, have two:
NF_IP[6]_TABLE_DEBUG() - operates inside ip_tables.c
NF_IP[6]_STACK_DEBUG() - used to debug points in the stack where bugs could
cause failures and screwups in netfilter
This idea probably won't fly, but I think it could be useful.
>
> Logging:
>
> I think we should introduce a generic logging interface in ip_tables.c:
>
> void ipt_log(struct sk_buff *pskb,
> unsigned int hooknum,
> const struct net_device *in,
> const struct net_device *out,
> const char *prefix,
> unsigned char flags)
>
> #define IPT_LOG_TCPSEQ 0x01 /* Log TCP sequence numbers */
> #define IPT_LOG_TCPOPT 0x02 /* Log TCP options */
> #define IPT_LOG_IPOPT 0x04 /* Log IP options */
> #define IPT_LOG_MASK 0x07
>
> Thus anyone could call the generic interface for packet logging: from the
> LOG target, from the debug table and in any other cases when a logged
> packet might be useful (out of window packets, etc, etc).
>
> (We could make the function so generic that when say the ULOG module were
> loaded, everyting would be logged via ULOG.)
>
> What is your opinion on such a generic logging interface?
Sounds OK to me. It would reduce complexity and allow for more interesting
things to happen in ULOG ;)
>
> Stateless table:
>
> We need a "notrack", "prestate" or "stateless" table in order to be able
> to select packets not to enter the conntrack and nat framework. There have
> been (at least) two implementations already published in netfilter-devel,
> with different techniques applied:
>
> - prestate table (by me)
> I used a new NFC_NOTRACK flag in nfcache to mark the packets
> by the new target called 'NOTRACK'. The state matching
> was extended by "NOSTATE" in order to catch easily all such
> packets later by simple matching.
I used this for a while until it disappeared from the public view :(
>
> - nomatch table (by Rusty)
> Rusty used a fake conntrack entry to mark the packets selected
> by the NOTRACK target.
>
> Before the workshop, Harald sent a proposal which followed Rusty's
> approach and used the following names: 'notrack' table, 'NOTRACK' target
> and 'UNTRACKED' state.
>
> What would be the proper names at conntrack exemptions?
"UNTRACKED" sounds OK for both the state and the conntrack matches.
>
> I believe the 'NOTRACK' target and 'UNTRACKED' state names are all right.
> However the 'notrack' tablename seems to be too restrictrive to me (the
> table can be used for other purposes as well); 'conntrack' would be
> misleading; 'prestate' is a little bit ugly.
>
> What about 'stateless' (also misleading a little bit...)?
Here are a few possibilities, OTTOMH: nostate, conntrack, ctblock
>
> Technically, the debug and notrack/stateless tables could be unified.
> For a clean separation of functionalities, we should keep (introduce :-)
> both tables. However, technically there is no really need for both of
> them. What do you think?
I believe these duties should be separate.
>
> Regards,
> Jozsef
> -
Brad
P.S: If anything I said here upsets anyone, sorry in advance (seriously)
=====
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mail: [EMAIL PROTECTED]
Alternate e-mail: [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
