From patchwork Thu Feb 5 07:20:37 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhu Yanjun X-Patchwork-Id: 436660 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 8D2C714021A for ; Thu, 5 Feb 2015 18:20:30 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756714AbbBEHUU (ORCPT ); Thu, 5 Feb 2015 02:20:20 -0500 Received: from mail-ig0-f179.google.com ([209.85.213.179]:38368 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751945AbbBEHUR (ORCPT ); Thu, 5 Feb 2015 02:20:17 -0500 Received: by mail-ig0-f179.google.com with SMTP id l13so9773346iga.0 for ; Wed, 04 Feb 2015 23:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=cvUQCErPthzi5txYjTfSFJYr/oDx4OuG6iVzlRsB19Q=; b=xOuT/oyDkJpHLklQnwfa87LkSuaaejhDssv1yZD5e7p2fdfdsZcmmkL1dVZcn7kUYm EK8Rio4iTv+xH6bDtFG3Bd1b9nT6lFjoTPbUBvQoQZukYPbLN3So1eFYob3FSQiHkvRq yVF0D2qnZAFPwvqJ8xxv6liy/dOcyjCWt0mGGzhw4t5qBFL2AjkbpOx6+jV8oArzaoVM wAwc6gKTUOwVm7zi1uLW8RGB/9VUbiYjw8r6dve/LOGTks+UCEg57e7fqQS2d8CrIA9l CwO7o6hKn9xBwy+CYvtatakwmZn5izeEDN/Uplh9JOuantshyg2cNJS6NzWk6/LyAx/R 0tsQ== X-Received: by 10.50.147.99 with SMTP id tj3mr6816127igb.41.1423120816634; Wed, 04 Feb 2015 23:20:16 -0800 (PST) Received: from HV2021-Test-001.corp.ad.wrs.com ([128.224.252.2]) by mx.google.com with ESMTPSA id p15sm2113075ioe.44.2015.02.04.23.20.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Feb 2015 23:20:15 -0800 (PST) From: zhuyj To: netdev@vger.kernel.org, stefan.costandache@windriver.com, alexandre.dietsch@windriver.com, yue.tao@windriver.com, clinton.slabbert@windriver.com Cc: eulfsam , "David S. Miller" , WANG Cong , zhuyj Subject: [PATCH 1/1] neighbour: Support broadcast ARP in neighbor PROPE state Date: Thu, 5 Feb 2015 02:20:37 -0500 Message-Id: <1423120837-28102-1-git-send-email-zyjzyj2000@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: eulfsam When the neighbor statemachine is in PROBE state, it will normally send a number of unicast ARP requests (number defined in "ucast_probes" entry in the proc file system, default=3) and if no reply is received, it will change state to FAILED. Enabling CONFIG_ARP_PROBE_BCAST, will make the statemachine try to send broadcast ARP requests, and only enter FAILED state if the broadcast ARP requests did not receive a reply. Enabling CONFIG_ARP_PROBE_BCAST, makes the IPv4 ARP behaviour more similar to the IPv6 Neighbor Discovery protocol, and is neccessary, if the other end only responds to broadcast ARPs. CC: David S. Miller CC: WANG Cong Signed-off-by: eulfsam Signed-off-by: zhuyj --- net/core/neighbour.c | 4 ++++ net/ipv4/Kconfig | 17 +++++++++++++++++ 2 files changed, 21 insertions(+) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 8d614c9..50f5ee2 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -830,10 +830,14 @@ out: static __inline__ int neigh_max_probes(struct neighbour *n) { struct neigh_parms *p = n->parms; +#ifdef CONFIG_ARP_PROBE_BCAST + return p->ucast_probes + p->app_probes + p->mcast_probes; +#else int max_probes = NEIGH_VAR(p, UCAST_PROBES) + NEIGH_VAR(p, APP_PROBES); if (!(n->nud_state & NUD_PROBE)) max_probes += NEIGH_VAR(p, MCAST_PROBES); return max_probes; +#endif } static void neigh_invalidate(struct neighbour *neigh) diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig index bd29016..4d13edb 100644 --- a/net/ipv4/Kconfig +++ b/net/ipv4/Kconfig @@ -259,6 +259,23 @@ config IP_PIMSM_V2 gated-5). This routing protocol is not used widely, so say N unless you want to play with it. +config ARP_PROBE_BCAST + bool "IP: ARP send broadcast ARP, if probing using unicast fails" + default y + ---help--- + When the neighbor statemachine is in PROBE state, it will + normally send a number of unicast ARP requests + (number defined in "ucast_probes" entry in the proc file system, default=3) + and if no reply is received, it will change state to FAILED. + + Saying Y here, will make the statemachine try to send broadcast ARP + requests, and only enter FAILED state if the broadcast ARP requests did not + receive a reply. + + Enabling this, makes the IPv4 ARP behaviour more similar to the IPv6 + Neighbor Discovery protocol, and is neccessary, if the other end + only responds to broadcast ARPs. + config SYN_COOKIES bool "IP: TCP syncookie support" ---help---