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