Anyone know for sure if it's broken or working ?
Well I finally made this work, so the answer is that it does indeed work.
I will post some information in the hope that future generations may be retain their hair:
There seem to be a number of preconditions that must be met before the arp...pub form of proxy arp will work. If these conditions are not met the kernel silently fails to answer the arp request (as oposed to for example the user seeing an error message when they run the user-space program).
First, the /proc/sys/net/ipv4/conf/<dev>/proxy_arp must be enabled on the interface where you desire arp responses to be sent.
Second, the address that you want to proxy arp must _not_ be arp-able on the interface that you want the arp response to be sent from (i.e. you can't proxy arp addresses that are in a subnet assigned to the interface). This means that if you do want to proxy addresses from a subnet that also contains the address of the interface, then you need to either a) use some other address for the interface but assign the address from the subnet to the loopback interface or b) assign a point-to-point /32 address to the interface. In both cases you also need to insert a route for any host you want to talk to on that subnet (in my case the DSL router), because that host won't be arp-able once you fix your addresses such that proxy arp functions.
Third, the address that you are attempting to proxy
must be routable from the host. The kernel's definition
of 'routable' appears to be a little more complicated than
might be imagined. For example in my case I did have
a route (and I could even ping the host successfully),
however I also had two route tables. For some reason
the kernel refused to answer the arp request unless
I put a route in the second route table (possibly because
the arp request has a source IP address that if the kernel had been planning to route it, would have
consulted the second route table).
So perhaps the necessary condition is 'have a route
from the arping node's IP address to the proxied address ?
After three days battling this, I am certain that something is broken : perhaps the ioctl() call should fail if the arp response wouldn't be sent, or perhaps arp -e|a should tell the user that no arp response will be generated or perhaps the kernel shouldn't be so picky about when and if it will respond to an arp request (after all, anyone messing around with proxy arp presumably knows what they are doing??). And surely the documentation could be improved. I plan to do all these things in a parallel universe where I have sufficient free time...
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
