All of lore.kernel.org
 help / color / mirror / Atom feed
From: netfilter@interlinx.bc.ca
To: Netfilter Development Mailinglist <netfilter-devel@lists.netfilter.org>
Subject: How to create a "persistent" expectation with newnat?
Date: Mon, 24 Feb 2003 00:18:15 -0500	[thread overview]
Message-ID: <20030224051810.GB7523@pc.ilinx> (raw)

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

I am writing (actually 99% done) a conntracker/nat helper pair for
gnutella.  The only part of the protocol it's interested in currently
is allowing for the client behind the iptables box to have incoming
connections to it's listening port.

It works, but with one caveat.  Every time a new incoming (i.e.
related) connection is made, the expectation that allows it is
"reaped" and another incoming connection cannot be made until another
expectation is set up by the conntracker.

What I want to do is when the conntracker sets up the expectation,
tell netfilter not to remove the expectation when a related connection
is successfully made but leave it there allowing for more related
connections.

I currently have my ip_conntrack_helper configured as follows:

    memset(&gnutella_helper, 0, sizeof(struct ip_conntrack_helper));
    gnutella_helper.tuple.src.u.tcp.port = htons(6346);
    gnutella_helper.tuple.dst.protonum = IPPROTO_TCP;
    gnutella_helper.mask.src.u.tcp.port = 0xFFFF;
    gnutella_helper.mask.dst.protonum = 0xFFFF;
    gnutella_helper.max_expected = 10;
    gnutella_helper.timeout = 180;
    gnutella_helper.flags = IP_CT_HELPER_F_REUSE_EXPECT;
    gnutella_helper.me = ip_conntrack_gnutella;
    gnutella_helper.help = help;
    gnutella_helper.name = "gnutella";

and my expectation registration as follows:

    expect.tuple = ((struct ip_conntrack_tuple)
                    { { 0, { 0 } },
                      { ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip,
                        { htons(exp_gnutella_info->port) },
                        IPPROTO_TCP } });
    expect.mask = ((struct ip_conntrack_tuple)
                   { { 0, { 0 } },
                     { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
    expect.expectfn = NULL;
    ip_conntrack_expect_related(ct, &expect);

I thought the max_expected = 10 would achieve what I want but all I
ever seem to get is one expectation waiting and it goes away as soon
as I get one connection (as observed by both /proc/net/ip_conntrack
and seeing "blocking" rules in the firewall where a connection should
be allowed because of the expectation).

Am I doing something wrong, or is what I want to do ust not doable?

b.

-- 
Brian J. Murrell

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

             reply	other threads:[~2003-02-24  5:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-24  5:18 netfilter [this message]
2003-02-25  4:43 ` How to create a "persistent" expectation with newnat? netfilter
2003-02-26 17:41   ` Harald Welte
2003-02-26 20:40     ` netfilter
2003-02-26 21:15       ` Harald Welte
2003-02-26 22:24         ` netfilter
  -- strict thread matches above, loose matches on Subject: below --
2003-02-26 21:11 Ian Latter
2003-02-26 22:18 ` netfilter
2003-02-26 22:53 Ian Latter
2003-02-26 23:54 ` netfilter

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=20030224051810.GB7523@pc.ilinx \
    --to=netfilter@interlinx.bc.ca \
    --cc=netfilter-devel@lists.netfilter.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.