[tproxy] TProxy version 4.0.0 released

[Cameron Schaus]

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