Appended is a patch that modifies proxy_arp to check the target's neighbour state before reporting any information to requestors. The benefit is that the availability of the target host is properly
This is a dicey situation in that when the entry does become valid this does not trigger a proxy arp by us, does it? I guess the original requestor will redo the request, so I'm just mentioning this
Yes, currently it works in this way, when target replies we do not propagate this answer to the proxy_queue. But this is not fatal becuase we apply delay in the answer which means we have time to re
I found that it is better not to delay answers to unicast probes. In case I change other things, I'll keep latest version of this patch here: http://www.ssi.bg/~ja/tmp/ arp_proxy-*.diff Regards -- J
As this seems to make the proxy_arp more intelligent, maybe you should take a look at: http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-01.txt (which, at the moment, specifies proxy arp/
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. Could the neighbor be removed while we have the packet in the pr
Do we really want to reply to all the garbage tcpdump causes us to capture? That is what the pkt_type is dealing with. If we're in promiscuous mode, we'll hear ARP requests meant not for any of our d
David S. Miller wrote: On Sun, 8 Feb 2004 22:44:05 +0200 (EET) Julian Anastasov <ja@xxxxxx> wrote: - the 'skb->pkt_type == PACKET_HOST' check has no semantic anymore, the requestor should have same i
Unicast probes are possible. If it is broadcast/multicast then pkt_type will be PACKET_{BROAD,MULTI}CAST. The existing ipv4 proxy-arp code is saying (as I read it) to not delay the response if this i
Julian, do you understand what this check is for? If it is zero, this means we are being reinvoked via the delayed proxy queue. It means that some previously delayed response has been kicked so that
I assume you need to probe with ARP request whether for some IP we have: - proxy entry or - we can respond for this target IP due to indev/proxy_arp set to 1 Then where is better such flag to exist,
But this is true for local TIPs too. Do we need early check for {HOST|BROADCAST} or you prefer it only for the proxy_arp case? I complained once but everything is doable with netfilter, with more ru
It will work as before if we have valid target You are almost right, yes, partially for arp_announce, but IPVS like apps need more things to solve this problem. As for this proxy_arp work it is enti
I think it's not so much your changes as this huge ugly ARP receive processing function. It is a mockery of functional programming :-) I even tried to split this damn thing up today into smaller chun
parse error. Are you agreeing it should be a sysctl? what i meant was i am happy with the slight delay in some cases i get now; example host we are parping for sends a unicast probe - we would immedi
Of course, there is no delay for !tv_sec, just answer or do not answer, http://www.ssi.bg/~ja/tmp/arp_proxy-2.6.2-1.diff: -- else if (fwd_proxy && (n = rt->u.dst.neighbour) && neigh_is_valid(n)) got
May be, if we found usage for this, because I see the handling in this way (I should put this info in doc file later): - if the target is not an ARP neighbour then it is already validated from ip_ro
Hi Julian, Is this always guaranteed? Example "ip route get" will always create a cache entry but not a neighbor. This is true, but not in my setup where i guarantee there will be no other authoritat