Re: [LARTC] Is 'publish' proxy arp still broken ?

["David Boreham" <david_list@boreham.org>]

> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/