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

[netfilter@interlinx.bc.ca]

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