Re: Fixed Newnat13+h323+...-all-in-1-Patch

2002-04-17 Thread Jozsef Kadlecsik
On Wed, 17 Apr 2002, Javor Marinov wrote: ok oks , this patch is apply to the kernel source and compiling whith small warnings , so now its good , What are those small warnings, exactly? BUT I GET THE KERNEL DUMP Apr 10 02:09:48 NAT-Router-9 kernel: Unable to handle kernel NULL pointer

Re: [SUGGESTION] ECN match/target

2002-04-17 Thread Oskar Andreasson
Hi Brad, snip for brevity 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

Re: [SUGGESTION] ECN match/target

2002-04-17 Thread Oskar Andreasson
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.

Re: [SUGGESTION] ECN match/target

2002-04-17 Thread Harald Welte
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

Re: [SUGGESTION] ECN match/target

2002-04-17 Thread Harald Welte
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

Re: [SUGGESTION] ECN match/target

2002-04-17 Thread Oskar Andreasson
Hi Harald et al, Huge thanks for all of the replies, and sorry for any inconvinience for asking for a target already in production =). I will be very interested in seeing this target reach the CVS tree, as well as a ECN match if this is possible to implement in the future. Have a nice day,

[PATCH] netfilter conntrack/nat ICMP bugfix 2.4.x

2002-04-17 Thread Harald Welte
Hi Dave! Unfortunately we've again discovered a bug within netfilter. This time it's about the handling of ICMP error messages that are created on the firewall itself. I'll describe the two problems, so you can understand why there are changes to the ipv4 networking code. 1) ICMP errors for

Re: [PATCH] netfilter conntrack/nat ICMP bugfix 2.5.x

2002-04-17 Thread James Morris
On Wed, 17 Apr 2002, Harald Welte wrote: This is the same bugfix as in my previous mail, this time for 2.5.x: Patch again by James Morris. Actually, Rusty developed the sections of the patch which deal with unconfirmed connections. - James -- James Morris [EMAIL PROTECTED]

Re: Suggestions regarding multiport match and chain traversing

2002-04-17 Thread Norbert Sendetzky
On Wednesday 17 April 2002 15:20, you wrote: As usually with all modifications of matches/targets, there is the compatibility issue: - old iptables userspace needs to work with new kernel mport - new kernel mport needs to work with old kernel mport This shouldn't be a problem

Re: Suggestions regarding multiport match and chain traversing

2002-04-17 Thread Joakim Axelsson
2002-04-17 18:33:45+0200, Norbert Sendetzky [EMAIL PROTECTED] - On Wednesday 17 April 2002 15:20, you wrote: Now the questions: Can the memory area passed to the kernel be greater than 32 bytes and if not, can I limit the number of port ranges in the new multiport version to 7 instead of

Re: Suggestions regarding multiport match and chain traversing

2002-04-17 Thread Norbert Sendetzky
On Wednesday 17 April 2002 19:47, you wrote: I hope you mean the struct you are sending all the data in to the kernel. Just make the struct larger. It's not a problem. Is the struct ipt_mulitport allocated by ip_tables before the functions are called? However, make sure the struct looks the

Re: debug and notrack tables - proposal and questions

2002-04-17 Thread Harald Welte
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

Re: debug and notrack tables - proposal and questions

2002-04-17 Thread Harald Welte
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

Netfilter Routing (device redirection)

2002-04-17 Thread Robert Joyce
Hello, I am currently trying to grab multicast packets off one ethernet interface, do some processing on them, and then pass them out another different interface. Thus I was wondering what functionality exists in netfilter/iptables to accomplish this (any insight also appreciated).

Re: debug and notrack tables - proposal and questions

2002-04-17 Thread Hervé Eychenne
On Wed, Apr 17, 2002 at 09:21:30PM +0200, Harald Welte wrote: 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

Re: debug and notrack tables - proposal and questions

2002-04-17 Thread Brad Chapman
--- Martin Josefsson [EMAIL PROTECTED] wrote: On Wed, 2002-04-17 at 12:58, Jozsef Kadlecsik wrote: [big snip] 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

[PATCH] Suggestions regarding multiport match

2002-04-17 Thread Norbert Sendetzky
On Wednesday 17 April 2002 15:20, Harald Welte wrote: please feel free to provide us with an implementation that is fullfilling the above requirements. The current mport.patch in patch-o-matic doesn't. And suddenly it's done ;-) I've extended the existing multiport module to support the

[PATCH] multiport match ipv6

2002-04-17 Thread Norbert Sendetzky
Greetings This is another patch for the mulitport module, but for IPv6. Like the patch for IPv4 it adds the mport semantic to multiport (possibility to add not only single ports but also port ranges). It should work, but I havn't tested the code simply because I don't use IPv6 (yet) :-( Please

Re: debug and notrack tables - proposal and questions

2002-04-17 Thread Joakim Axelsson
2002-04-17 21:16:40+0200, Harald Welte [EMAIL PROTECTED] - On Wed, Apr 17, 2002 at 05:20:36PM +0200, Martin Josefsson wrote: I'm just going to mention one of these other purposes. Joakim Axelsson has built a new limit match called superlimit that is a lot more powerful than the old limit

Re: debug and notrack tables - proposal and questions

2002-04-17 Thread Martin Josefsson
On Wed, 2002-04-17 at 21:16, Harald Welte wrote: Have you tried without conntrack? I'm not so sure it really accounts for most of the performance problems. Jamal Hadi Selmi and Robert Olsson have made several performance analysis on linux routers. You can find their test results in

Re: odd state and conntrack match behavior

2002-04-17 Thread Joakim Axelsson
2002-04-17 11:08:24+0400, Paul P Komkoff Jr [EMAIL PROTECTED] - Here it goes -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -A INPUT -m state --state ESTABLISHED,RELATED 1st matched less than second It is very strange to me. I'm even tried to investigate the code. :( but

Re: debug and notrack tables - proposal and questions

2002-04-17 Thread Patrick Schaaf
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)