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