mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Harald Welte <laforge@netfilter.org>
To: "David Laganière" <spanska@securinet.qc.ca>
Cc: linux-kernel@vger.kernel.org,
	Netfilter Development Mailinglist 
	<netfilter-devel@lists.netfilter.org>
Subject: Re: A suggestion for the netfilter part of the sources
Date: Tue, 4 Mar 2003 19:20:06 +0100	[thread overview]
Message-ID: <20030304182006.GI4880@sunbeam.de.gnumonks.org> (raw)
In-Reply-To: <3E64E1C8.9040309@securinet.qc.ca>

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On Tue, Mar 04, 2003 at 12:26:32PM -0500, David Laganière wrote:
 
> Since a couple of new kernel versions already, I use to modify two files 
> related to the netfilter part to be able to add more
> ports for the IRC NAT module. I was wondering if you could definitively 
> apply those modifications to the kernel sources.

We (the netfilter developers) thought that for the usual case, 8 ports
should be a reasonable compiletime-limit.  I know, especially for IRC,
this largely depends on the number of IRC networks and servers you want
to support...

> Here are my two modifications:
> 
> In /usr/src/linux-2.4.20/net/ipv4/netfilter:
> I change "#define MAX_PORTS 8" to "#define MAX_PORTS 15" in both 
> "ip_conntrack_irc.c" and "ip_nat_irc.c".

yes, this is the (documented) way to compile with support for more ports

> I'd greatly appreciate a reply even though my suggestion is not a good one.

The suggestion is neither 'good' nor 'bad'.  Nobody has (until now)
asked us to raise this value, eight seems to be enough for most people.

As long as your proposal is not backed by more other users who think the
default should be raised, I'd rather leave it the way it currently is.

btw: further discussion should happen at
netfilter-devel@lists.netfilter.org

> David Laganière
> Network/System Administrator
> Securinet Systems

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

  reply	other threads:[~2003-03-04 18:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-04 17:26 David Laganière
2003-03-04 18:20 ` Harald Welte [this message]
2003-03-04 22:56   ` Dominik Kubla
2003-03-04 23:27     ` Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030304182006.GI4880@sunbeam.de.gnumonks.org \
    --to=laforge@netfilter.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=spanska@securinet.qc.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®