On Wed, Apr 17, 2002 at 12:58:40PM +0200, Jozsef Kadlecsik 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.
Nice. That would be great, since my primary focus will be nfnetlink/iptnetlink and iptables2 for 2.5.x and failover - not knowing how much time there will be left for other non-stuff. > Any comments on this proposal? No, I'm fine with that. However, we might also think about adding debug output to the NAT code, since paket manipulations are done without any rule matching (after the first packet has passed through). So maybe there could be some macro used at several points in the NAT code. The macro can be defined empty, if no debug table support is compiled in. > 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.) Well, my first opinion on this was: Overkill. But after giving it some thought, it would be very nice to use the debug table in combination with ULOG, because of the efficiency. Maybe we can make the logging interface similar to the 'queue handler' stuff. There can be a 'log handler' registered which takes care of logging the packet via some encapsulated mechanism. > What is your opinion on such a generic logging interface? Having a generic logging function makes sense, since the code would be duplicated anyway. > 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. > > - 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. Eeeks, I don't even remember that proposal of mine ;) Well. As for the naming, I'd say: - UNTRACKED for the state name (ESTABLISHED,RELATED,INVALID,UNTRACKED) - notrack for the table name - NOTRACK for the target name Some arguments why: - 'prestate' table sounds strange, because it is pre-conntrack, and the module is always called conntrack - 'nomatch' table. I don't know Rusty's reason for the name, but at least to me I don't see how this relates to conntrack at all. - NOSTATE as state name is OK with me, but I think UNTRACKED makes it more clear that it is untracked by an explicit rule > 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...)? Mh. 'first', 'before' ? I'm not good at naming... Is there a word (which ideally also has some funny conotation) expressing the meaning of 'before everything else' ? Any english native speakrers? > 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? Well, I think it makes sense to integrate them. However, we still need to make sure that the debug logging statements can be disabled at compile time for efficiency. So if they are unified, there still will be a config option explicitly for the debugging stuff (debugging macros + DEBUG target). > Regards, > Jozsef -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
