How to create a "persistent" expectation with newnat?

How to create a "persistent" expectation with newnat?

[netfilter]

[-- 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 --]

Re: How to create a "persistent" expectation with newnat?

[netfilter]

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

To followup on my own message...

On Mon, Feb 24, 2003 at 12:18:15AM -0500, netfilter@interlinx.bc.ca wrote:
> 
> 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).

OK,  I have been doing some digging in the code.  From what I have
determined, it looks like there is no allowance for creating multiple
non-unique expectations.  I can see why the design is such that this
is the case, as it allows ip_conntrack_expect_related() to renew the
timeout on a related simply by posting the expectation again.

But, there does seem to be a "use" counter in "struct
ip_conntrack_expect".  Is that of any use to me?

Anyway, I did manage to solve this problem with the following hack.  I
have no idea if it's the right solution or not, but I suspect it's
not.  More on why below.

So my solution was to repost the expectation when the related
(expected) connection comes in via the struct
ip_conntrack_expect.expectfn() function pointer.  I assigned to that,
the following function:

static int gnutella_expectfn(struct ip_conntrack *foo)
{

    /* foo->master is the expectation that we are being called for
     * (and want to repost) and foo->master->expectant is the connection
     * that we are related to
     */
    if (foo->master && foo->master->expectant) {
        LOCK_BH(&ip_gnutella_lock);
        ip_conntrack_expect_related(foo->master->expectant, foo->master);
        UNLOCK_BH(&ip_gnutella_lock);
    }

    return 0;

}

I am not sure if the locking in there is needed, or if this approach
is even the right way to make an incoming expectation
persistant/perpetual.  If not, I am open to alternatives.

In any case, what makes me suspect that this is the wrong solution is
that (back to the "use" counter) while the expectation does not seem
to disappear on me (good) the use counter increments indefinately.  It
is at:

EXPECTING: 179 use=120 proto=6 src=0.0.0.0 dst=66.102.74.122 sport=0 dport=6346 

right now.  This has to be wrong.  At a minimum, I wonder why incoming
connections that meet the expectation are not decrementing the use
counter.

Thots?

b.

-- 
Brian J. Murrell

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

Re: How to create a "persistent" expectation with newnat?

[Harald Welte]

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

On Mon, Feb 24, 2003 at 11:43:37PM -0500, netfilter@interlinx.bc.ca wrote:
> To followup on my own message...

;)
> OK,  I have been doing some digging in the code.  From what I have
> determined, it looks like there is no allowance for creating multiple
> non-unique expectations.  I can see why the design is such that this
> is the case, as it allows ip_conntrack_expect_related() to renew the
> timeout on a related simply by posting the expectation again.

true.

> But, there does seem to be a "use" counter in "struct
> ip_conntrack_expect".  Is that of any use to me?

no, this is a reference counter used internally. when use drops to 0,
the structure is kfree()d.

> Anyway, I did manage to solve this problem with the following hack.  I
> have no idea if it's the right solution or not, but I suspect it's
> not.  More on why below.

it's not a hack, it is _the_ solution.

> So my solution was to repost the expectation when the related
> (expected) connection comes in via the struct
> ip_conntrack_expect.expectfn() function pointer.  I assigned to that,
> the following function:

I don't remember which helper, but this _is_ already implemented in one
of the helpers.  I am quite sure that we had this discussion an the list
and somebody has actually already implemented this solution.

> I am not sure if the locking in there is needed, or if this approach
> is even the right way to make an incoming expectation
> persistant/perpetual.  If not, I am open to alternatives.

I don't know the rest of the code, but locking should in general not be
needed (at least not by the core).

> In any case, what makes me suspect that this is the wrong solution is
> that (back to the "use" counter) while the expectation does not seem
> to disappear on me (good) the use counter increments indefinately.  It
> is at:

if you increment the use counter, the structure will never be deleted
from kernel memory and you will run out of memory.  The expectation will
_not_ persist in an active state, since it is removed from the
expect_list anyway.

> Brian J. Murrell



-- 
- 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 --]

Re: How to create a "persistent" expectation with newnat?

[netfilter]

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

On Wed, Feb 26, 2003 at 06:41:45PM +0100, Harald Welte wrote:
> 
> it's not a hack, it is _the_ solution.

Oh.  Decent.  :-)

> I don't remember which helper, but this _is_ already implemented in one
> of the helpers.

I can be so dumb sometimes.  I went googling for use of expectfn but
didn't think to look in existing helpers.  I think actually I didn't
think that any helpers were using it already.

In fact the h323 helper shows a nice example of hooking a different
helper function to the incoming connection of what was expected.  This
was going to be my next question.  :-)

[ you can skip the next three paragraphs if you are not interested in
  the nuances of the gnutella protocol and a question about to handle
  one aspect of it with a helper ]

The way Gnutella works, it starts out making outbound connections, but
because it's peer to peer, once your address gets circulated into the
"cleint pool" other people start making incoming connections to you.

The Gnutella client tries to keep between a minimum number and a
maximum number of connections up.  So it's completely possible that
once things get going, you will not make any further outbound
connections because inbound ones keep up your minimum connections
requirement.

Thus the need to hook further incoming expecations on incoming
connection requests.  If I am correct, in order to do this, I need to
hook a helper to each inbound connection that simply sets up the same
expectation -- for more inbound connections.  I have not thought of
the NAT implications of this yet, but that will be after I have the
expectations working for both inbound and outbound connections.

> I am quite sure that we had this discussion an the list
> and somebody has actually already implemented this solution.

There seem to be a few uses of expectfn that I am sure I can glean
lots from.

> I don't know the rest of the code, but locking should in general not be
> needed (at least not by the core).

OK.

> 
> > In any case, what makes me suspect that this is the wrong solution is
> > that (back to the "use" counter) while the expectation does not seem
> > to disappear on me (good) the use counter increments indefinately.  It
> > is at:
> 
> if you increment the use counter,

I am not touching the counter, myself.  However, every time I repost
the expectation with:

static int gnutella_expectfn(struct ip_conntrack *ct)
{

    struct ip_conntrack *master;
    master = master_ct(ct);
    if (!master) {
        DEBUGP(" no master!!!\n");
        return 0;
    }

    ip_conntrack_expect_related(master, ct->master);

    return 0;
}

[ I wonder if the above function should be put into the
  ip_conntrack_core as "repost_expect(struct ip_conntrack *)" (or
  something similar).  It's generic enough and should not really need
  to be written by many people who just need to repost expectations
  when they are met. ]

in the expectfn function, the counter is increased.  This continues to
happen until the master connection goes away, and the expectation is
removed.

I would have thought the counter would go 0, 1, 0, 1, 0, 1... (or 1,
2, 1, 2, 1, 2, 1, 2...) as incoming connections repeaped the
expectation and my helper reposts it.  If it's normal and expected (no
pun intended) that the counter just continue to increment as incoming
(expected) connections are made and I repost the expectation, then I
won't worry about it.

> the structure will never be deleted
> from kernel memory and you will run out of memory.

If I can trust that it's freed from kernel memory when it disappears
in /proc/net/ip_conntrack, I won't run out of memory if I wasn't going
to run out of memory already.  It's not a recurring "leak".  The
counter is incrementing as per the reposting of the expectation, but
when the master goes away, so does the expectation (with it's high
counter).

> The expectation will
> _not_ persist in an active state, since it is removed from the
> expect_list anyway.

I think you are just saying what I said, albeit more concisely, no?
(It's a sad state when one's use of his native tongue is worse than
another's use of his second tongue.  :-)

b.

-- 
Brian J. Murrell

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

Re: How to create a "persistent" expectation with newnat?

[Ian Latter]

Howdy netfilter-dude,

  Wouldn't most of your problems go away if you set the expectation
on the outbound connection?  Ie.  If I was to alter my rsh module to
do gnutella, on what you've said below, I would look for the one 
outbound connection (client to server --- or client to universe in p2p),
setup an expectation on the inbound connections (universe to client)
for either an unlimited or numbered count of each type, then handle
these connections.

  In this way you will also avoid hassles later with NAT ....

So, generally, my feeling from netfilter is that you track the
outbound and expect the inbound ...


----- Original Message -----
>From: <netfilter@interlinx.bc.ca>
>To: "Netfilter Development Mailinglist" <netfilter-devel@lists.netfilter.org>
>Subject:  Re: How to create a "persistent" expectation with newnat?
>Date: Wed, 26 Feb 2003 15:40:10 -0500
>
> On Wed, Feb 26, 2003 at 06:41:45PM +0100, Harald Welte wrote:
> > 
> > it's not a hack, it is _the_ solution.
> 
> Oh.  Decent.  :-)
> 
> > I don't remember which helper, but this _is_ already implemented in one
> > of the helpers.
> 
> I can be so dumb sometimes.  I went googling for use of expectfn but
> didn't think to look in existing helpers.  I think actually I didn't
> think that any helpers were using it already.
> 
> In fact the h323 helper shows a nice example of hooking a different
> helper function to the incoming connection of what was expected.  This
> was going to be my next question.  :-)
> 
> [ you can skip the next three paragraphs if you are not interested in
>   the nuances of the gnutella protocol and a question about to handle
>   one aspect of it with a helper ]
> 
> The way Gnutella works, it starts out making outbound connections, but
> because it's peer to peer, once your address gets circulated into the
> "cleint pool" other people start making incoming connections to you.
> 
> The Gnutella client tries to keep between a minimum number and a
> maximum number of connections up.  So it's completely possible that
> once things get going, you will not make any further outbound
> connections because inbound ones keep up your minimum connections
> requirement.
> 
> Thus the need to hook further incoming expecations on incoming
> connection requests.  If I am correct, in order to do this, I need to
> hook a helper to each inbound connection that simply sets up the same
> expectation -- for more inbound connections.  I have not thought of
> the NAT implications of this yet, but that will be after I have the
> expectations working for both inbound and outbound connections.
> 
> > I am quite sure that we had this discussion an the list
> > and somebody has actually already implemented this solution.
> 
> There seem to be a few uses of expectfn that I am sure I can glean
> lots from.
> 
> > I don't know the rest of the code, but locking should in general not be
> > needed (at least not by the core).
> 
> OK.
> 
> > 
> > > In any case, what makes me suspect that this is the wrong solution is
> > > that (back to the "use" counter) while the expectation does not seem
> > > to disappear on me (good) the use counter increments indefinately.  It
> > > is at:
> > 
> > if you increment the use counter,
> 
> I am not touching the counter, myself.  However, every time I repost
> the expectation with:
> 
> static int gnutella_expectfn(struct ip_conntrack *ct)
> {
> 
>     struct ip_conntrack *master;
>     master = master_ct(ct);
>     if (!master) {
>         DEBUGP(" no master!!!n");
>         return 0;
>     }
> 
>     ip_conntrack_expect_related(master, ct->master);
> 
>     return 0;
> }
> 
> [ I wonder if the above function should be put into the
>   ip_conntrack_core as "repost_expect(struct ip_conntrack *)" (or
>   something similar).  It's generic enough and should not really need
>   to be written by many people who just need to repost expectations
>   when they are met. ]
> 
> in the expectfn function, the counter is increased.  This continues to
> happen until the master connection goes away, and the expectation is
> removed.
> 
> I would have thought the counter would go 0, 1, 0, 1, 0, 1... (or 1,
> 2, 1, 2, 1, 2, 1, 2...) as incoming connections repeaped the
> expectation and my helper reposts it.  If it's normal and expected (no
> pun intended) that the counter just continue to increment as incoming
> (expected) connections are made and I repost the expectation, then I
> won't worry about it.
> 
> > the structure will never be deleted
> > from kernel memory and you will run out of memory.
> 
> If I can trust that it's freed from kernel memory when it disappears
> in /proc/net/ip_conntrack, I won't run out of memory if I wasn't going
> to run out of memory already.  It's not a recurring "leak".  The
> counter is incrementing as per the reposting of the expectation, but
> when the master goes away, so does the expectation (with it's high
> counter).
> 
> > The expectation will
> > _not_ persist in an active state, since it is removed from the
> > expect_list anyway.
> 
> I think you are just saying what I said, albeit more concisely, no?
> (It's a sad state when one's use of his native tongue is worse than
> another's use of his second tongue.  :-)
> 
> b.
> 
> -- 
> Brian J. Murrell
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

Re: How to create a "persistent" expectation with newnat?

[Harald Welte]

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

On Wed, Feb 26, 2003 at 03:40:10PM -0500, netfilter@interlinx.bc.ca wrote:

> > > In any case, what makes me suspect that this is the wrong solution is
> > > that (back to the "use" counter) while the expectation does not seem
> > > to disappear on me (good) the use counter increments indefinately.  It
> > > is at:
> > 
> > if you increment the use counter,
> 
> I am not touching the counter, myself.  However, every time I repost
> the expectation with:
> 
> static int gnutella_expectfn(struct ip_conntrack *ct)
> {
> 
>     struct ip_conntrack *master;
>     master = master_ct(ct);
>     if (!master) {
>         DEBUGP(" no master!!!\n");
>         return 0;
>     }
> 
>     ip_conntrack_expect_related(master, ct->master);
> 
>     return 0;
> }

This was not what I was thinking about. You would try to put the same
struct onto the list again.  Bad things will happen.  You will need to
allocate a new struct ip_conntrack_expect, initialize it with tuple/mask
and then call expect_related on this newly-allocated struct.

I did mean 'the same expectation' on a logical level, not 'the same
piece of memory representing the expectation'.

> > the structure will never be deleted
> > from kernel memory and you will run out of memory.
> 
> If I can trust that it's freed from kernel memory when it disappears
> in /proc/net/ip_conntrack, 

No, please look at the code.  /proc/ip_conntrack lists _unfulfilled_
expectations.  once the 'slave' connection arrives and fulfills the
expectation, it will no longer appear in /proc/net/ip_conntrack.

In fact the structure will be allocated until the slave struct
ip_conntrack dies (and thus drops the 'use' count of the master struct 
ip_conntrack_expect.

I've tried to describe this in documentation/newnat-summary.txt.

> b.
> Brian J. Murrell

-- 
- 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 --]

Re: How to create a "persistent" expectation with newnat?

[netfilter]

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

On Thu, Feb 27, 2003 at 08:11:29AM +1100, Ian Latter wrote:
> 
> Howdy netfilter-dude,

Howdy pardner.  :-)

>   Wouldn't most of your problems go away if you set the expectation
> on the outbound connection?

I do that.  And it works while there are outbound connections.  But as
I described in my last message, there might be some time (quite a bit
of time in fact) between outgoing connections.  Indeed, once you have
been on the network long enough and your address gets known to enough
other peers on the network, you will start to see enough incoming
connections that you no longer make outgoing connections to keep the
"minimum connections" count up.

Since there potentially can be no outgoing connections after the first
few, it is these incoming connections that need to keep the "flywheel"
(of inbound expectations) going.

> Ie.  If I was to alter my rsh module to
> do gnutella, on what you've said below, I would look for the one 
> outbound connection (client to server --- or client to universe in p2p),
> setup an expectation on the inbound connections (universe to client)
> for either an unlimited or numbered count of each type, then handle
> these connections.

But the expectation will go away when either of a) it times out, or b)
the master connection goes away.  It is for both of these reasons that
the expectation needs to continually be renewed (even when your only
connections are inbound).  It needs to be attached to an ESTABLISHED
connection and not be timed out.

>   In this way you will also avoid hassles later with NAT ....

For inbound connections, I don't know that there are NAT issues yet.
I don't think anything in the payload needs to be altered.  I have not
looked that deeply yet.

> So, generally, my feeling from netfilter is that you track the
> outbound and expect the inbound ...

Generally, I agree with you -- for protocols where this is in fact the
case.

b.

-- 
Brian J. Murrell

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

Re: How to create a "persistent" expectation with newnat?

[netfilter]

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

On Wed, Feb 26, 2003 at 10:15:45PM +0100, Harald Welte wrote:
> 
> This was not what I was thinking about. You would try to put the same
> struct onto the list again.

Right.  I was assuming that was the point of the "use" reference
counter.  To be able to re-use objects.

> Bad things will happen.  You will need to
> allocate a new struct ip_conntrack_expect, initialize it with tuple/mask
> and then call expect_related on this newly-allocated struct.

OK.  Should be simple enough with a few memcpys.  I don't suppose
there is a "copy_ip_conntrack_expect()" courtesy function is there?

> I did mean 'the same expectation' on a logical level, not 'the same
> piece of memory representing the expectation'.

OK.  I will go correct that in my helper then.

> I've tried to describe this in documentation/newnat-summary.txt.

I looked at that, and maybe with the context I have now it will be
clearer, but it was not that clear on my first reading (obviously, or
I would have gotten this all right the first time :-).

Thanx much for the steering in the right direction Harald.

You know, writing helpers for various protocols would not be a bad
gig... for a while I guess... everything gets boring after a while I
suppose.  :-) 
b.

-- 
Brian J. Murrell

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

Re: How to create a "persistent" expectation with newnat?

[Ian Latter]

> Howdy pardner.  :-)
ahhh .. Brian ;-)  Didn't see your sig b4 ...
 
> >   Wouldn't most of your problems go away if you set the expectation
> > on the outbound connection?
> 
> I do that.  And it works while there are outbound connections.  But as
> I described in my last message, there might be some time (quite a bit
> of time in fact) between outgoing connections.  Indeed, once you have
> been on the network long enough and your address gets known to enough
> other peers on the network, you will start to see enough incoming
> connections that you no longer make outgoing connections to keep the
> "minimum connections" count up.
Instead of relying on outgoing connections to maintain the live session,
leave that out for the time being, and set up an untimed inbound expectation.


> Since there potentially can be no outgoing connections after the first
> few, it is these incoming connections that need to keep the "flywheel"
> (of inbound expectations) going.
s'cool ... let one out set it off ... and the ins can look after themselves ...


> > Ie.  If I was to alter my rsh module to
> > do gnutella, on what you've said below, I would look for the one 
> > outbound connection (client to server --- or client to universe in p2p),
> > setup an expectation on the inbound connections (universe to client)
> > for either an unlimited or numbered count of each type, then handle
> > these connections.
> 
> But the expectation will go away when either of a) it times out, or b)
> the master connection goes away.  It is for both of these reasons that
> the expectation needs to continually be renewed (even when your only
> connections are inbound).  It needs to be attached to an ESTABLISHED
> connection and not be timed out.
Whenever your "end condition" occurs for the client ... then unload all
of the open expectations ....   so ... a or b rings true, then trash the open
expects ..


> >   In this way you will also avoid hassles later with NAT ....
> 
> For inbound connections, I don't know that there are NAT issues yet.
> I don't think anything in the payload needs to be altered.  I have not
> looked that deeply yet.
Even if there's nothing in the payload ... if the NAT has been a masq or
some other non ip-to-ip mapping, then the helper will need to rewrite the
ip headers ... this had to be done in rsh .. which works like ftp ... one
out with a port in the proto for where a new one should come back ..
this then hits the firewall (tables) as a local port, which then needs to
be re-written.  Not that my rsh nat code ever got published ... I've been
meaning to ask Harald about that actually ...


> > So, generally, my feeling from netfilter is that you track the
> > outbound and expect the inbound ...
> 
> Generally, I agree with you -- for protocols where this is in fact the
> case.
I don't see your proto as being tremendously different from ftp ... 'cept
that the data sessions can be many+ and they can come from
the universe and not the master destination ...  should be pretty straight
forward ...


> b.
> 
> -- 
> Brian J. Murrell
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

Re: How to create a "persistent" expectation with newnat?

[netfilter]

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

On Thu, Feb 27, 2003 at 09:53:45AM +1100, Ian Latter wrote:
> 
> ahhh .. Brian ;-)  Didn't see your sig b4 ...

S'ok.  It was funny.

> Instead of relying on outgoing connections to maintain the live session,
> leave that out for the time being, and set up an untimed inbound expectation.

But unless I am mistaken, inbound expectations have to be related to
an ESTABLISHED connection.  That is fine, except as soon as the
ESTABLISHED connection goes away so does it's expectation(s).  With the
nature of P2P like Gnutella, connections come and go like the wind.

That is why the expectation (which is the same for every outgoing and
incoming connection) needs to be refreshed with new master
connections.

> s'cool ... let one out set it off ... and the ins can look after themselves ...

Right.  I do refresh the expecation for every outbound connection, but
need to refresh on inbound connections as well as outbound connections
can be few and far between once the client has made it's presence
known.

> Whenever your "end condition" occurs for the client ... then unload all
> of the open expectations ....

Well, the expectation (there is only one, it's the same expectation
for all masters everybody:allports->client:localport) goes away when
it times out or the master connection goes away.  That is clean enough
for me.

> so ... a or b rings true, then trash the open
> expects ..

It's just cleaner to let the framework do that for me.

> Even if there's nothing in the payload ... if the NAT has been a masq or
> some other non ip-to-ip mapping, then the helper will need to rewrite the
> ip headers ...

Right.  I am already doing that.  I do alter the payload in the
outgoing connection if needed -- although with gtk-gnutella, it somehow
determines the outside address of the iptables box so technically it's
not needed.

> this had to be done in rsh .. which works like ftp ... one
> out with a port in the proto for where a new one should come back ..
> this then hits the firewall (tables) as a local port, which then needs to
> be re-written.

Right.  That I am doing already as well.  I have successfully run two
different clients behind my modules and they both work (while both are
using the same local port), so I must be doing something right.  :-)

> I don't see your proto as being tremendously different from ftp ... 'cept
> that the data sessions can be many+ and they can come from
> the universe and not the master destination ...  should be pretty straight
> forward ...

'Tis really.  In my original message, I think I said it was 99%
working and thought I had to use a hack to get it to work when indeed
my hack was (close to) the right solution.  I based heavily on the ftp
and/or irc modules.

b.

-- 
Brian J. Murrell

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