Re: new iptables module
On Tue, Jan 22, 2002 at 07:52:30PM -0500, Brad Spengler wrote: I've just tried my hand at writing an iptables module. It's a match module that matches SYNs sent to unserved TCP ports and datagrams sent to unserved UDP ports. Since doing something like this is impossible with regular iptables rules, would a module like this be accepted into the patch-o-matic list for iptables? Comments/questions welcome Hi Brad. I suppose this was the mail you were referring to when we met yesterday? I can now tell you because it was lost: - Subject didn't really say anything about what the module was - you didn't include the code in the email. This might be different with other projects, but in the netfilter project [and as well as the netdev and linux-kernel lists] this is the preferred method. It's really unfortunate that we lost this important contribution because of this :( Anyway, please send your module as patch-o-matic patch, if possible. We'd certainly like to include it. -Brad http://grsecurity.net -- 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+(*)
Re: [PATCH] Iptables multiport match fix
On Tue, Jul 09, 2002 at 10:21:36PM +0200, Marcus Sundberg wrote: Hi, The multiport match checks for the IPT_INV_PROTO flag in the 'flags' member of struct ipt_ip instead of in the 'invflags' member. thanks for this fix. diff -ur linux.current/net/ipv4/netfilter/ipt_multiport.c linux-mine/net/ipv4/netfilter/ipt_multiport.c --- linux-2.4.19-rc1/net/ipv4/netfilter/ipt_multiport.c Tue Jun 20 23:32:27 2000 +++ linux/net/ipv4/netfilter/ipt_multiport.c Tue Jul 9 10:43:23 2002 @@ -78,7 +78,7 @@ /* Must specify proto == TCP/UDP, no unknown flags or bad count */ return (ip-proto == IPPROTO_TCP || ip-proto == IPPROTO_UDP) - !(ip-flags IPT_INV_PROTO) + !(ip-invflags IPT_INV_PROTO) matchsize == IPT_ALIGN(sizeof(struct ipt_multiport)) (multiinfo-flags == IPT_MULTIPORT_SOURCE || multiinfo-flags == IPT_MULTIPORT_DESTINATION (Where should I send this btw? The kernel part of iptables doesn't seem to be in the netfilter CVS. Was I supposed to create a p-o-m patch? Or send it directly to Marcelo?) send it to the netfilter development list ([EMAIL PROTECTED]). The netfilter developers will then check/test and submit to DaveM for kernel inclusion. //Marcus -- 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+(*)
Re: conntrack hash function
On Tue, Jun 25, 2002 at 12:10:44PM -0700, Don Cohen wrote: A few questions here: - Why make the two halves of the connection hash to different buckets? I'd think you'd want to consider the two halves to be the same connection. So you want them to hash the same. It would make the comparison a little more expensive, but save half the space. so what happens in case of NAT? The tuples are not the same in this case... -- 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+(*)
Re: possible race in init_conntrack()?
On Tue, Jul 02, 2002 at 11:14:51AM +0200, Patrick Schaaf wrote: Hi devel, Did I overlook something? Making drop_next atomic_t should be a good fix. no, you didn't. I'm not going to submit a patch for this, since we've never had a single bug report and it is very theoretic [whatever reason has to become true], and we are currently redesigning the conntrack hash anyway so I'd expect the new conntrack hash code including the limit-number-of-entries-per-chain code to fix this issue as well :) best regards Patrick -- 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+(*)
Re: [CRAP] Some patches
On Mon, Jun 17, 2002 at 12:02:39AM +0400, Paul P Komkoff Jr wrote:
This is the result of make allyesconfig
Actually, make allyesconfig won't link vmlinux due to netfilter p-o-m
additions. While conntrack_egg part isn't very clean (I'll resend
cleaner version later), and conntrack_rpc bombing out the kernel to panic,
and needs a big rewrite just because _tcp and _udp files ARE just a
copypaste results (Harald, so please move it to b0rken suite for now).
ok, I'll move conntrack_rpc.
But ipv6 stuff seems awful :( it just duplicating one function already
present in ipv6 code :( and doing it without static keyword ...
I think kisza has dealt with this..
diff -Nur --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet
a/net/ipv4/netfilter/ip_conntrack_egg.c
linux-2.4.19-pre10-ac2-s3/net/ipv4/netfilter/ip_conntrack_egg.c
ok, applied this one...
diff -Nur --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet
a/net/ipv4/netfilter/ipt_ah.c linux-2.4.19-pre10-ac2-s3/net/ipv4/netfilter/ipt_ah.c
--- a/net/ipv4/netfilter/ipt_ah.c Sat Jun 15 12:51:20 2002
+++ linux-2.4.19-pre10-ac2-s3/net/ipv4/netfilter/ipt_ah.c Fri Jun 14 12:31:05
2002
@@ -91,12 +91,12 @@
static struct ipt_match ah_match
= { { NULL, NULL }, ah, match, checkentry, NULL, THIS_MODULE };
-int __init init(void)
+static int __init init(void)
{
return ipt_register_match(ah_match);
}
-void __exit cleanup(void)
+static void __exit cleanup(void)
{
ipt_unregister_match(ah_match);
}
this one is now pending for kernel inclusion... (though it will be
post-2.4.19)
Paul P 'Stingray' Komkoff 'Greatest' Jr /// (icq)23200764 /// (http)stingr.net
--
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+(*)
Re: [PATCH}: Make MARK target terminate (resend)
On Fri, Jul 05, 2002 at 12:01:21PM +0800, Fabrice MARIE wrote: Hello Harald, On Friday 05 July 2002 07:58, Harald Welte wrote: [...] yes. But then, how do we distinguish between terminating targets [where we can have only one per rule] and non-terminating targets AKA actions, where we can have multiple. You could just add a boolean field 'terminating' to the iptables_target. Then, make sure iptables abort and complains if it sees more than one terminating target being requested in a single rule. no, it's not about how to distinguish it internally. It was more like: How does the user know which targets terminate and which don't [just by looking at the name or it's usage] But now, if you don't want to use the match piggybacking trick that Jozsef Henrik mentionned, then we can't implement that right now. no. There is no reason in implementing it right now anyway. A change like this would not appeear in 2.4.x anyway... Do you think multiple targets is worth including in the design of the next netfilter framework ? it's not a big issue anyway. Instead of a fixed single target entry, there is a linked list. I'm already working on that code.. I bielieve we should do that, multiple actions for one condition is very natural, and I believe the usage of a custom chain for each of theses rules is a bit overkill.. yes, it helps in some cases, but not in all. Any thoughts ? Fabrice. -- 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+(*)
Re: FYI: QUEUE ipqmpd bugs
On Fri, Jul 05, 2002 at 04:08:54PM +0200, Jean-Michel Hemstedt wrote: FYI, I upgraded to iptables-1.2.6a (user kernel-2.4.18 patches) and got the following (maybe known) problems: - QUEUE target is NOK with kernel compiled with CONFIG_IP_NF_QUEUE=m = the packets are queued, but ipq_create_handle() returns can't create netlink socket ERROR: Unable to create netlink socket: Connection refused (problem with exported symbols?) =quick fix: compile kernel with CONFIG_IP_NF_QUEUE=y I think james should be able to answer that. - ipqmpd-0.3: default verdict NF_ACCEPT is not applied when no process has attached to it. In fact ipqmpd starts, but it seems that it never receives any packet (in ipq_inp). When one process attaches to it, with a mark different from the queued packet, then the default NF_ACCEPT is applied correctly. When all processes have detached from ipqmpd, the default NF_ACCEPT continues to be applied correctly. ever looked at the CVS repository? http://www.gnumonks.org/cgi-bin/cvsweb.cgi/ipqmpd/ None of that code has been touched since 22 months... I wrote ipqmpd for fun, and nobody really seemed to use it. Feel free to submit patches or take over maintainership of ipqmpd :) kr, -jmhe- He who expects nothing shall never be disappointed -- 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+(*)
Re: [PATCH] ipt_recent-0.2.2
On Mon, Jul 01, 2002 at 07:27:31AM -0400, Stephen Frost wrote: Harald, Sending this again with hopes that it will get in before the next official release. Just a small bugfix, thanks. applied. -- 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+(*) msg01494/pgp0.pgp Description: PGP signature
Re: NAT and locally bound sockets
On Mon, Jul 01, 2002 at 11:32:32AM -0500, Michael Shuey wrote: On Thu, May 30, 2002 at 03:32:47PM +0200, Harald Welte wrote: Interestingly I don't remember this bug. I (and nobody else) has added something to the TODO list about this either. Maybe it somehow got lost :( I can't fault that; heck, I just took a month to reply to this email. I looked up the previous comment about this issue: http://lists.samba.org/pipermail/netfilter-devel/2002-January/003041.html Are you aware thet netfilter/iptables NAT is [in IETF terms] 'symmetric nat', which means that we can use the same port on the NAT gw multiple times, as long as the tuple (consisting out of srcip,dstip,srcport,dstport,l4proto) is unique. Yes, I am aware that netfilter provides symmetric nat. Unfortunately, its port selection can provide a tuple that is _not_ unique. mmh... not exactly. I understand that there is a problem, but the tuple is always unique - as long as there is any tuple! In the case where you just bind to an udp port, but haven't sent any packets yet, somebody else can use a tuple including that port - which of course clashes if the local port then starts sending packets to the same destip/destport as the now-used tuple - boom. In this scenario, think about the tuple for a moment. Since all clients and the natbox are mounting the same NFS server, selecting the same port by default, using UDP across the board, the connection tuples are (after SNAT) going to be very similar - they only differ in srcport. Normally that would be just fine; however, with a high level of traffic the NAT system would occaisionally select a srcport that was already in use by the NFS client local to natbox. That's not fine - it causes quite a few NFS timeouts, retransmits, etc. on natbox. so you need to include your nat box itself into the SNAT rule. A proper fix would have to involve TCP as well (as a similar problem most likely exists there, it just crops up much less frequently). mh. the issue with TCP is the same: if you bind to a socket and not use it for quite some time, before you actually innitiate any connection. Mike Shuey -- 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+(*)
Re: [PATCH}: Make MARK target terminate (resend)
On Mon, Jul 01, 2002 at 09:50:18AM +0200, Balazs Scheidler wrote: On Sat, Jun 29, 2002 at 12:36:36PM +0200, Henrik Nordstrom wrote: On Saturday 29 June 2002 11.46, Patrick McHardy wrote: So the question to the Netfilter core team is if it would be OK to add a new option and module class to the userspace tools, and have the existing IPT_CONTINUE targets dual-register as both a target and a match. I can try to whip something together if this is seen as something acceptable. Should be fully backwards/forward compatible with existing rulesets with only a minimal amount of code duplication. The only compability issue is that if you make use the new feature then you cannot go back to a older userspace or kernel.. I for one would second a feature like this. I see a good number of places where it could be used (the long standing missing -l option is one example) It is definitely useful. I'd love to have this additional flexibility. A couple of issues, though: 1) definitely 2.5.x thing - thus it should wait until pkt_tables becomes more apparent 2) I think this heavily confuses users, since a target can now be used as a 'match'. The current concept of netfilter/iptables is very clear and well-defined. Adding kludges like this sort-of breaks this concept... Bazsi -- 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+(*)
Re: conntrack performance/DoS formula
On Fri, Jun 28, 2002 at 12:03:38PM -0700, Don Cohen wrote: Patrick Schaaf writes: I have real data from an IRC server (one of the german IRCnet hubs), and from several boxen providing transparent proxy service to dialup customers, 3000 customers per box peak, running DNS and squid towards the Internet. With the peak load, the proxy boxen have up to 10 conntrack entries (according to slabinfo; /proc/net/ip_conntrack is too lame to show them all). Others will certainly be able to contribute data from production routing firewalls. I have one of those, too, but they only protect an ~50 workstation LAN, so these are not that significant. If you can put some data on a web page that I could download I'd be happy to write and run the program that analyzes it and compares it to the results expected for a uniform hash function. great. I'd definitley want to encourage the two of you to do some furtherr research on the hashing function. It's just a pity that I'm currently travelling and away from my test boxes, so I won't be of much help. Good work. -- 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+(*)
Re: conntrack performance/DoS formula
On Sun, Jun 30, 2002 at 12:40:09PM -0700, Don Cohen wrote: Clearly one easy defense against one easy attack (as was mentioned in private communication) is that whenever you want to add to a bucket that is full, you should feel free to throw out the oldest UNREPLIED connection in that bucket. if we're going to change the overall strategy into limiting the number of list-entries per bucket, this is definitely the way to go. just deleting unreplied in the case ip_conntrack_max is reached doesn't make sense anymore. If you're interested in preventing attacks that consume connection table space devoted to real connections I have some ideas, but that's another large discussion. If lots of people out there want to hear it I'll send to the list, otherwise perhaps it's better off the list. please send it to the list, this way people can later read it for reference purpose, and you encourage more people to discuss it. On a related subject, I'm worried that UNREPLIED might not mean what I think it does. Your data contains things like: tcp 6 387070 ESTABLISHED src=9.163.211.64 dst=165.130.71.38 sport=3228 dport=1301 [UNREPLIED] src=165.130.71.38 dst=9.163.211.64 sport=1301 dport=3228 use=1 How can one half of the connection be established while the other half is unreplied? Is this cause in one direction a syn was sent and a syn-ack was received, and that makes it established, while in the other direction a syn-ack was sent and nothing more was received so it's unreplied? That doesn't make much sense. They should both be established only if the entire handshake is complete, right? The problem here is most likely that cat /proc/net/ip_conntrack does not read out the conntrack entries atomically. We really should have ctnetlink for gathering the contents of the conntrack hash table... I'll try to have it ready soon. You were describing unreplied connections that hang around for 5 days. When I send some random syn's I see stuff like cat /proc/net/ip_conntrack tcp 6 113 SYN_SENT src=10.0.3.2 dst=10.0.2.3 sport=4096 ... I'm guessing the 113 is the timeout, and that it was originally set to 120, which still seems way too long to me, but a lot better than 5 days. so now send a single ACK packet and see what happens... This is needed for connection pickup. -- 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+(*)
Re: [PATCH}: Make MARK target terminate (resend)
On Mon, Jul 01, 2002 at 11:47:09AM +0200, Jozsef Kadlecsik wrote: On Sat, 29 Jun 2002, Henrik Nordstrom wrote: [...] I proposed adding a new class of iptables things between matches and targets, being neither a match for filtering or a target that determines the ultimate fate of the packet. The names proposed for these in the discussion was modifiers or actions. I believe we have four possibilities - multiple targets It has been rejected several times with good reasons: too error-prone for the users and it would require heavy modifications both in the kernel and the userspace. the 'too heavy modification' issue is not really a problem anymore, since the undergoing 'pkt_tables' rewrite [shared infrastructure for iptables, ip6tables, arptables] and the linked-list rewrite. - a new class: actions With the new class, we would have to following skeleton of a rule: IP match data list of matches list of actions single target Using any action would make sense only when the target is ACCEPT and alike, so the actions function as 'always true' matches. One also has to note, that we have a nice, visible separation of matches and targets by name: matches are lowercased, while targets are uppercased. How could actions be fit into this scheme? How could one decide by glimpse that we are speaking about a match, action or target? [I'd name the new class as 'action' instead of 'modifier', because '-m' is reserverd but '-a' is not.] this sounds the most reasonable idea to me. In my opinion the match solution would be better, cleaner. I think introducing actions would be the way to go. but I'm not really convinced of any of the 'solutions'. 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+(*)
Re: ip_conntrack_lock not readlocked
On Tue, Jul 02, 2002 at 04:11:37PM +0200, Albrecht Melan wrote: Hi, I'm using a kernel of version 2.4.18 where module-support is disabled together with iptables-1.2.6a ( all compiled by myself). I applied patches to netfilter using POM. which patches? The following messages are seen in my log-file ASSERT: ip_nat_core.c: 743 ip_conntrack_lock not readlocked ASSERT:ip_conntrack_core.c: 973 ip_conntrack_lock readlocked how often do you see them? Do they have always the same line number? Could you send me a grep on all 'ASSERT:' entries in your syslog? What kind of machine are you running? Thanks for your help Albrecht -- Live long and prosper - Harald Welte / [EMAIL PROTECTED]http://www.sunbeam.franken.de 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+(*)
Re: iptables questions
On Tue, Jul 02, 2002 at 03:08:37PM +0300, Vladimir Getselevich wrote: Hi, Harald. I asked you this question, but you didn't answered me. Could you please tell me how can I cause that there will not be a delay of 1 packet in ULOG. It is very important for my master research. Well, you have the sourcecode so it should be pretty easy to find out. I'd try to set flushtimeout=0 at the modprobe commandline. You say that this is an option of ipt_ULOG module. How can I configure it to deliver packets immediately without a delay. just read the ipt_ULOG.c Best regards, Vladimir -- 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+(*)
Re: performance issues (nat / conntrack)
On Thu, Jun 27, 2002 at 12:21:45PM +1000, Andrew Smith wrote: This gives a good example when being able to set the timeout dependant upon specific factors (e.g. port/protocol) would be good rather than a global timeout that suits specific cases and does not match many cases - and causes a severe problem for a limited set of cases Sorry, but we've had this discussion over and over again. Go to the list archives and look for tuneable timeouts. The conclusion of this discussion was, that we need to cope with all cases without any tuning being necessarry. btw: For the 'ping' case, the icmp echo reply is closing the connection anyway. conntrack is mostly about tracking layer 3+4 protocol state. And this should happen as transparent as possible, so assumptions about the application are made. [conntrack helpers are an exemption, and be sure I would be much happier if we didn't need to have them]. -Cheers -Andrew -- 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+(*)
Re: MSN Messenger ALG
On Wed, Jun 26, 2002 at 11:44:14AM -0700, Amir Khandani wrote: Hi, Is there a ALG for MSN Messenger in iptables? I need that to get file transfer and voice working between NATed clients. I assume you are talking about the SIP protocol? No, nobody came up to either write or sponsor support for SIP yet. It's a fairly complex protocol... thanks for any help, -amir -- 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+(*)
Re: performance issues (nat / conntrack)
On Tue, Jun 25, 2002 at 11:47:12PM +0200, Jean-Michel Hemstedt wrote: agreed. (strange thing is that ethernet irq's reported by procinfo are decreasing when the machine is overloaded. It suppose that it means either that irq's are not even caught by the kernel/driver, which is quite worrying, or either that irq's counters refer to 'processessed' interrupts) are you using a driver which uses the irq mitigation interface of 2.4.x or the NAPI of 2.5.x ? Harld: could you ask to your kernel specialist what is the weakpoint of kmem_cache_alloc()? (locks, allocs, ...), and how we could possibly improve it (batch alloc, but isn't it already the case?) I don't think that the slab allocator is the bottleneck. please show me profiling data pointing this out. I've been talking about this with a couple of people here at the kernel summit, and it looks like the per-packet del_timer/add_timer in ip_ct_refresh should be a severe performance hit on SMP boxes. Any indications that it would not be the same on non SMP boxes? well, it's still a performance problem, but on UP it doesn't involve disabling interrupts across all cpus. -jmhe- -- 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+(*)
Re: Connection Tracking and FIN+ACK packets
On Wed, Jun 26, 2002 at 12:09:48PM +0200, Antonio E. Mart?nez wrote: I am not sure if this matter has been discussed previously... If that's true, please, point me to the place where the answer is... yes. please look at the list archives. -- 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+(*)
Re: performance issues (nat / conntrack)
On Tue, Jun 25, 2002 at 01:33:13PM +0200, Jozsef Kadlecsik wrote: From where do you think that the module usage counter reports how many packets/connections are handled (currently? totally?) by the module. There is no whatsoever connection! one should also consider the performance impact this would have !!! According to your first mail, the machine has 256M RAM and you issued insmod ip_conntrack 16384 That requires 16384*8*~600byte ~= 75MB non-swappable RAM. When you issued iptables -t nat -L, the system tried to reserve plus 2x75MB. That's in total pretty near to all your available physical RAM and the machine might died in swapping. ??? Why should listing an IP table try to reserve twice the size of the conntrack table? 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+(*)
Re: performance issues (nat / conntrack)
On Tue, Jun 25, 2002 at 03:21:56PM +0200, Jean-Michel Hemstedt wrote: loading a module, doesn't mean using it (lsmod reports it as 'unused' in my tests). So, does it really 'sounds as expected', when you see From where do you think that the module usage counter reports how many packets/connections are handled (currently? totally?) by the module. There is no whatsoever connection! module usage counter increases when a TARGET needs it (i.e. ipt_REDIRECT). In this test, no rule was defined, and no target module was loaded. So I did not expect NAT to process any packet. the way NAT is implemented currently, it always processes every packet the same way. For a NEW packet where we don't find a nat rule, we allocate a 'null binding' telling the nat code that there is no nat transformation to be made . But this raises one additional problem: 1) the hash index size and the hash total size should be configurable separately (get rid of that factor 8, and use a free list for the tuple allocation). 2) NAT hash sizes should also be configurable independently from conntrack. Normally the nat hashes are smaller than conntrack hash, since conntrack is based on ports, while nat is not. both of this is already true. look at the module loadtime parameters of ip_conntrack.o and iptable_nat.o -- 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+(*)
Re: performance issues (nat / conntrack)
On Tue, Jun 25, 2002 at 03:59:01PM +0200, Jean-Michel Hemstedt wrote: ??? Why should listing an IP table try to reserve twice the size of the conntrack table? this is in nat_init (or so): nat takes the conntrack hash size to allocate 2 additional nat hashes 'bysource' and 'byisproto'. Ah. I was not aware that you didn't have iptable_nat loaded before the command. Just issuing the '-L' command with no nat loaded does not allocate anything big inside the kernel. The question is, why do we init it, if we don't use it (on a rule point of view)? This init step should occur only if we insert a rule using nat. no. This is again something I regard as feature, not as bug. dont load the module if you don't use it. It's the same behaviour like conntrack. kr, -jmhe- -- 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+(*)
Re: performance issues (nat / conntrack)
On Tue, Jun 25, 2002 at 04:51:37PM +0200, Jean-Michel Hemstedt wrote: both of this is already true. look at the module loadtime parameters of ip_conntrack.o and iptable_nat.o right for conntrack, but i can't find something similar for nat: strange. I though we already had that. conntrack: -- but in ip_conntrack_init(): 1093 ip_conntrack_max = 8 * ip_conntrack_htable_size; = when the module is loaded, it is loaded with this default value. could be good to have it as loadable parameter in order to save it and restore in modules.conf wheres the problem with having a 'echo 12345 /proc/sys/net/ipv4/ip_conntrack_max' in the post-load script in modules.conf? nat: (from ip_nat_init): - ip_nat_htable_size = ip_conntrack_htable_size; (not configurable) : allocated at init twice (for bysource and byisproto hashes) - max tuples??? haven't found any value neither any config data. (is it in patch-o-matic)? but the tuples are allocated on demand. PS: the fact that tuples are allocated on demand (392bytes/tuple) and not at init a tuple does not have 329 bytes. this sounds more like the size of a struct ip_conntrack. -- 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+(*)
Re: performance issues (nat / conntrack)
On Tue, Jun 25, 2002 at 05:13:02PM +0200, Balazs Scheidler wrote: On Tue, Jun 25, 2002 at 04:17:54PM +0200, Jozsef Kadlecsik wrote: On Tue, 25 Jun 2002, Jean-Michel Hemstedt wrote: The book-keeping overhead is at least doubled compared to the conntrack-only case - this explains pretty well the results you got. what do you mean by 'book-keeping' ? Does NAT do a lookup even if there are no rules? I have to write again: even if there are no any rules, NULL mapping happens and new connections must be put into both nat hashes. This should not explain the performance degradation others found. If no rules are found in the table, the conntrack entry is added to the NAT hashes. (place_in_hashes() function), this involves adding the entry to two linked lists (changes two pointers per list), and then calling do_bindings() which does nothing (num_manips == 0) except for calling helpers, which should be none, if helper modules are not loaded. Adding entries to the NAT hashes doesn't involve memory allocation (NAT info is stored in ip_conntrack), therefore I don't see the reason for the 50% performance decrease. think about the lock contention on SMP system. The 'null binding' approach for nat (and for example, that nat helpers are called for connections with 'null binding') is a poor design. I've recently did some testing which try to avoid the null binding, but as I'm not entirely sure they don't break something else I haven't been releasing them yet. Bazsi -- 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+(*)
Re: [ANNOUNCE] netfilter/iptables Anonymous CVS has been moved
On Fri, Jun 21, 2002 at 03:55:08PM -0400, Stephen Frost wrote: * Harald Welte ([EMAIL PROTECTED]) wrote: The anonymous CVS repository for the netfilter/iptables project has been moved. Harald, Is there anything we need to do to get back on the netfilter cvs-commits list? I havn't seen any commits since the 18th so I'm guessing either we have to subscribe to a new list or you're still working on getting that part up again? the list is up and running [on lists.netfilter.org]. I'll see if I can find something in my logs about your mails... Stephen -- 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+(*) msg01358/pgp0.pgp Description: PGP signature
Re: MIME Patches (was [PATCH] ROUTE target : bug fixes)
On Fri, Jun 21, 2002 at 10:56:24AM -0700, Ben Reser wrote: On Fri, Jun 21, 2002 at 07:15:26PM +0200, Harald Welte wrote: Please try to send patches as mime attachment to ensure no corruption occurs. Okay this is confusing. Your scoreboard guidelines (http://www.netfilter.org/scoreboard/) say that you should include patches straight in the body of the message, not MIME'd. Honestly I've always found this policy bizzare. This is because Rusty wrote it, and he wants to have it this way [like many other kernel hackers incl. David Miller] because emacs doesn't handle mime mail. Either way we should pick a standard and follow it. Frankly MIME is a common standard and attaching patch is intuitive. So I think we should go that route. yes. The core team agreed on that long time ago, since I'm handling most patches these days I am the one to set the rules ;) I'm updating the scoreboard/index.html now. Ben Reser [EMAIL PROTECTED] -- 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+(*) msg01361/pgp0.pgp Description: PGP signature
Re: About a patch to unclean module.
On Sat, Jun 22, 2002 at 10:51:10PM +0800, Fabrice MARIE wrote: Hello Maciej, On Saturday 22 June 2002 03:00, Maciej Soltysiak wrote: Hello, I may say now, that I have finished writing the module, updating the lipipt_unclean.c, I have created the patches to the netfilter tree. But, suppose, Harald applies the patch. It will change libipt_unclean.c in a way, that withougt running patch-o-matic it will not compile, because it uses an include file KERNEL_DIR/include/linux/netfilter_ipv4/ipt_unclean.h which will be only available after patching the kernel tree. So how do we solve that? The easiest way is to use the userspace patching facility of patch-o-matic. GNAH! As soon as somebody is using this evil confusing hack without it being absolutely necessarry, I'll start flaming him. See my other mail in this thread. Fabrice. -- 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+(*) msg01362/pgp0.pgp Description: PGP signature
Re: About a patch to unclean module.
On Fri, Jun 21, 2002 at 09:00:04PM +0200, Maciej Soltysiak wrote: Hello, I may say now, that I have finished writing the module, updating the lipipt_unclean.c, I have created the patches to the netfilter tree. But, suppose, Harald applies the patch. It will change libipt_unclean.c in a way, that withougt running patch-o-matic it will not compile, because it uses an include file KERNEL_DIR/include/linux/netfilter_ipv4/ipt_unclean.h which will be only available after patching the kernel tree. So how do we solve that? this is a comon problem, and it's always solved the same way: Put the kernel include file into userspace/include/linux/netfilter_ipv4/. Maciej Soltysiak -- 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+(*) msg01363/pgp0.pgp Description: PGP signature
Re: performance issues (nat / conntrack)
On Thu, Jun 20, 2002 at 09:48:27PM +0200, Jean-Michel Hemstedt wrote: dear netdevels, I'm doing some tcp benches on a netfilter enabled box and noticed huge and surprising perf decrease when loading iptable_nat module. Sounds as expected. - ip_conntrack is of course also loading the system, but with huge memory and a large bucket size, the problem can be solved. The big issue with ip_conntrack are the state timeouts: it simply kill the system and drops all the traffic with the default ones, because the ip_conntrack table becomes quickly full, and it seems that there is no way to recover from that situation... Keeping unused entries (time_close) even 1 minute in the cache is really not suitable for configurations handling (relatively) large number of connections/s. what is a 'relatively' large number of connections? I've seen a couple of netfilter firewalls dealing with 20+ tracked connections. o The cumulative effect should be reconsidered. could you please try to explain what you mean? o Are there ways/plans to tune the timeouts dynamically? and what are the valid/invalid ranges of timeouts? No, see the mailinglist archives for th reason why. o looking at the code, it seems that one timer is started by tuple... wouldn't it be more efficient to have a unique periodic callback scanning the whole or part of the table for aged entries? I think somebody (Martin Josefsson?) is currently looking into optimizing - The annoying point is iptable_nat: normally the number of entries in the nat table is much lower than the number of entries in the conntrack table. So even if the hash function itself could be less efficient than the ip_conntrack one (because it takes less arguments: src+dst+proto), the load of nat, should be much lower than the load of conntrack. o So... why is it the opposite?? ? What 'nat table' are you talking about? Do you understand how NAT works and how it interacts with connection tracking? o Are there ways to tune the nat performances? no. NAT (and esp. NAT performance) is not a very strong point of netfilter. Everybody agrees that NAT is evil and it should be avoided in all circumstances. Rusty didn't want to become NAT/masquerading maintainer in the first place, but rather concentrate on packet filtering. The NAT subsystem has a number of shortcomings, some of which have been fixed, other still remain. - Another (old) question: why are conntrack or nat active when there are no rules configured (using them or not)? If not fixed it should be at least documented... This is standard behaviour. Does your network driver unload if you 'ifconfig down' an interface? Does a TC qdisc module unload if you delete all instances of the queue? conntrack is _not_ related/intermangled with iptables at all. Conntrack does not know if anybody is using conntrack state in the system. Somebody doing iptables -t nat -L takes the risk of killing its system if it's already under load... ? Please explain why. I see no reason for this. In the same spirit, iptables -F should unload all unused modules (the ip_tables modules doesn't hurt). Just one quick fix: replace the 'iptables' executable by one 'iptables' script calling the exe (located somewhere else) and doing an rmmod at the end... no. this is considered a feature. The current [and past] behaviour is wanted like this by design. -jmhe- -- 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+(*) msg01364/pgp0.pgp Description: PGP signature
Re: Bug#150467: user-defined chains vs. iptables module names
On Fri, Jun 21, 2002 at 11:03:37AM +0200, Patrick Schaaf wrote: Wasn't there recent discussion about how do I find all available target names? yes. Unfortunately nobody implemented what the discussion was about. regards Patrick -- 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+(*) msg01365/pgp0.pgp Description: PGP signature
Re: [ANNOUNCE] Feature Freeze for iptables-1.2.7
On Sat, Jun 22, 2002 at 07:12:30PM +0200, Hervé Eychenne wrote: On Sat, Jun 15, 2002 at 11:59:09AM +0200, Harald Welte wrote: Hi, I'm announcing a feature freeze for the iptables-1.2.7 release starting at 24 Jun 2002. After this date, only bugfixes will be accepted. The 1.2.7 release will most likely be out by Jul 01. So here are minor manpage updates. thanks, applied. RV -- 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+(*) msg01367/pgp0.pgp Description: PGP signature
Re: [PATCH] ROUTE target : bug fixes
On Thu, Jun 20, 2002 at 04:12:41PM +0200, Cédric de Launois wrote: Hi, Here is a patch for 'ROUTE' target : thanks. I'd love to apply your patch, but since you have not attached but inlined it, your mail program has wrapped the lines and thus corrupted the patch. Please resend it. Please try to send patches as mime attachment to ensure no corruption occurs. Cédric de Launois -- 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+(*) msg01349/pgp0.pgp Description: PGP signature
Re: ipt_recent-0.2.1 [PATCH]
On Tue, Jun 18, 2002 at 12:34:39AM -0400, Stephen Frost wrote: Hey all, Version 0.2.1 of my ipt_recent module has been up and running on my thanks. For future reference: please send patches as mime attachment, uncompressed. this way i can read them in the mailer and don't need to save, unzip them before. Thanks, Stephen -- 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+(*) msg01350/pgp0.pgp Description: PGP signature
[ANNOUNCE] netfilter/iptables Anonymous CVS has been moved
Hi! The anonymous CVS repository for the netfilter/iptables project has been moved. Please don't use the old (pserver.samba.org) repository anymore, since it is no longer updated and will run out of date very soon. The new location for accessing the netfilter/iptables sourcecode via anonymous CVS repository is: cvs -d:pserver:[EMAIL PROTECTED]:/cvspublic login cvs -d:pserver:[EMAIL PROTECTED]:/cvspublic co netfilter/userspace Or if you want to check out the full repository, including homepage, HOWTO sources, etc.: cvs -d:pserver:[EMAIL PROTECTED]:/cvspublic login cvs -d:pserver:[EMAIL PROTECTED]:/cvspublic co netfilter Please also note that the URL for CVSweb access has changed: http://cvs.netfilter.org/ Thanks! -- 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+(*) msg01343/pgp0.pgp Description: PGP signature
Re: netfilter on solaris?
On Fri, Jun 14, 2002 at 12:05:40PM +0200, Balazs Scheidler wrote: Hi, It is a strange idea I know, but I'd be interested in what the opinion of the core netfilter developers is on porting the whole netfilter subsystem to Solaris? After my netfilter presentation at linuxtag, somebody was asking me exactly this question. Apart from the technical issues, would there be any problems? Does the GPL allow this kind of usage? (it would be implemented as a module) This is basically the same question like binary-only kernel modules. The GPL just talks about linking with libraries, since it was written at the time people were working on userspace programs. Linus has generally given his permission, that his code might be called from binary-only kernel modules Rusty has always made it very clear, that he doesn't share this view and he has never given permission for people using any of his code from binary- only modules. Having netfilter within a different kernel, is technically the same: GPL'd netfilter/iptables code is called from a binary-only kernel. Thus, my conclusion would be: Without the explicit permission of the authors, it is legally not possible to use netfilter/iptables within a proprietary OS kernel. But of coursel, I am not a lawyer. I for myself are somewhat undecided, but I tend to share Rusty's view: I haven't ever given permission for using my code by binary only kernel modules. All new code I'm working on wil export GPLONLY to make sure about that. ps: don't tell me to use ipfilter (which works on Solaris), it's awful I don't share this opinion, but this doesn't matter - it's off-topic. Bazsi -- 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+(*) msg01322/pgp0.pgp Description: PGP signature
Re: netfilter on solaris?
On Fri, Jun 14, 2002 at 12:47:07PM +0200, Balazs Scheidler wrote: But how do you imagine the porting so that the maintenance would not become a nightmare? Of course I'd want to provide system independency using some headers which would make it work on both Linux/Solaris, so it could be incorporated into standard Netfilter as well. Just to make this clear: As long as I am one of the maintainers of netfilter/iptables, I am not going to do any extra hassle in order to support different operating systems. This includes using weird different types instead of sk_buff. Linux kernel hackers expect to see linux code, not something abstract using only typedefs and macros all over the place. Sorry. Bazsi -- 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+(*) msg01323/pgp0.pgp Description: PGP signature
Re: netfilter on solaris?
On Sat, Jun 15, 2002 at 03:37:25PM +0200, Balazs Scheidler wrote: On Sat, Jun 15, 2002 at 02:52:12PM +0200, Harald Welte wrote: On Fri, Jun 14, 2002 at 12:05:40PM +0200, Balazs Scheidler wrote: Hi, It is a strange idea I know, but I'd be interested in what the opinion of the core netfilter developers is on porting the whole netfilter subsystem to Solaris? After my netfilter presentation at linuxtag, somebody was asking me exactly this question. And your answer was? what a weird idea. I told him that it is technically not easy and the core team certainly has no plans of ever supporting this thing. I didn't even start to talk about licensing issues. This is basically the same question like binary-only kernel modules. I think it is more similar to Gimp plugins under Photoshop case. I'm not aware of this case - we are not talking about .so's [libraries] being linked to an application, which is what the GPL is talking about. Under binary-only you mean propriatery, or something nonGPLd? Solaris kernel source _is_ available, though it doesn't use the GPL. well, source is available if you sign some very interesting license conditions, IIRC. Anyway, this is not important. When I was talking about proprietary or binary-only, I should have said: GPL-incompatible. Bazsi -- 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+(*) msg01328/pgp0.pgp Description: PGP signature
Re: [patch] REJECT incorrectly inherits the current nfmark to the generated RST packet
On Thu, Jun 13, 2002 at 07:31:23PM +0200, Henrik Nordstrom wrote: I have a smal patch not yet sent.. REJECT incorrecly inherits the current nfmark to the generated packet, inhibiting mangle from rerouting the generated RST packet correcly if attempting to set the same mark as the original packet that was REJECT:ed. hm. this is in fact a bug. It might depend on one's point of view, and maybe there was a particular reason for the way it is currently implemented. As far as I don't receive any complaints, I will submit this patch to the kernel soon. For now, it can be found in patch-o-matic/pending/ Henrik -- 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+(*) msg01309/pgp0.pgp Description: PGP signature
Re: [PATCH] Unused bit check to Unclean module
On Wed, Jun 12, 2002 at 03:57:12PM +0200, Maciej Soltysiak wrote: Hello, as suggested by Jozsef, i moved my IP unused bit check to the Unclean module. Here is the patch to netfilter root directory. thanks, applied. Regards, Maciej Soltysiak -- 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+(*) msg01306/pgp0.pgp Description: PGP signature
Re: New target 'ROUTE' - cvs patch
On Tue, Jun 11, 2002 at 02:49:40PM +0200, Cédric de Launois wrote: Hi, Here is the patch against the current CVS tree to include the new target 'ROUTE'. The patches have been tested, they work fine for me. Doing patch -p0 ROUTE.cvs.patch in the same directory as netfilter/ should apply the patch correctly. great. applied. two minor modifications: 1) move it to 'extra', since we consider it as experimental at the moment. 2) remove your change to extensions/Makefile. Only targets in the kernel (or to be submitted to the kernel soon) are in extensions/Makefile. Cédric de Launois -- 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+(*) msg01308/pgp0.pgp Description: PGP signature
Re: [Fwd: Bug fixed]
From: zhongyu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug fixed Date: 10 Jun 2002 16:23:34 +0800 Fix iptable_nat's memory leak problem. ouch. thanks. How can something as obvious as this bug survive for that long time? I'll pass this on for kernel inclusion immediately. Could you tell us your real name for the scoreboard? thanks. -- 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+(*) msg01284/pgp0.pgp Description: PGP signature
Re: [PATCH] remove exessive timer updates (3/4)
On Sat, Jun 08, 2002 at 05:03:36PM +0200, Martin Josefsson wrote: On Sat, 2002-06-08 at 09:37, Harald Welte wrote: ah. now I understand what the exporting was all about :) :) sounds interesting and should give quite some speedup. Did you do any benchmarking on that? I need to get a slower test-router so I can benchmark properly :( I need to get a very old pentium or high-end 486 with PCI. ok, but even then the benchmarking results would most likely be a bit different, since modern CPU's tend to have quite different cache sizes and I/O respectively memory bandwidth. I implemented this a while ago and then accidentally lost the sourcetree but I did do some profiling which I can't find now :( no problem. I was just asking in case you had some numbers handy... A similar thing was recently done in VFS in kernel 2.5 for the atime updates and it gave a very nice speedup, I doubt the speedup will be as large here since the timer handling is a lot faster than disk-io. I think I will do some stress testing with and without your patch. I'm currently in the process of going through the locking in conntrack to try and make it more scalable (splitting ip_conntrack_lock) and trying to fix things I find. great, improvements are always welcome, as you might assume :) /Martin -- 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+(*)
Re: [PATCH] don't try to track broadcasts or multicasts (4/4)
On Sat, Jun 08, 2002 at 04:51:47PM +0200, Martin Josefsson wrote: Hmm why didn't I think about that? it just came to my mind after reading your mail.. I've done some simple testing and the results are: the results are actually quite interesting - but maybe there's a particular reason for TCP behaving different than other protocols... It was a nice thought but doesn't work in the real world. yup, it would have been a nice optimization... /Martin -- 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+(*)
Re: conntrack/NAT module
On Wed, Jun 05, 2002 at 10:36:48AM +0800, luoqiang wrote: Hi,Harald Thanks for your answers. I am afraid that the conntrack module for DNAT is not correct now.my purpose of the two module is to achieve the rule which is iptables -A PREROUTING -t nat -p udp -d 159.226.1.1 --dport 5001 -j DNAT --to 192.168.1.2:. well. from having a short view at your code, i'm unable to determine the reason of it's malfunction. it might be worth trying to see what verdict ip_nat_setup_info is actually returning, since that particular (hardcoded) ip_address / portnumber range could be already in use. Another issue could be endianness... luoqiang -- 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+(*)
Re: [PATCH] remove exessive timer updates (3/4)
On Thu, Jun 06, 2002 at 02:24:04PM +0200, Martin Josefsson wrote: Here's the patch that lead up to the first patch (the renaming of death_by_timeout and exporting it). ah. now I understand what the exporting was all about :) This patch adds a check to ip_ct_refresh() so it doesn't update the timer of a connection unless it's been HZ ticks since the last update. both del_timer() and add_timer() disables interrupts while removing/inserting the timer, no reason to do this for each packet. sounds interesting and should give quite some speedup. Did you do any benchmarking on that? /Martin -- 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+(*)
Re: [RFC] matching tproxied packets
On Tue, Jun 04, 2002 at 04:50:36PM +0200, Balazs Scheidler wrote: Hi, Suppose you have a TCP session, which is transparently redirected to a local proxy. With the current state of the tproxy framework one need to add two rules to iptables: - one to the tproxy table to actually redirect a session - one to the filter table to let the NATed traffic enter the local stack (in INPUT) I'd like to make tproxies easier to administer, so I'm thinking about a simple way of matching tproxied packets, which can be ACCEPTed from the INPUT chain. Possible solutions: * use a new state (called TPROXY), which would be applied to all TPROXYed packets (might interact badly with nat/conntrack). yes, and it is not really a state. * have the tproxy framework mark all packets with an fwmark, and let the packets in based on the value of fwmark fwmark should only be used as configured by the administrator. * have a separate match (called tproxy), which matches tproxied sessions based on some value stored in the associated conntrack entry this is the preferred solution from my point of view. Bazsi -- 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+(*) msg01181/pgp0.pgp Description: PGP signature
Re: iptables bad byte counter?!?
On Wed, Jun 05, 2002 at 09:29:54PM +0200, Henrik Nordstrom wrote: Torge Szczepanek wrote: I am getting byte counters like this: 18446744073707058701 Very much looks like a negative number.. the above is the same as 64 bit integer -2492915 printed as a unsigned value. The byte counters differ (18446744073707 is mostly the same) so I think this might be an overflow of a (longint?!?) counter. Very unlikely as it is 64 bits in size and unsigned.. no, this is clearly a problem within the 32bit-userspace / 64bit kernelspace handling of iptables. Don't assume any reasonable value to be in the counters on sparc64. Regards Henrik -- 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+(*) msg01183/pgp0.pgp Description: PGP signature
Re: any body help me...
On Thu, Jun 06, 2002 at 04:53:02AM +0900, bob wrote: HTML is not the right format for an email. emails are either plain 7 bit ascii or mime encoded text. -- 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+(*) msg01184/pgp0.pgp Description: PGP signature
Re: [PATCH] Compile fixes
On Sun, Jun 02, 2002 at 04:01:04PM +0200, Marcus Sundberg wrote: Hi, some fixes to make current CVS compile properly. thanks, applied. //Marcus -- 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+(*) msg01144/pgp0.pgp Description: PGP signature
Re: ECN target in cvs broken?
On Sun, Jun 02, 2002 at 10:38:07PM -0400, Dave Hawkes wrote: I think there may be a typo in the ECN code recently commited to CVS line 12 in ipt_ecn.h yes, this has been fixed now. Dave Hawkes -- 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+(*) msg01145/pgp0.pgp Description: PGP signature
Re: Dependence issue on today cvs
On Tue, Jun 04, 2002 at 12:33:46AM -0300, Thomas T. Soares wrote: Hi all packets hackers... This is just to inform that the today CVS of netfilter is giving this to me: typo is fixed now, should work again. | Thomas Tschoepke Soares | // En brujas no -- 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+(*) msg01147/pgp0.pgp Description: PGP signature
Re: New ECN target in CVS
On Thu, May 30, 2002 at 01:02:04AM +0200, Henrik Nordstrom wrote: Harald Welte wrote: The ECN target supports the following operations: -p tcp -j ECN --ecn-tcp-remove As discussed before, I think there should be an --ecn-remove, which both a) Clears all the ECN bits from the TCP header on TCP packets b) Sets the IP level ECN codepoint to 0 well. The way TCP-ECN setup works, is that the ECE and CWR are set in the SYN packet. If you remove those two bits from the TCP header, you effectively prevent ECN to be negotiated for this connection. The IPv4 ECT bits are not used during this negotiation. So for a clean 'prevent-ecn-from-being-used' target, I would not touch the IPv4 header bits. Feel free to convince me of the opposite :) I don't see any value in being able to manipulate the bits other than to clear them, and if selected to clear them then the ECN bits should be cleared at all levels. Well, the value would be of experimental nature. Like manually simulating congestion by setting an ECT codepoint. This also applies quite nicely to non-TCP packets. no. I will _never_ advocate setting/removing the ECT codepoint from a non-tcp ECN packet. Since there are no specs (RFC's) about how the IPv4 ECT bits are used for other layer 4 protocols. ECN works as a combination of IP and transport layer, and to prevent ECN from being negotiated, you need to touch the transport layer. removing IPv4 ECT bits is effectively removing signalling information when congestion actually occurs. This leaves both ends in the belief that the connection supports ECN, but in case of congestion packets are dropped rather than the ECT bits set. This totally breaks ECN behaviour. Regards Henrik -- 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+(*)
Re: my last NAT fix unseen?
On Thu, May 30, 2002 at 10:39:06AM +0200, Balazs Scheidler wrote: Hi, I've posted a patch against the ICMP NAT problem I encountered, and there was no reply. It was under the topic Re: addendum to ICMP translation problem [PATCH] it was posted 27th May. Could you please review it? oh my god. Please. I will review your patch ASAP, as will do every other coreteam member. It's just like not everybody has the time to immediately look into every detail of something as complex as the ICMP reply translation. SCNR. Bazsi -- 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+(*)
New ECN target in CVS
Hi! I have just committed the (new) finished ECN target to CVS, it's in patch-o-matic/base/ECN.patch The ECN target supports the following operations: -p tcp -j ECN --ecn-tcp-remove Remove all ECN bits from the TCP header and thus suppress the advertisement of ECN-capability of the sender. This is what you want to use to work around ECN blackholes. In addition, there are a couple of experimental options, which are potentially _VERY DANGEROUS_, and I'm not sure if I should really keep them at the time the ECN target is submitted to the mainstream kernel. If you have any good arguments why they should (not?) be preserved, please go ahead and tell me :) -p tcp -j ECN --ecn-tcp-cwr 0|1 Set the TCP ECN CWR bit to 0 or 1 -p tcp -j ECN --ecn-tcp-ece 0|1 Set the TCP ECN ECE bit to 0 or 1 -j ECN --ecn-ip-ect 0..3 Set the IPv4 ECN codepoint to any value between 0 and 3 -- 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+(*)
Re: [PATCH]: new fixed+improved string match
On Wed, May 29, 2002 at 12:14:09PM +0100, Gianni Tedesco wrote: Hi all, Here is a new string match. New kernel code, and updated userspace code. As much as I appreciate your work, we still have Emmanuel Roger listed as author of the patch. This means, that I'd like you to discuss your changes with him before submitting them to me. If he isn't working on the string match anymore, we could also change ownership to you, but only in case this is fine with Emmanuel. // Gianni Tedesco [EMAIL PROTECTED] -- 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+(*) msg01099/pgp0.pgp Description: PGP signature
Re: Bug: iptables -A INPUT -p TCP --state NEW ! --syn -j DROP
On Mon, May 27, 2002 at 03:43:02PM +0200, Jean Bel wrote: Hi, The result of the command: iptables -A INPUT -p TCP --state NEW ! --syn -j DROP is Out of memory: Killed process 5166 (iptables). well, it seems like your system is out of memory. Nothing iptables-related, though. Thanks. Jean Bel -- 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+(*)
Re: manpages updates
On Sun, May 26, 2002 at 03:48:49PM +0200, Hervé Eychenne wrote: Hi, Here are attached some small fixes for iptables(8) and ip6tables(8) manpages: - TTL target had nothing to do here, as it is in patch-o-matic. Deleted for coherence. Maybe we could have a special manpage for extra extensions, but as they are already documented in the Netfilter Extensions HOWTO, it would seem to appear as a duplicated effort. I just added a note on the existence of this HOWTO. ok. - check option (former -C in ipchains) will never exist (document this in the FAQ, if not done) ok. - owner section was duplicated in the process of merging my previous manpage patch (a bug in the patch tool? ;-) oops. - small typo fixed - some minor cosmetic changes fine. Comments: - strictly speaking, REJECT target for IPv6 is not in mainstream 2.4.18, so it should not have appeared in the ip6tables(8) manpage. I have left it though. well, I should find some time and finish the REJECTv6 and submit it. (°= Hervé Eychenne Thanks, patch applied. -- 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+(*)
Re: ULOG and logd
On Sun, May 26, 2002 at 10:37:42AM -0500, James Tidman wrote: I downloaded ethereal and determined these packets to be ARP packets. I thought they would show up under the default PROTO, but maybe not. The packets never showed up in the ULOG file. I don't pass any paramters to ipt_ULOG, the defaults seem to be OK. I don't know if ULOG will track ARP, I will keep looking at the source and on the web.. no, as ARP is a seperate layer 3 protocol (independent from IP), no ARP packet will ever go through iptables and thus never get logged by any ULOG rule. Thanks, James -- 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+(*)
Re: endianess issue in newnat
On Thu, May 23, 2002 at 10:38:33AM +0200, Roberto Romano wrote: Hello, I just want to report an endiannes issue found with 2.4.18+newnat running on a PPC architecture. this turns out to be strange, since most parts of newnat have been developed on powerpc architecture. As Jozsef already pointed out, it is the PPTP patch which is the culprit. In old nat they both contained an union u of 16bits width. With newnat this union u is now 32bits width. This breaks code where the union is still initialized with 16bits values as if the whole union size was still equal to its port element. this is true, indeed. While I was aware of this, I thought I had fixed all respective code parts. Maybe something got lost before creating the final patch :( One possible fix for this chunck of code could be: exactly true. There is multiple places in newnat code having this issue. Anybody else tried newnat on a big-endian arch ? Yes, newnat is running on big-endian here - but without pptp :) Are you able to provide us with a patch fixing all respective places throughout the code? This would help a lot... If you don't have the time, please tell me an I'll see what I can do. Regards, Rob -- 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+(*)
Re: tproxy using conntrack/nat?
On Thu, May 23, 2002 at 12:56:58PM +0200, Balazs Scheidler wrote: I see two possibilities: * add a new argument to ip_nat_setup_info() to avoid helpers seems reasonable. it's only three arguments currently, having four wouldn't be a problem. add a 'int flags' argument and define a flag for 'BYPASS_HELPER'. ok, isn't this api change too intrusive to other netfilter parts? ip_nat_setup_info() is referenced 11 times on an unpatched 2.4.18. From my point of view, Linux kernel API's have always been changing. And a simple one-argument-change doesn't hurt anybody. The patch may contain a huge number of lines (since it's 11 function call changes) - but looking at it from an abstract point of view, there is nothing intrusive about it. A third solution would be to add new NFCT_ flag. Do you still prefer the flags argument? no, nfct again looks like a hack. This however wouldn't bypass the conntrack helper [which could already say INVALID because a packet doesn't match the layer5+ state of the connection, see for example the PPTP helper]. Don't forget that we have two conntrack entries if traffic is flown through a transparent proxy, and conntrack processing is done prior to NAT rewriting. Please tell me if I'm wrong, but CONNTRACK sees an unmodified PORT command assigned to a session with unmodified destination address. Oh, I didn't make myself clear. There are no bad interactions with NAT. But in case there really is an out-of-state packet, the conntrack helper would mark it INVALID - which might not be what you want in case of transparent proxying, where such state violation should be detected by the proxy itself. Bazsi -- 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+(*)
Re: another netfilter ICMP bug
On Thu, May 23, 2002 at 10:18:23AM +0200, Balazs Scheidler wrote: Hi, I've encountered another ICMP translation problem in netfilter. This time it occurs when a process initiates a connection and it is translated on the same host. are you sure this problem persists, even after applying the icmp nat fix? Bazsi -- 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+(*)
Re: [PATCH] REJECT with fake source IP update
On Wed, May 22, 2002 at 02:56:28PM +0800, Fabrice MARIE wrote: Hello, Here's a patch from Guilaumme Morin that updates thanks, patch applied. Fabrice MARIE -- 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+(*)
Re: netfilter C++
On Thu, May 16, 2002 at 03:15:11PM +0800, Fabrice MARIE wrote: I probably didn't understand.. but is there any reason to explicitely cast the pointer to become a 'void *' when the declaration specifically says it is returning an 'ipt_entry_target *' ? Shouldn't it be casted to 'ipt_entry_target *' instead ? Sorry if didn't understand, but I'm just curious. It isn't about the return value, it's about the calculation. Casting it to void * results in the addition of N bytes - otherwise we would add sizeof(struct ipt_entry_target)*N Have a nice day, Fabrice. -- 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+(*)
[OT] Off from my email for 5 days.
Hi! I just want to let you know: For the first time in several years, I'm now totally off my email for five days [starting with friday, 17th of May to 22nd of May]. So please excuse otherwise unexpected delays in email reply. [if anybody's interested, I'm off for something not computer related at all, http://www.wave-gothic-treffen.de/] See [read/write] you, Harald. -- 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+(*) msg00969/pgp0.pgp Description: PGP signature
Re: [Q] Relating multiple UDP streams to a single connection
On Tue, May 14, 2002 at 04:19:15PM -0700, Brennen Reynolds wrote: All of the connections use UDP. I want to have the first line (H1:p1-H2:P0) be the main connection with all the other ones related / associated with it. I have been able to relate the H1:P0-H2:P2 connection by creating an expected connection by including everything but P2 in a tuple. I though this would catch the other ones, but it doesn't. If I specify a related tuple as (H1:P0-H2:any port) why does it only work for the first instance? Any help / pointers to other mods doing this would be great! Because you always expect only a single connection. There is no such thing as a 'persistent expectation' From my point of view, there are two possible solutions: 1) create a new expectation at the time your first slave connection arrives (racy) 2) use the newnat API [which is encouraged anyway, since it will be standard starting with the 2.4.20 kernel] and issue four expectations for four to-be-expected UDP streams. Brennen Reynolds [EMAIL PROTECTED] -- 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+(*)
Re: netfilter C++
On Wed, May 15, 2002 at 06:06:51PM +0300, Dotan Lior wrote: Hi, I'm trying to write a class in C++ that will retreive statistics from iptable in order to find out the traffic on each rule in the NAT table. The problem is that after including iptables.h whenever I'm compiling I get: Please see the various lengthy over-and-over-again discussed threads about C++ programming within the linux kernel. A short summary: The linux kernel will never support c++ Or are you talking about userspace? TIA Lior -- 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+(*)
Re: Re:
On Sun, May 12, 2002 at 12:32:33PM +0800, Dung Patrick wrote: I use iptables 1.2.6a (debian woody). The iptables-save in cvs is 1.22 (last changed is in March). I've not compiled the source from cvs to test yet. Ok. The bug is (was) within the iptables.c code, could you please try latest CVS [or try to apply the patch http://cvs.samba.org/cgi-bin/cvsweb/netfilter/userspace/iptables.c.diff?r1=1.45r2=1.46] -- 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+(*)
Re: #106374: -N doesn't do the right thing when followed by a would-be option
On Fri, May 03, 2002 at 07:01:07PM -0700, Laurence J. Lane wrote: I'm trying to clean up outstanding Debian bugs that are not Debian maintainer screw ups. My mail to the list has fallen into a black hole somewhere. Here we go again... http://bugs.debian.org/106374 The problem is user-defined chains that start with a dash are seemingly impossible to kill with any amount of shell-foo. Using GNU logopts style --foo=bar options is the only way I've found to remove the chains independently. I don't see anything in the docs that mention that style though. ouch. maybe we should rather check on '-' as first character and disallow chain creation with such names. Just a personal note: But it would have _never_ occurred to me that somebody would want to start a chain name with a leading dash. -- 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+(*)
Re: [PATCH] iptables hppa build failure, ld linking
On Fri, May 03, 2002 at 07:47:06PM -0700, Laurence J. Lane wrote: This is a bug of sorts triggered on the hppa Debian build daemon auto-builder. iptables fails to build on hppa. Lamont Jones provided a patch that changes the build behavior to use gcc instead of ld for linking. All 11 Debian architectures appear to accept the change. well, I have no idea about the hppa port, but I don't really understand why they enforce usage gcc instead of 'ld' for linking. Shouldn't this be fixed within the binutils / buildchain, rather than having patching (all? lots of?) individual packages. Maybe you can forward this to the patch author, asking him for some explanation of this case. - $(LD) -shared -o $@ $ + $(CC) -shared -o $@ -nostdlib $ -lgcc -- 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+(*)
Re: Question about ip_nat_setup_info
On Thu, May 02, 2002 at 07:44:12PM +0200, Patrick McHardy wrote: Hi ! I have a question concerning nat code. After handing a struct ip_nat_multi_range to ip_nat_setup_info the target doesn't see any future packets from the original ip. is there a way to dermine when the last packet for an ip/struct ip_nat_multi_range was handled by the nat code ? no, since NAT doesn't deal with state, and only conntrack notices when a connection is torn down. And what about timed out connections? You never know what was the last packet... The only idea could be to register some callback function with the conntrack destroy function, and then reading out the nat bindings out of the ip_conntrack struct before destroying it. Thanks Bye, Patrick -- 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+(*)
Re: [PATCH] icmp type-3-code-13 for REJECT
On Mon, Apr 15, 2002 at 03:41:25AM -0700, Brad Chapman wrote: There is no real change in the structure layout, it's just one additional value that is becoming valid... Yes. After studying my patches some more, I've rezlied the following: - unpatched userspace simply doesn't tickle the case statement in the kernel that specifies a type-3-code-13 packet - unpatched kernelspace just doesn't accept the value contained in the enum IPT_ICMP_ADMIN_PROHIBITED Either way, I don't see any bugs from my POV (yet). Imagine the following case: Old kernel, new iptables userspace: Somebody inserts a rule with the new admin_prohibited flag. The old REJECT module doesn't trigger any of the case statements, resulting in a plain DROP. This is not a very big problem, if it is clearly documented. However, I still don't like this kind of hard-to-debug hidden stuff. Brad -- 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+(*)
Re: iptables-restore issue
On Mon, Apr 29, 2002 at 11:38:49AM -0700, Ted Bannon wrote:
I have some rules which work fine when entered at the command line with
iptables, but iptables-restore complains about some but not all of them.
Here are the rules:
# allow outbound ICMP echo request and inbound ICMP echo replies
-A OUTPUT -s 192.168.29.25/32 -p icmp --icmp-type echo-request -d 0.0.0.0/0
-j ACCEPT
-A INPUT -s 0.0.0.0/0 -p icmp --icmp-type echo-reply -d 192.168.29.25/32 -j
ACCEPT
# allow inbound ICMP echo requests and outbound ICMP echo replies
-A INPUT -s 0.0.0.0/0 -p icmp --icmp-type echo-request -d 192.168.29.25/32
-j ACCEPT
-A OUTPUT -s 192.168.29.25/32 -p icmp --icmp-type echo-reply -d 0.0.0.0/0
-j ACCEPT
This is the error:
[root@engtest0 sysconfig]# /etc/init.d/iptables start
Flushing all current rules and user defined chains:[ OK ]
Clearing all current rules and user defined chains:[ OK ]
Applying iptables firewall rules: [ OK ]
iptables-restore v1.2.6-20020226: Unknown arg `--icmp-type'
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
I've now prepared a patch (attached to this email) which solves the problem.
As far as I can see, removing the two lines shouldn't break anything else.
So if your problem is resolved after using this patch, I will commit it to
CVS.
Ted
--
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+(*)
--- userspace/iptables.c.oldMon Mar 25 09:30:31 2002
+++ userspace/iptables.cThu May 2 16:40:07 2002
@@ -2054,8 +2054,6 @@
actually hear this code suck. */
if (m == NULL
protocol
-!find_proto(protocol, DONT_LOAD,
- optionsOPT_NUMERIC)
(m = find_proto(protocol, TRY_LOAD,
optionsOPT_NUMERIC))) {
/* Try loading protocol */
Re: placement of postrouting
On Thu, Apr 25, 2002 at 10:41:52AM -0700, Don Cohen wrote: My impression (please correct me if I'm wrong) is that pre is supposed to catch packets coming into the box and post is supposed to catch those going out. I believe postrouting currently happens before a packet is queued for output. I think it would be better to delay this until after it is dequeued. This would improve accuracy. In particular, the packets that are dropped in queuing should not be processed as outgoing. I'm interested in hearing any counter arguments, and especially things that would be broken by this change. the counter argument is that the queue is part of the lower-layer drivers and not part of the IPv4 stack. netfilter hooks are always restricted to one protocol stack - there's separate hooks for ipv4, ipv6, ipx, ... BTW, I'm trying to find out by reading the code, but it would help if I could just find some documentation, or for that matter if someone would just tell me the answers. What code is actually run at which places? At the moment I'm mostly interested in conntrack and nat. I understand why dnat has to be done pre-routing. I don't see why snat couldn't also be done there. theoretically, yes. but then you wouldn't be able to match on the original source of the packet anymore (imagine the standard masquerading case, you wouldn't be able to distinguish your individual clients, because all the source adresses have already been overwriten). It occurs to me that when you start taking drops into account, conntrack could/should really track at least two different states, and maybe more. The real question is what states the two different ends of the connections could be in. This is an extremely complex situation, and the connection tracking code cannot assume that a packet seen by the packet filter will ever arrive at the receiver. The packets that come in show something about the state the sender was in when it sent those packets, the packets that go out tell us something about what states the receiver could be in after receiving them (if it does receive them). Any pointers to discussion of these issues are appreciated. Not sure if there was any public discussion about this. As you are talking about TCP, maybe Jozsef Kadlecsik (who has done a lot of state trackin improvements by writing the window tracking code) is the best to discuss this in case you have any questions. There is no doubt you can increase TCP state tracking as soon as you do window / sequence number tracking. But without, I don't see how you could do any better [in terms of security] than we do. You can represent the state more verbously - but without any practical implications for security, there is no other than academic interest in this. -- 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+(*)
Re: placement of postrouting
On Fri, Apr 26, 2002 at 09:52:46AM -0700, Don Cohen wrote: Harald Welte writes: the counter argument is that the queue is part of the lower-layer drivers and not part of the IPv4 stack. netfilter hooks are always restricted to one protocol stack - there's separate hooks for ipv4, ipv6, ipx, ... This seems more a psychological than technical argument. Is there some reason the lower level can't be interleaved in execution order with the upper level? Or is it more related to the files? You want NF_HOOK to be called by ip_output but not by dev.c ? IP tables are restricted to IPv4. IP6tables are restricted to ipv6. arptables are restricted to arp. So you want to have a big case statement _after_ enqueuing of the packet happens [ i.e. in the network TX softirq], calling NF_HOOK for the respective protocol family? This raises another general point. There are lots of cases where a certain thing has to be done in a certain place cause that's where the data is available. At the moment, there are things that just can't be done cause they require two pieces of data that are not both available at the same time, e.g., input device and output device. When you want to do something like that you end up adding kernel code to save the old data so you can use it later. I think in general it would be worth while to save more of this data for use in later hooks. So I think that nat should save the original data just for use in later hooks. well, but it's added overhead and none of the existing functions within the framework need it. If there is any chance for adding such overhead, then if at the same time we actually have some code which uses it. Just providing features because they are nice for some not-included-in-kernel code is not our philosophy. -- 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+(*)
Re: [PATCH] IPv6 AH, ESP, frag fix
On Sun, Apr 21, 2002 at 11:55:37PM +0200, Andras Kis-Szabo wrote: Hi, AH, ESP: - added length check in the iteration phase - added length check in the interpreter frag: - added length check in the iteration phase thanks, applied. Regards, kisza -- 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+(*)
Re: [PATCH] IPv6 routing hdr match + some fixes
On Mon, Apr 22, 2002 at 03:42:07AM +0200, Andras Kis-Szabo wrote: Hi, ChangeLog: Thanks again, applied. Regards, kisza -- 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+(*)
Re: ip_masq_pptp
On Wed, Apr 24, 2002 at 08:50:50AM +0100, Phil Roberts wrote: Dear Sirs Under Kernel 2.2 kernel and using ipchains, I used insmod ip_masq_pptp, this was so I could use PPTP from a workstation behind the firewall to contact a PPTP Server across the Internet, i have searched for weeks for this module for IPTABLES is it not needed or has it not yet been written. You have searched weeks? Well, please search for ip_conntrack_pptp respectively ip_nat_pptp which we've had two different implementations of: one old, included e.g. in iptables-1.2.6a one new (for newnat), in current patch-o-matic CVS BTW: ip_masq_pptp was never included into the mainstream kernel source, IIRC. Phil Roberts -- 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+(*)
Re: debug and notrack tables - proposal and questions
On Fri, Apr 19, 2002 at 03:21:40PM +0200, Jozsef Kadlecsik wrote: On Wed, 17 Apr 2002, Harald Welte wrote: 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. Hm. Are you thinking on logging when say a conntrack/nat helper generates/detects an expectation? That, too - but that wasn't what I'm thinking of. I'm more thinking of 'DST IP address changed from x to y' 'SRC Port changed from a to b' At the time the NAT manipulations happen in PRE_ROUTING/POST_ROUTING 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? What about something neutral: 'select' table I.e 'select' table for debugging packets, conntrack exemptions, early dropping of spoofed packets, unclean ones, DoS protection, etc. Mh, let's name it 'select' until we have better ideas ;) 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+(*)
Re: [PATCH] Trivial PPTP conntrack typo fix (was: RE: ip_nat_pptp)
On Fri, Apr 19, 2002 at 04:28:13AM +0200, Sneppe Filip wrote: Hi Harald, ... a typo in the Makefile patch prevented the ip_conntrack_pptp module from compiling, see Robert's mail to the Netfilter list. thanks, patch applied Regards, Filip -- 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+(*)
Re: debug and notrack tables - proposal and questions
On Thu, Apr 18, 2002 at 08:22:57AM +0200, Patrick Schaaf wrote: Hi Joakim all, We (me and Martin) has discussed a table, border, that is the absolutly first thing that is being travered after leaving the netcard driver. I like the idea (a lot!), as well as the placement, but I'm not really fond of the name. May I suggest one of two things? A) Call the table netdev, with chains RX and TX B) Call the table filter, with chains RX and TX RX/TX could alternatively be RECEIVE/TRANSMIT, if they seem to short. however, this would clearly violate layering. IPtables is about IP packets, not about ARP, IPX, IPv6, and some other weird stuff going on on the network interface. best regards Patrick -- 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+(*)
Re: [SUGGESTION] ECN match/target
On Wed, Apr 17, 2002 at 09:42:08AM +0200, Oskar Andreasson wrote: On Tue, Apr 16, 2002 at 01:57:27PM +0200, Oskar Andreasson wrote: Hi all, I have a brief suggestion for a match/target which I am unable to to write myself of many reasons, mainly that I am a very very lousy coder =). If someone is already working on this, disregard from this mail. What I would like to propose is an ECN match/target. http://cvs.samba.org/cgi-bin/cvsweb/netfilter/userspace/extensions/libipt_ECN.c My fault, I never found that part in 1.2.6a but it should be there if I am not wrong after reading through this. One stupid question however.. where is the kernel side implementation of this target? It hasn't been released yet. I have written the dscp match/target in combination with the ECN matcht/target. However, the code for ECN ist still not complete. Expect it to be ready soon (have to submit three pending bug- fixes before). Only touchin the IP haeder is not a good idea, as ECN works in combination with the transport layer (i.e. TCP). Makes sense to me=) I hadn't actually come to the part of the RFC so far, my mistake. I've made the same mistake initially, as can be seen in the list archives. So... one more question then, is there such a (ECN) match that I have missed as well? as stated above, give me a couple of more days Have a nice day, Oskar Andreasson -- 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+(*)
Re: [SUGGESTION] ECN match/target
On Tue, Apr 16, 2002 at 08:45:20AM -0700, Brad Chapman wrote: Harald Welte wrote an ECN target a few weeks ago and then got rid of it because of a b0rKed design. I think DSCP does everything your ECN target/match can do, and I think it does more as well (not sure about this). Perhaps if your ECN target has a better design than Harald's, maybe he'll use yours ;) no, DSCP and ECN together replace TOS. Brad -- 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+(*)
[PATCH] netfilter conntrack/nat ICMP bugfix 2.4.x
@@ if (!ipc.addr) ipc.addr = rt-rt_dst; err = ip_build_xmit(sk, sk-protinfo.af_inet.hdrincl ? raw_getrawfrag : - raw_getfrag, rfh, len, ipc, rt, msg-msg_flags); + raw_getfrag, rfh, len, ipc, rt, msg-msg_flags, + NULL); done: if (free) diff -urN linux-2.4.19-pre6.orig/net/ipv4/udp.c linux-2.4.19-pre6-nf-01/net/ipv4/udp.c --- linux-2.4.19-pre6.orig/net/ipv4/udp.c Sun Apr 7 15:27:29 2002 +++ linux-2.4.19-pre6-nf-01/net/ipv4/udp.c Fri Apr 12 00:52:32 2002 @@ -548,7 +548,7 @@ (sk-no_check == UDP_CSUM_NOXMIT ? udp_getfrag_nosum : udp_getfrag), - ufh, ulen, ipc, rt, msg-msg_flags); + ufh, ulen, ipc, rt, msg-msg_flags, NULL); out: ip_rt_put(rt); -- 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+(*)
Re: debug and notrack tables - proposal and questions
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_MASK0x07 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
Re: debug and notrack tables - proposal and questions
On Wed, Apr 17, 2002 at 09:21:03PM +0200, Hervé Eychenne wrote: On Wed, Apr 17, 2002 at 09:09:11PM +0200, Harald Welte wrote: 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 Why not simply PRETRACK, or PRECONNTRACK ? It would be coherent with the existing naming... PRETRACK for which of the three? You are writing uppercase so it can only be the state name or the target name. A state name of PRETRACK doesn't make sense to me. PRETRACK references to a location, not to a state. Same with the target name. RV -- 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+(*)
[PATCH] bugfix for ipt_ULOG module
Hi Dave!
Unloading ipt_ULOG can cause kernel oops if some timers are still pending
while module unload happens.
The following patch fixes this bug.
Please apply,
Thanks
--- linuxppc-benh-100402-plain/net/ipv4/netfilter/ipt_ULOG.cSat Apr 6 12:30:04
2002
+++ linuxppc-benh-100402-ulog/net/ipv4/netfilter/ipt_ULOG.c Tue Apr 16 09:33:00
+2002
@@ -29,7 +29,7 @@
* Specify, after how many clock ticks (intel: 100 per second) the queue
* should be flushed even if it is not full yet.
*
- * ipt_ULOG.c,v 1.15 2002/01/18 21:33:19 laforge Exp
+ * ipt_ULOG.c,v 1.18 2002/04/16 07:33:00 laforge Exp
*/
#include linux/module.h
@@ -339,10 +339,28 @@
static void __exit fini(void)
{
+ ulog_buff_t *ub;
+ int i;
+
DEBUGP(ipt_ULOG: cleanup_module\n);
ipt_unregister_target(ipt_ulog_reg);
sock_release(nflognl-socket);
+
+ /* remove pending timers and free allocated skb's */
+ for (i = 0; i ULOG_MAXNLGROUPS; i++) {
+ ub = ulog_buffers[i];
+ if (timer_pending(ub-timer)) {
+ DEBUGP(timer was pending, deleting\n);
+ del_timer(ub-timer);
+ }
+
+ if (ub-skb) {
+ kfree_skb(ub-skb);
+ ub-skb = NULL;
+ }
+ }
+
}
module_init(init);
--
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+(*)
Re: building 1.2.6a bugs
On Tue, Apr 16, 2002 at 11:21:58AM +0200, Joachim Schwender wrote: changing the PREFIX: in the main Makefile does not compile correctly, as there is another definition in the file iptables.c, line 43: IPT_LIB_DIR this definition is only getting active if IPT_LIB_DIR is not defined. which is not defined in the main Makefile. The definition in the Makefile is similar and this seems to be a bug: IPT_LIBDIR no. see about line 100 in the Makefile: $(CC) $(CFLAGS) -DIPT_LIB_DIR=\$(IPT_LIBDIR)\ -c -o $@ $ please don't mix up Make variables and C preprocessor definitions. compiling with a changed PREFIX generates binaries that still search the modules in /usr/local/iptables. This needs to be some strange interaction on your system. I'm regularly using this feature (as are most of the SPEC files I've seen for iptables). --- Another issue is that the compiler (or some subordinated program) complains about syntax in /extensions/owner.c, line 23, a macro cannot be used inside a printf function. --- compiler: gcc 3.0.4, on Linux libc 2.2.2, Kernel 2.4.18 this is a known issue with gcc3 (which is not really considered a standard compiler on linux systems yet). The 'bug' has been fixed in CVS recently. -- 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+(*)
Re: [PATCH] icmp type-3-code-13 for REJECT
On Mon, Apr 15, 2002 at 11:29:07AM +0800, Fabrice MARIE wrote: Hello, On Monday 15 April 2002 08:46, Brad Chapman wrote: Mr. Harald, Thanks for the patch. Unfortunately it's not that easy. Writing the 10-line patch is smallest part of the job. The interesting question is: How to achieve backwards- and forwards-compatibility for - making old kernel work with new iptables (easy) - making new kernel work with old iptables (easy) - make new iptables compile with old kernel headers - make old iptables compile with new kernels (easy) Whoops - I completely forgot about that :( Unfortunately, I don't know how to do that, or I would have done it. Is it just basically a bunch of #ifdefs, or is there additional magic involved? I can remake the patch if required. Well the easy solution is to have a userspace patch (see the trivial If I'm not mistaken, in case of REJECT it should be possible to do without a userspace patch - which is really starting to make things weird. There is no real change in the structure layout, it's just one additional value that is becoming valid... Fabrice. -- 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+(*)
Re: list of available matches and targets through /proc
On Sun, Apr 14, 2002 at 01:02:32AM -0400, Zygo Blaxell wrote: In article [EMAIL PROTECTED], Harald Welte [EMAIL PROTECTED] wrote: On Wed, Apr 10, 2002 at 09:36:05PM -0400, Zygo Blaxell wrote: I think that the user-space modules should provide much richer version information than a simple version number. Simple version numbers are useless if there are multiple maintainers each extending the code in different ways and distributing it before it is officially integrated (i.e. the status quo for netfilter and indeed most of the Linux kernel). Where did you get this idea from? Please point me to a single occation where any part of iptables was modified in different ways by different 'maintainers'? Sure...the module net/ipv4/netfilter/ip_conntrack_standalone.c was modified in different ways by Gerd Knorr, Henrik Nordstrom, Jay Schulist, Harald Welte, Jozsef Kadlescik, Rusty Russell, and Various Artists. Some of these modifications change kernel-to-user communication mechanisms (note I include renaming or reformatting things under /proc here), most change internal kernel-to-kernel API's, or cause failure to build, or cause failures in other patches. I was explicitly talking about _iptables_, namely iptables extensions (ipt_XXX.o and their respective counterparts libipt_XXX.so and their userspace api exposed via the iptabels commandline utility). btw: The connection tracking changes you have mentioned all occurred sequentialy, whereas your original statement was suggesting that they had been modified at the same time and different versions were distributed at the same time. And please don't refer to some development stages. Code which is under active development (and has not been officially released by submission to the mainstream kernel) is subject to code fluctutation. I don't see anything In addition to the CVS tree there are other large distributors of netfilter--the Linux kernel and all of its derivative flavours (some of which you mostly control) and all the different Linux distributors who are now packaging this stuff. Suppose some Linux distributor is insane enough to package netfilter with non-default patch/compile options (oops, too late, Red Hat already did this), and the distro people throw in some of their own patches that are not in your CVS because they haven't submitted them yet, or their patches were submitted but you've rejected them. This is a general problem with free software in general. I have to admit that I am not very lucky with the behaviour of distributors with regard to this. It would not be difficult to implement version checking module by module, since the extensible part of kernel/userspace communication is just passing arbitrary struct's back and forth. Add a struct member for version and check it whenever the struct is received at both ends. Well, that might be suitable if we'd be taliking about 2.5.x - but we certainly cannot make this change during 2.4.x, because it would break all compatibility to old versions of the iptables commandline utility. As already stated (and documented in the devel meeting proceedings), 2.5.x will see a major redesign of the iptables structures anyway - and versioning is definitely a design criteria. Ah, iptables2 would be the code I never bother to look at as I'm too busy banging on the parts of netfilter I'm actually trying to use. ;-) :) well, there's a lot of recent work on libiptables, which i haven't committed to CVS yet, since it is not in a state where it even compiles. I wonder if there has been some thought to what happens to e.g. a GUI config tool when new options to an iptables module are added. Will there be a backward-compatible mechanism that can be used if the GUI finds a data type newer than itself? The GUI can query libiptables about available plugins and their options. Everything behind is covered by libiptables. The Applications _must not_ make any assumption on which options are present and what data types they use. Everything needs to be read via libiptables at runtime. With libiptables (as soon as it is fully implemented) it is possible to write a GUI (or any other application) which doesn't know anything about individual matches/targets, their options, data types or help messges. The application does not need to be modified if a new match/target is written. Please see the README file, it gives some basic idea... Zygo Blaxell (Laptop) [EMAIL PROTECTED] -- 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+(*)
Re: nating netlogon (NT domain) packets?
On Thu, Apr 11, 2002 at 10:15:46PM +0200, Rönnblom Janåke /Teknous wrote: I want to be able to to logon to my NT domain from behind my NAT box. I have win9x workstations that are connected to the internet through a linux machine which uses NAT. These win9x machines need to be able to login to the Active Directory (NT domain) which is located at another site, both which are connect to each other through the internet. First of all, you should use some VPN with encryption when passing such traffic over the internet. As I understand there is no extension in netfilter today that support NetLogon traffic. Is there such an extension in planning? No, there is no module and there are no plans for a module. How much work would be involved in creating such an extension? Are we talking about weeks, months or only days? definitely days, certainly less than one week. http://support.microsoft.com/default.aspx?scid=kb;EN-US;q172227 http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q263293 Janåke Rönnblom -- 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+(*)
Re: list of available matches and targets through /proc
On Wed, Apr 10, 2002 at 09:36:05PM -0400, Zygo Blaxell wrote: I think that the user-space modules should provide much richer version information than a simple version number. Simple version numbers are useless if there are multiple maintainers each extending the code in different ways and distributing it before it is officially integrated (i.e. the status quo for netfilter and indeed most of the Linux kernel). ? Where did you get this idea from? Please point me to a single occation where any part of iptables was modified in different ways by different 'maintainers'? The netfilter/iptables project has five maintainers, the core team members. And we have a single point for distributing code changes: the CVS tree. If the user-space and kernel-space modules check the version string, there is no danger of my user-space module being accidentally used to configure your kernel-space module (nor any unpredictable consequences that might arise from such a mixture). I'm pretty sure iptables already does this, although not everyone patches the version string when they make incompatible changes... Please look on how the current model of iptables kernel/userspace communication works. It is very primitive, and there is no way of passing such information back and forth. Back to user-space. The information you get from iptables about a module should be something like what you get from --help, but more machine-readable. Perhaps: # iptables -m state --option-list would output a list of: [...] This is basically what libiptables is supposed to export via it's API to iptables2. Please look at the 'iptables2/libiptables/README' file in CVS and/or read the respective code. Zygo Blaxell (Laptop) [EMAIL PROTECTED] GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD -- 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+(*)
Re: [CORRECTION] AF,EF patch
On Wed, Apr 10, 2002 at 05:01:14PM +, [EMAIL PROTECTED] wrote:
Woops sorry,
Missed a couple of return statements from the last patch
Here is a fixed one.
I've made a couple of other changes (untested):
- move EF and BE into struct ds_class list
- add missing IANA-assigned CSxx codepoints
This code is now in CVS.
diff -u -r1.2 libipt_DSCP.c
--- libipt_DSCP.c 2002/02/17 21:28:51 1.2
+++ libipt_DSCP.c 2002/04/11 10:48:27
@@ -7,6 +7,7 @@
*
* libipt_DSCP.c borrowed heavily from libipt_TOS.c
*
+ * --set-class added by Iain Barnes
*/
#include stdio.h
#include string.h
@@ -17,6 +18,40 @@
#include linux/netfilter_ipv4/ip_tables.h
#include linux/netfilter_ipv4/ipt_DSCP.h
+
+/* see http://www.iana.org/assignments/dscp-registry */
+
+static struct ds_class
+{
+ char *class;
+ unsigned int dscp;
+} ds_classes[] =
+{
+ { CS0, 0 },
+ { CS1, 0x08 },
+ { CS2, 0x10 },
+ { CS3, 0x18 },
+ { CS3, 0x18 },
+ { CS4, 0x20 },
+ { CS5, 0x28 },
+ { CS6, 0x30 },
+ { CS6, 0x38 },
+ { BE,0 },
+ { AF11, 0x0a },
+ { AF12, 0x0c },
+ { AF13, 0x0e },
+ { AF21, 0x12 },
+ { AF22, 0x14 },
+ { AF23, 0x16 },
+ { AF31, 0x1a },
+ { AF32, 0x1c },
+ { AF33, 0x1e },
+ { AF41, 0x22 },
+ { AF42, 0x24 },
+ { AF43, 0x26 },
+ { EF, 0x2e }
+};
+
static void init(struct ipt_entry_target *t, unsigned int *nfcache)
{
}
@@ -28,11 +63,18 @@
--set-dscp valueSet DSCP field in packet header to value\n
This value can be in decimal (ex: 32)\n
or in hex (ex: 0x20)\n
+ --set-class class Set the DSCP field in packet header to the value\n
+ represented by the DiffServ class value.\n
+ This class may be EF,BE or any of the CSxx
+ or AFxx classes.\n
+\n
+ These two options are mutually exclusive !\n
);
}
static struct option opts[] = {
{ set-dscp, 1, 0, 'F' },
+ { set-class, 1, 0, 'G' },
{ 0 }
};
@@ -53,6 +95,24 @@
return;
}
+
+static void
+parse_class(const unsigned char *s, struct ipt_DSCP_info *dinfo)
+{
+ int i;
+
+ for (i = 0; i sizeof(ds_classes) / sizeof(struct ds_class); i++) {
+ if (!strncasecmp(s, ds_classes[i].class,
+ strlen(ds_classes[i].class))) {
+ dinfo-dscp = (u_int8_t)ds_classes[i].dscp;
+ return;
+ }
+ }
+
+ exit_error(PARAMETER_PROBLEM, Invalid DSCP class value '%s', s);
+}
+
+
static int
parse(int c, char **argv, int invert, unsigned int *flags,
const struct ipt_entry *entry,
@@ -67,6 +127,13 @@
exit_error(PARAMETER_PROBLEM,
DSCP target: Only use --set-dscp ONCE!);
parse_dscp(optarg, dinfo);
+ *flags = 1;
+ break;
+ case 'G':
+ if (*flags)
+ exit_error(PARAMETER_PROBLEM,
+ DSCP target: Only use --set-class ONCE!);
+ parse_class(optarg, dinfo);
*flags = 1;
break;
Iain
--
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+(*)
Re: Thank you for your attention
On Wed, Apr 10, 2002 at 01:07:20PM +0900, LeeHojae wrote: I'm really thank you for your attention. No problem, I always want to improve netfilter/iptables. And your xdmcp conntrack/nat helper is a nice extension, really. I'm ashamed of my poor coding No problem, it's your first netfilter/iptables contribution, and everybody has to learn in the beginning :) If right, Please send me the modified code. I will send it as soon as I got around testing it. I wish good luck to you... Thanks. There is another, security-relevant issue of your code: It doesn't track the state of the XDMCP protocol, so everybody could just send fake MANAGE packets an thus cause holes in the firewall/NAT to be opened. I'm now trying to track the REQUEST/ACCEPT hanshake before accepting a MANAGE packet. This way we know if the Server has allowed the Display to be managed by the Server. -- 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+(*)
[ruben.unteregger@siemens.com: feature]
this belongs here -- 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+(*) ---BeginMessage--- hi netfilter team i have not found a bug, no support is needed and i wont ask you questions concerning configuration and so. i rather have a suggestion for a feature that probably could be interesting. because it dont read your list, forgive me if someone else proposed you already that idea. the packetfiltering mechanism works from top sequentially down and checks if a rule can be triggerd. for performance reasons, you have to know, what rules get triggerd more often than others an put them to a higher position in the rulebase in a certain domain, where the order of the rules doesnt matter. wouldnt it be useful if you can create a domain in the rulebase and count how often a rule gets triggered and put these rules in a optimised order? just an idea regards ruben unteregger ---End Message---
Re: list of available matches and targets through /proc
On Wed, Apr 10, 2002 at 02:06:24PM +0200, Hervé Eychenne wrote:
Yes, but when some existing modules will go into the kernel, some
other modules will have been created, waiting for validation.
Seems like a never ending story...
Well, alternatively we can also stop all new development ;)
Yes, but how do you know at runtime that a particular feature
(provided by a patch-o-matic module) is usable?
by telling the user about the prerequisites and let him apply
the necessarry patches. If you tell him to apply a patch which is
already in the kernel, patch-o-matic will detect that it is already
applied.
What's why I suggest a mechanism which would provide the list of
currently available matches and targets, with their API (regarding options)
versions. /proc seems to be a good candidate.
Well, we could only list the currently loaded matches/targets, which can
be read out by parsing 'lsmod' anyway. (assuming that all matches/targets
are modules).
Too many assumptions for me here too.
What about statically compiled netfilter modules?
I said that this is not covered (assuming that all matches/targets are modules).
How to recognize netfilter modules by their names?
ipt_
How to differentiate matches from targets?
matches are lowercase, targets uppercase. This is reliable, since even
iptables does rely on it (for module autoloading).
But having something like /proc/net/ipv4/netfilter/{match,target}_names
would be a nice contribution, and definitely be welcome :)
I may not have the time to do it myself, so I just talked about the
idea to see if someone would have my time instead of me. ;-)
BTW, what about netfilter modules that have been compiled as kernel
modules, but still not loaded? Is there any other way than trying to
insmod them to see if they are available? (ugly)
find /lib/modules/`uname -r`/kernel/net/ipv4/netfilter -name ipt_.o
Would it be acceptable that this /proc thing should provide a way to inform
that a netfilter module has been compiled as a kernel module (even if not
inserted at the time the cat /proc/net/ipv4/netfilter/{match,target}_names
is done)?
No, at least not for me. What is the purpose of a modular kernel, if
the kernel image needs to know which modules are there? People should be
able to compile new kernel modules seperately.
I, for example, regularly just rebuild kernel modules after reconfiguration,
and not the kernel image itself (like 'make modules
SUBDIRS=net/ipv4/netfilter').
The kernel modules don't know anything about commandline-options of
iptables - and this is by design, since this doesn't belong into the kernel.
Yes, but we can assume there's a direct mapping between user-visible
functionnalities brought by a kernel netfilter module and its
userspace counterpart, and so the API of the latter too, I guess.
There is no 'api'. It's just some structures. And the compiled
code doesn't even know about the name of the struct members, since
everything gets compiled into adresses and offsets.
But I conceptually agree that it is not a good thing to store
userspace API version in the kernel even if there's a bijection.
So, why not consider adding an API version switch to every userspace
module, then?
I was suggesting to add versioning to 2.5.x - but right now I have
different, more basic stuff on my 2.5.x todo list. Like abstracting
ip_tables into pkt_tables, creating new netlink-based userspace interface,
etc.
(°= Hervé Eychenne
--
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+(*)
Re: [PATCH] LOG target @ tunnel interfaces (SIT only)
On Tue, Apr 02, 2002 at 11:54:50PM +0200, Andras Kis-Szabo wrote: Will You be so kind as to test the patch If you have got tunnel interface (or native conenction)? ip6tables -A INPUT -j LOG any news on this patch so far? Any test reports? Regards, kisza -- 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+(*)
Re: [Fwd: Re: IPv6 MAC logging buggy bei Tunnel-Interfaces?]
On Tue, Jan 01, 2002 at 01:03:13AM +0100, Andras Kis-Szabo wrote: -Forwarded Message- From: Peter Bieringer [EMAIL PROTECTED] To: Harald Welte [EMAIL PROTECTED] Cc: Andras Kis-Szabo [EMAIL PROTECTED] Subject: Re: IPv6 MAC logging buggy bei Tunnel-Interfaces? Date: 05 Apr 2002 21:37:05 +0200 Hi again, sorry for my test delays, I'm currently not so fast... No problem at all :) I was just wondering if testing was already done :) but good news: latest patch works! nice. Now only some questions: 1) MAC address difference between v4 and v6: MAC=00:50:bf:06:b4:f5 00:d0:d3:a5:6e:d9 MAC=00:50:bf:06:b4:f5:00:d0:d3:a5:6e:d9:08:00 what mean the :08:00 on v4? this is the layer3 protocol number (08:00 means ipv4). kisza: we should use the same format for MAC address everywhere. Even on tunnels it should read MAC=00:50:bf:06:b4:f5:00:d0:d3:a5:6e:d9:08:00 2) TUNNEL addresses Exists there any problem about printing two vars separated by space? Don't know how current log parser working, but can be cause a problem. Perhaps better: TUNNELIPV4LOCAL= TUNNELIPV4REMOTE= Yes, thanks for this hint. kisza: please change it to some shorter names, could be SITSRC and SITDST or something like this. Kernel sources: RHL 2.4.18-0.4 Peter -- 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+(*)
Re: I've mad nat/conntrack xdmcp moduel, how distribute?
On Tue, Apr 09, 2002 at 03:22:05PM +0900, XX wrote: I made NAT/conntrack module for xdmcp But I don't know how to distribute... something like patch-o-matic..but I don't know.. Please send me a unified diff (diff -Nru linux-clean linux-xdmcp) of the whole kernel tree. I'll have a look at the code and then convert it to patch-o-matic. Thank you.. -- 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+(*)
Re: (no subject)
On Tue, Apr 09, 2002 at 03:26:32PM +0900, ÀÌÈ£Àç wrote: I made NAT/conntrack module for xdmcp I've now had a look at the code. There are a couple of issues: 1. the display number NAT stuff (mistakenly named free_port_xxx functions) doesn't belong into the conntrack module, but in the NAT module. 2. /usr/src/linux/Documentation/CodingStyle is not used throughout the code 3. the helpers are written 4. the modules are missing MODULE_LICENSE(GPL) tags 5. the modules have the same 'ports_c' bug like old versions of the ftp helper 6. the modules are written for the old conntrack/nat API, whereas newnat is now considered standard. 7. UDP checksumming !! 8. The IP checksum is recalculated from scratch rather than using incremental checksumming. This results in corrupted packets traveling through nat getting a correct checksum - the receiver cannot discover data corruption. I'm currently resolving all those issues and will include the corrected code into netfilter patch-o-matic. But I don't know how to distribute... -- 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+(*)
Re: [UPnP-SDK-discuss] UPNP Server/Application Gateway for Linux
On Sun, Apr 07, 2002 at 03:48:26PM +0200, Henrik Nordstrom wrote: On Sunday 07 April 2002 12:07, Brian J. Murrell wrote: Dynamically inserting/removing rules seems like a big hack, but not like a solution. Why? I thought that userspace solutions were _always_ considered the better way(tm) to do things when possible. What is a better solution to UPnP than a userspace daemon manipulating netfilter rules? How I understood Harald is that he do not regard a userspace daemon who dynamically changes the iptables ruleset as the correct approach, but the correct approach rather a userspace daemon who directly insert new connection tracking/NAT session entries as being the correct approach. Exactly, that was what I meant. Dynamically changing the iptables ruleset is evil, because: 1) if some admin is reloading the iptables rules, the dynamically inserted are gone 2) inserting rules at a particular rule number (-I foobar 12) will become unreliable, because in the meantime the upnp-daemon could have inserted other rules which resulted in rule-renumbering. 3) inserting/removing single rules very often is extremely expensive within current iptables implmentation - see discussions about iptnetlink to read why. Perhaps you prefer the UPnP daemon to act more like a true application proxy and do application level forwarding to satisfy the requests made of it? This may also be an possibility, but not as efficient or flexible, and I don't think this is how UPnP can be used. Also I don't think this is anywhere close where Harald was aiming. well, it wouldn't have any relation to netfilter then. A pure application layer proxy is outside the scope of netfilter - and I'm interested in a netfilter solution, of course :) Regards Henrik Nordström -- 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+(*)
