Well, you should be able to do:
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
And then all proxy_arp requests on eth0 that fall outside the address
range of eth0, but which the linux machine has a router for, will be
responded to.
At least it _should_. It doesn't do that at the moment if the source
IP address of the ARP request falls outside of the IP range of eth0,
which reduces it's usefullness a lot. I think that's a bug.
Witness:
spock# ifconfig dummy0 192.168.1.1
spock# echo 1 > /proc/sys/net/ipv4/ip_forward
spock# echo 1 > /proc/sys/net/ipv4/conf/eth0/ip_forward
Now "spock" should do proxy arp, right? On another machine:
tricorder# ifconfig eth0:1 192.168.1.5
tricorder# ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20): 56 data bytes
spock# tcpdump -n arp or icmp
tcpdump: listening on eth0
19:27:06.622804 arp who-has 192.168.1.20 tell 192.168.1.5
19:27:07.615503 arp who-has 192.168.1.20 tell 192.168.1.5
19:27:08.615404 arp who-has 192.168.1.20 tell 192.168.1.5
As you can see, "spock" does not reply. Now let's configure "tricorder"
a bit differently:
tricorder# ifconfig eth0:1 down
tricorder# route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
tricorder# ping 192.168.1.20
Pings for 192.168.1.20 now still go out on eth0, but with the source
IP address in the ARP packet of the real local network:
spock# tcpdump -n arp or icmp
tcpdump: listening on eth0
19:29:07.262300 arp who-has 192.168.1.20 tell 195.64.65.99
19:29:07.575366 arp reply 192.168.1.20 is-at 0:80:48:e9:4:dc
19:29:07.575446 195.64.65.99 > 192.168.1.20: icmp: echo request
19:29:08.254933 195.64.65.99 > 192.168.1.20: icmp: echo request
As you can see, the proxy host (spock) now does answer.
Alexey, is this a bug or intentional ?
Mike.
-- Indifference will certainly be the downfall of mankind, but who cares?- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/