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

[netfilter@interlinx.bc.ca]

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