[tproxy] TProxy version 4.0.0 released

[Balazs Scheidler]

On Mon, 2007-08-13 at 16:49 -0600, Cameron Schaus wrote:
> KOVACS Krisztian wrote:
> >> I would like to understand why the 4.0.0 code does not work when a 
> >> bridge is involved, because based on previous discussions it sounds like 
> >> should work when I create a static ARP entry on the web server.  The 
> >> packets arriving back at the bridge have a dest ethernet address of the 
> >> bridge, and so should make it up the stack correctly.
> >>
> >> When I use ebtables brouting feature, the packets are processed 
> >> correctly by the bridge, however, using ebtables brouting is not 
> >> feasible for my application.
> >>     
> >
> > If you configure ARP properly, then it should work. Definitely worth
> > investigating... Do you have any clue _where_ things might go wrong inside
> > the kernel? (It looks like the packet does get up to routing, but then the
> > socket is somehow not found and the kernel tries to forward it.)
> >   
> 
> I added some debug information to the ip_tproxy_prerouting function, and 
> it appears that the incoming connection is found in the socket hash, and 
> that "freebind" is set in the struct.  So, my initial speculation about 
> mismatched devices was not correct.
> 
> Do you have anymore ideas about why this code does not work with a bridge?
> 
> I'm going to investigate the ip_divert_local function, but I'm not 100% 
> clear about what it's doing to "short circut" the routing.

It sets up a dst_entry that forces the packet go to ip_local_deliver(),
which is the main entry point of the IP stack in the kernel.

I don't see how this could go wrong from that point. The prerouting hook
of tproxy looks up the socket and stores this information in skb->sk,
which in turn will be used by the TCP stack instead of doing another
lookup.

Can you confirm that skb->sk is set in tcp_v4_rcv() by the time the
packet gets there?

You could also get some information by adding a "LOG" rule in
filter/INPUT, as that chain is iterated only if the packet successfully
got to the input side of the IP stack.

-- 
Bazsi