Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Change\s+proxy_arp\s+to\s+respond\s+only\s+for\s+valid\s+neighbours\s*$/: 64 ]

Total 64 documents matching your query.

1. Change proxy_arp to respond only for valid neighbours (score: 1)
Author: >
Date: Sun, 8 Feb 2004 22:44:05 +0200 (EET)
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
/archives/netdev/2004-02/msg00180.html (12,387 bytes)

2. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: S. Miller" <davem@xxxxxxxxxx>
Date: Sun, 8 Feb 2004 13:14:17 -0800
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
/archives/netdev/2004-02/msg00188.html (9,096 bytes)

3. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: ndalf@xxxxxxxxxxx>
Date: Sun, 8 Feb 2004 23:38:12 +0200 (EET)
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
/archives/netdev/2004-02/msg00191.html (10,127 bytes)

4. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: Miller" <davem@xxxxxxxxxx>
Date: Mon, 9 Feb 2004 00:44:26 +0200 (EET)
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
/archives/netdev/2004-02/msg00192.html (9,527 bytes)

5. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: shfuji@xxxxxxxxxxxxxx>
Date: Mon, 9 Feb 2004 08:08:30 +0200 (EET)
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/
/archives/netdev/2004-02/msg00200.html (10,087 bytes)

6. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: Hideaki / 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Mon, 9 Feb 2004 13:30:56 +0200 (EET)
Thanks, I'll check it later today. Regards -- Julian Anastasov <ja@xxxxxx>
/archives/netdev/2004-02/msg00204.html (9,849 bytes)

7. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: kkas@xxxxxxxxxx>
Date: 09 Feb 2004 10:01:15 -0500
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
/archives/netdev/2004-02/msg00206.html (11,614 bytes)

8. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: r" <davem@xxxxxxxxxx>
Date: Mon, 9 Feb 2004 12:19:26 -0800
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
/archives/netdev/2004-02/msg00213.html (10,808 bytes)

9. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: Miller" <davem@xxxxxxxxxx>
Date: Mon, 9 Feb 2004 16:26:46 -0500 (EST)
Sounds like a plan. - James -- James Morris <jmorris@xxxxxxxxxx>
/archives/netdev/2004-02/msg00219.html (10,244 bytes)

10. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 09 Feb 2004 13:39:51 -0800
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
/archives/netdev/2004-02/msg00220.html (11,355 bytes)

11. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 9 Feb 2004 13:45:51 -0800
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
/archives/netdev/2004-02/msg00221.html (10,446 bytes)

12. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: xxxxxxxxx>
Date: Mon, 9 Feb 2004 13:58:43 -0800
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
/archives/netdev/2004-02/msg00223.html (10,119 bytes)

13. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: xxxxxx>
Date: Tue, 10 Feb 2004 00:23:20 +0200 (EET)
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,
/archives/netdev/2004-02/msg00226.html (12,148 bytes)

14. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: eth.krekula@xxxxxxxxx>
Date: Tue, 10 Feb 2004 00:32:56 +0200 (EET)
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
/archives/netdev/2004-02/msg00228.html (10,597 bytes)

15. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Feb 2004 00:42:47 +0200 (EET)
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
/archives/netdev/2004-02/msg00229.html (10,840 bytes)

16. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: >
Date: Mon, 9 Feb 2004 14:45:57 -0800
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
/archives/netdev/2004-02/msg00230.html (10,271 bytes)

17. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: >
Date: 09 Feb 2004 17:50:38 -0500
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
/archives/netdev/2004-02/msg00231.html (12,424 bytes)

18. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: em@xxxxxxxxxx>
Date: Tue, 10 Feb 2004 00:49:10 +0200 (EET)
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
/archives/netdev/2004-02/msg00232.html (10,953 bytes)

19. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author:
Date: Tue, 10 Feb 2004 01:52:53 +0200 (EET)
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
/archives/netdev/2004-02/msg00237.html (14,656 bytes)

20. Re: Change proxy_arp to respond only for valid neighbours (score: 1)
Author: an@xxxxxxxxx>
Date: 09 Feb 2004 20:21:34 -0500
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
/archives/netdev/2004-02/msg00242.html (18,543 bytes)


This search system is powered by Namazu