[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tproxy
Subject:    Re: [tproxy] tproxy4 and bridge
From:       Cameron Schaus <cam () schaus ! ca>
Date:       2007-08-23 17:33:10
Message-ID: 46CDC4D6.9010202 () schaus ! ca
[Download RAW message or body]

Balazs Scheidler wrote:

>To be honest I don't know. TProxy 2 used the NAT framework which was
>explicitly supported by the bridging framework, so it worked without
>problems.
>  
>
It's funny, because I have things almost working with the TProxy 2 NAT 
based code, with the exception of FTP data channel transparency.  I'm 
still not exactly sure why that wasn't working, because I moved to the 
v4 code.

>The interface does not matter when looking up the socket, so this can be
>a real problem, if you want to keep the source port of the client.
>  
>
Which socket lookup are you referring to?  It seems that __inet_lookup 
does use the interface to match against the device the socket was bound 
to.  The routing hash doesn't appear to use the ports for the lookup, 
but I don't think that's as important.

>If you change the client source port to a dynamically allocated one, it
>should work, as the two sockets will not clash.
>  
>
I'd prefer not to have to do that, if at all possible.

Lastly, do you think brouting around the bridge to keep the transparent 
traffic locally routed would make any difference with what I'm trying to 
do?  Or am I going to run into the same socket lookup issues I am now 
with the bridge?

Thanks for the help.  It is appreciated.

Cam


[prev in list] [next in list] [prev in thread] [next in thread]