[tproxy] TProxy version 4.0.0 released

Cameron Schaus cam at schaus.ca
Tue Aug 7 17:55:29 CEST 2007


Jan Engelhardt wrote:
> Well, _where_ did you add this entry? It must be added to .34.1,
> not .34.2 and not .34.99. And that raises problems, for example:
>
>  - .34.1 is not under your control and/or has no way to add ARP entries
>    (like most routers which only have a web interface)
>
>  - there is more than just .34.1, for example if
>    br0[eth0+eth1] were the combined .34.0/24 (no router so to speak),
>    then you would have to add ARP for all machines on all machines (yikes!)
>   
I add the static arp entry on my web server.  I am doing this purely for 
testing purposes.  In the real system, the arp traffic flows across the 
bridge so the webserver has the client's MAC address.

To be clear, I have one test bridge running the tproxy code generating 
an HTTP GET request to a web server using a foreign source address for 
the request.  I have placed the static arp entry on the web server.

Using my setup I have validated that the tproxy v4.0.0 code does work 
without a bridge.  However, when I configure a bridge, per my previous 
posts, and run my test again, the client machine (with bridge+tproxy) 
sits and sends arp requests for the foreign IP address.

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.

Thanks,
Cam



More information about the tproxy mailing list