From patchwork Mon Jan 4 22:04:44 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Octavian Purdila X-Patchwork-Id: 42096 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 34AA3B7BF3 for ; Tue, 5 Jan 2010 09:08:16 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753301Ab0ADWIL (ORCPT ); Mon, 4 Jan 2010 17:08:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752914Ab0ADWIJ (ORCPT ); Mon, 4 Jan 2010 17:08:09 -0500 Received: from ixro-out-rtc.ixiacom.com ([92.87.192.98]:22881 "EHLO ixro-ex1.ixiacom.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751051Ab0ADWII (ORCPT ); Mon, 4 Jan 2010 17:08:08 -0500 Received: from ixro-opurdila-lap.localnet ([10.205.15.12]) by ixro-ex1.ixiacom.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 00:08:06 +0200 From: Octavian Purdila Organization: Ixia To: netdev@vger.kernel.org Subject: [RFC] ipv4: support for request type gratuitous ARP Date: Tue, 5 Jan 2010 00:04:44 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-trunk-686; KDE/4.3.2; i686; ; ) MIME-Version: 1.0 Message-Id: <201001050004.45004.opurdila@ixiacom.com> X-OriginalArrivalTime: 04 Jan 2010 22:08:06.0573 (UTC) FILETIME=[649155D0:01CA8D8A] Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Signed-off-by: Octavian Purdila Reviewed-by: Laurent Chavey --- I've noticed that even though we currently support response type gratuitous ARP [response type, source mac, dest mac, source IP, source IP] *with a clean ARP table* we do not support the request type [request type, source mac, ff:ff:ff:ff:ff:ff, source IP, source IP]. This patch makes request type work as well, but RFC2002 says that gratuitous ARP (both request and response) must update the ARP table *if* the IP already exists in the table: In either case, for a gratuitous ARP, the ARP packet MUST be transmitted as a local broadcast packet on the local link. As specified in [16], any node receiving any ARP packet (Request or Reply) MUST update its local ARP cache with the Sender Protocol and Hardware Addresses in the ARP packet, if the receiving node has an entry for that IP address already in its ARP cache. This requirement in the ARP protocol applies even for ARP Request packets, and for ARP Reply packets that do not match any ARP Request transmitted by the receiving node [16]. so, I am not sure if this is right. But current behavior for response type gratuitous ARP does not seem to be covered by the RFC either. net/ipv4/arp.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c index c95cd93..81ef2d5 100644 --- a/net/ipv4/arp.c +++ b/net/ipv4/arp.c @@ -811,8 +811,13 @@ static int arp_process(struct sk_buff *skb) goto out; } - if (arp->ar_op == htons(ARPOP_REQUEST) && - ip_route_input(skb, tip, sip, 0, dev) == 0) { + if (arp->ar_op == htons(ARPOP_REQUEST)) { + /* gratuitous ARP */ + if (tip == sip) { + n = neigh_event_ns(&arp_tbl, sha, &sip, dev); + goto update; + } else if (ip_route_input(skb, tip, sip, 0, dev) != 0) + goto update_lookup; rt = skb_rtable(skb); addr_type = rt->rt_type; @@ -853,6 +858,7 @@ static int arp_process(struct sk_buff *skb) } } +update_lookup: /* Update our ARP tables */ n = __neigh_lookup(&arp_tbl, &sip, dev, 0); @@ -868,6 +874,7 @@ static int arp_process(struct sk_buff *skb) n = __neigh_lookup(&arp_tbl, &sip, dev, 1); } +update: if (n) { int state = NUD_REACHABLE; int override;