On Mon, 9 Feb 2004, jamal wrote:
> It should probably be a sysctl example proxy_arp_validate_neigh.
> I am happy with the way it is right now in the situation i use it in.
I assume you need to probe with ARP request whether for some
IP we have:
- proxy entry
- we can respond for this target IP due to indev/proxy_arp set to 1
Then where is better such flag to exist, for indev or
> > The changes:
> > - now pneigh_lookup has more priority compared to arp_fwd_proxy
> > - neigh_event_ns is called only once per request, not twice
> Could the neighbor be removed while we have the packet in the proxy
> It doesnt seem like theres any harm done in redoing the neigh_event_ns
You are right, if proxy_delay is large the requestor can
disappear from our cache but it is not fatal for us to send reply,
we do not need cache entry for this. I'm not sure what is better, is
it right to confirm the requestor without receiving recent event
from it? If will be visible for too large proxy_delay values.
> > - the 'skb->pkt_type == PACKET_HOST' check has no semantic anymore,
> > the requestor should have same information no matter the packet
> > type. In all cases we add response delay for all requests, broadcast
> > or unicast, to help other authoritative hosts to reply before us.
> So far we havent been delaying responses to unicast because their
> state is typically sane. I should say we are taking for granted
> the sender's state machine is sane and would send a valid unicast
> probe. Are you protecting against insane implementations?
> Other than Linux what other OS actually sends unicast probes?
I already fixed that, if we have valid answer there is no good
reason to delay it if the probe was unicast.
> > - the RTCF_DNAT case is not delayed anymore (may be it is not used
> > anymore, IIRC)
> Looking at 2.6.1 CONFIG_IP_ROUTE_NAT RTCF_NAT is still in use. Recommend
> leaving it.
But there is no need to apply delay in this case.
Julian Anastasov <ja@xxxxxx>