Re: [PATCH}: Make MARK target terminate (resend)

Jozsef Kadlecsik wrote: - rewrite the IPT_CONTINUE targets as matches I am not very fond of this.. besides the order dependency it also has the question on how to easily determine what will happen with the packet.. No obvious distinction between something that matches packets and something

[PATCH] ipt_recent-0.2.2

Harald, Sending this again with hopes that it will get in before the next official release. Just a small bugfix, thanks. Changelog: - If not SET and not found, return immediately instead of flipping the hash entries first (in the event of a collision). diff -uNr

Re: [PATCH}: Make MARK target terminate (resend)

On Mon, 1 Jul 2002, Henrik Nordstrom wrote: - rewrite the IPT_CONTINUE targets as matches I am not very fond of this.. besides the order dependency it also has the question on how to easily determine what will happen with the packet.. No obvious distinction between something that matches

Anonymous CVS-access disabled?

Gents, I'm trying to checkout from the new CVS, but it's not working: -- [root@localhost src]# cvs -d:pserver:[EMAIL PROTECTED]:/cvspublic loginLogging in to :pserver:[EMAIL PROTECTED]:2401/cvspublicCVS password: cvs login: authorization failed: server pserver.netfilter.org

Re: Anonymous CVS-access disabled?

http://www.netfilter.org/downloads.html#cvs Gilion Goudsmit wrote: Gents, I'm trying to checkout from the new CVS, but it's not working: -- [root@localhost src]# cvs -d:pserver:[EMAIL PROTECTED]:/cvspublic login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvspublic CVS

conntrack match issues

I have some small issues with the conntrack match in it's current incarnation a) Very hard to extend with new features as there is no extra flag bits b) Missing the ability to match conntrack ports. c) Some errors in iptables-save output Attached to this message is an extension patch to the

Re: Anonymous CVS-access disabled?

Hello, On Monday 01 July 2002 21:05, Gilion Goudsmit wrote: brilliant! thank you... I was using the HOW-TO for the extensions, with the new servername for the announce-mailing... I did't notice mention of a password there... That why I was having problems... Regards, GG. Opps, looks like

Re: NAT and locally bound sockets

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

Re: conntrack performance/DoS formula

Henrik Nordstrom writes: Don Cohen wrote: 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

Re: NAT and locally bound sockets

On Mon, Jul 01, 2002 at 06:59:39PM +0200, Henrik Nordstrom wrote: 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 This is

Re: conntrack performance/DoS formula

Patrick Schaaf writes: You can now use '-c NUMBER' to set a seed for the CRC32 hash. You can now use '-C' (without parameter) to set a random seed for the CRC32 hash. These options are for testing the idea of attack compensation by inserting local variance. I'd like to hear

Re: conntrack performance/DoS formula -- answer

The answer from my friendly crypto expert: Richard Schroeppel writes: Problem: a firewall tries to track connections going through it (roughly identified by ip addresses and ports of source and destination) by keeping the currently active connections in a hash table. If