Re: [PATCH 3.2 01/06] "bridge should send gratuitous ARP to notify peer while a bond, which is a port of this bridge, changes."

ent, we need br0 send a gratuitous > ARP > to notify peer to update ARP table. > > Signed-off-by: Xing.Qingjie <xqjc...@gmail.com> > --- > net/bridge/br_notify.c | 12 > 1 files changed, 12 insertions(+), 0 deletions(-) > diff --git a/net/bridge/br_notify.

[PATCH net-next 03/11] ibmvnic: Send gratuitous arp on reset

From: John Allen <jal...@linux.vnet.ibm.com> Send gratuitous arp after any reset. Signed-off-by: John Allen <jal...@linux.vnet.ibm.com> --- drivers/net/ethernet/ibm/ibmvnic.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/

Re: [PATCH v2 0/4] arp: always override existing neigh entries with gratuitous ARP

On Wed, May 24, 2017 at 11:32 PM, Ihar Hrachyshka wrote: > On 05/23/2017 01:56 PM, Arnd Bergmann wrote: >> >> This seems to have caused a build warning: >> >> net/ipv4/arp.c:880:35: warning: 'addr_type' may be used uninitialized >> in this function [-Wmaybe-uninitialized] >>

Re: [PATCH v2 0/4] arp: always override existing neigh entries with gratuitous ARP

On 05/23/2017 01:56 PM, Arnd Bergmann wrote: This seems to have caused a build warning: net/ipv4/arp.c:880:35: warning: 'addr_type' may be used uninitialized in this function [-Wmaybe-uninitialized] Not sure. How do you reproduce it? I just did 'make net' in the latest tree that includes the

Re: [PATCH v2 0/4] arp: always override existing neigh entries with gratuitous ARP

On Thu, May 18, 2017 at 9:41 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > This patchset is spurred by discussion started at > https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no > real reason for enforcing override by gratuitous ARP packets only wh

Re: [PATCH v2 0/4] arp: always override existing neigh entries with gratuitous ARP

From: Ihar Hrachyshka <ihrac...@redhat.com> Date: Thu, 18 May 2017 12:41:17 -0700 > This patchset is spurred by discussion started at > https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no > real reason for enforcing override by gratuitous ARP pa

[PATCH v2 4/4] arp: always override existing neigh entries with gratuitous ARP

Currently, when arp_accept is 1, we always override existing neigh entries with incoming gratuitous ARP replies. Otherwise, we override them only if new replies satisfy _locktime_ conditional (packets arrive not earlier than _locktime_ seconds since the last update to the neigh entry). The idea

[PATCH v2 0/4] arp: always override existing neigh entries with gratuitous ARP

This patchset is spurred by discussion started at https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no real reason for enforcing override by gratuitous ARP packets only when arp_accept is 1. Same should happen when it's 0 (the default value). changelog v2: handled review

Re: [PATCH 2/2] arp: always override existing neigh entries with gratuitous ARP

Hello, On Wed, 17 May 2017, Ihar Hrachyshka wrote: > Currently, when arp_accept is 1, we always override existing neigh > entries with incoming gratuitous ARP replies. Otherwise, we override > them only if new replies satisfy _locktime_ conditional (packets arrive > not

[PATCH 2/2] arp: always override existing neigh entries with gratuitous ARP

Currently, when arp_accept is 1, we always override existing neigh entries with incoming gratuitous ARP replies. Otherwise, we override them only if new replies satisfy _locktime_ conditional (packets arrive not earlier than _locktime_ seconds since the last update to the neigh entry). The idea

[PATCH 0/2] arp: always override existing neigh entries with gratuitous ARP

Good day. This patchset is spurred by discussion started at https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no real reason for enforcing override by gratuitous ARP packets only when arp_accept is 1. Same should happen when it's 0 (the default value). The first patch

Re: [PATCH] arp: honour gratuitous ARP _replies_

te neighbour address > when a gratuitous arp is received and arp_accept is set") > > There is a glitch in the patch though. RFC 2002, section 4.6, "ARP, > Proxy ARP, and Gratuitous ARP", defines gratuitous ARPs so that they can > be either of Request or Reply ty

Re: [PATCH v2] arp: honour gratuitous ARP _replies_

When arp_accept is 1, gratuitous ARPs are supposed to override matching entries irrespective of whether they arrive during locktime. This was implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address when a gratuitous arp is received and arp_accept is set") There i

Re: [PATCH] arp: honour gratuitous ARP _replies_

When arp_accept is 1, gratuitous ARPs are supposed to override matching entries irrespective of whether they arrive during locktime. This was implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address when a gratuitous arp is received and arp_accept is set") There i

Re: [PATCH] arp: honour gratuitous ARP _replies_

From: Ihar Hrachyshka Date: Tue, 9 May 2017 17:16:07 -0700 > @@ -842,8 +844,20 @@ static int arp_process(struct net *net, struct sock *sk, > struct sk_buff *skb) > It is possible, that this option should be enabled for some > devices

[PATCH] arp: honour gratuitous ARP _replies_

When arp_accept is 1, gratuitous ARPs are supposed to override matching entries irrespective of whether they arrive during locktime. This was implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address when a gratuitous arp is received and arp_accept is set") There i

Re: [PATCH] arp: Race condition in gratuitous ARP reception handling.

From: Date: Thu, 2 Mar 2017 14:59:47 +0100 > @@ -836,19 +843,30 @@ static int arp_process(struct net *net, struct sock > *sk, struct sk_buff *skb) > n = __neigh_lookup(_tbl, , dev, 0); > > if (IN_DEV_ARP_ACCEPT(in_dev)) { > - unsigned int

[PATCH] arp: Race condition in gratuitous ARP reception handling.

From: Tomasz Dzieciol <tomasz.dziec...@nokia.com> Fix an issue where is_garp variable is not set when arp_accept option is disabled for a net device. There might be a situation where gratuitous ARP will be ignored when an existing neighbour is updated in a time smaller than LOCKTIME (for e

Re: bridge not learning from locally sent gratuitous ARP?

> So, assuming that proives stable, I have a workaround - but one that > needs knowlege of A) the unterlying interface (brport) to fondle, and > B) the macvlan MAC address that needs adding. keepalived couldn't > easily do that "in code" because it does not know what sits under the > bridge. > >

Re: bridge not learning from locally sent gratuitous ARP?

On Thu, Apr 21, 2016 at 12:31 PM, Toshiaki Makita wrote: > On 2016/04/21 15:37, Patrick Schaaf wrote: > (I understand the problem happens only if you use macvlan on the bridge > device. If wrong, correct me.) That is my understanding, yes. That macvlan device is

Re: bridge not learning from locally sent gratuitous ARP?

lived, with VRRP VMAC > - keepalived regularly sending gratuitous ARP with that VRRP VMAC > - (new) an additional tap interface in br0, for an openvpn link > > In principle, everything is working fine. The base keepalived setup > has been in operation for a long time, running directly ove

bridge not learning from locally sent gratuitous ARP?

Dear netdev, I've got a peculiar issue, and hope for clarification / workarounds here. Scenario: - a bridge interface br0, over some ethernet base - a macvlan interface br0-vrrp on top, set up by keepalived, with VRRP VMAC - keepalived regularly sending gratuitous ARP with that VRRP VMAC - (new

Re: [PATCH v3 2/4] ipv4: add option to drop gratuitous ARP packets

From: Johannes Berg <johan...@sipsolutions.net> Date: Thu, 4 Feb 2016 13:31:18 +0100 > From: Johannes Berg <johannes.b...@intel.com> > > In certain 802.11 wireless deployments, there will be ARP proxies > that use knowledge of the network to correctly answer requests.

[PATCH v3 2/4] ipv4: add option to drop gratuitous ARP packets

From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be ARP proxies that use knowledge of the network to correctly answer requests. To prevent gratuitous ARP frames on the shared medium from being a problem, on such deployments wireless needs t

[PATCH v3 2/4] ipv4: add option to drop gratuitous ARP packets

From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be ARP proxies that use knowledge of the network to correctly answer requests. To prevent gratuitous ARP frames on the shared medium from being a problem, on such deployments wireless needs t

[PATCH v2 3/4] ipv4: add option to drop gratuitous ARP packets

From: Johannes Berg <johannes.b...@intel.com> In certain 802.11 wireless deployments, there will be ARP proxies that use knowledge of the network to correctly answer requests. To prevent gratuitous ARP frames on the shared medium from being a problem, on such deployments wireless needs t

Re: [PATCH 3/4] ipv4: add option to drop gratuitous ARP packets

On Sat, 2015-04-11 at 13:59 +0300, Julian Anastasov wrote: >  > May be only arptable_filter can help here to > protect ARP? > Finally reviving an ancient thread ... I checked, butI don't see a way to match tip==sip. You can match on each, but not against each other. johannes -- To

Re: [PATCH] bonding: Gratuitous ARP gets dropped when first slave added

From: Venkat Venkatsubra venkat.x.venkatsu...@oracle.com Date: Tue, 11 Aug 2015 07:57:23 -0700 When the first slave is added (such as during bootup) the first gratuitous ARP gets dropped. We don't see this drop during a failover. The packet gets dropped in qdisc (noop_enqueue). The fix

[PATCH] bonding: Gratuitous ARP gets dropped when first slave added

When the first slave is added (such as during bootup) the first gratuitous ARP gets dropped. We don't see this drop during a failover. The packet gets dropped in qdisc (noop_enqueue). The fix is to delay the sending of gratuitous ARPs till the bond dev's carrier is present. It can also be worked

Re: [PATCH][kernel 2.6.32] Bond interface can't send gratuitous ARP

didn't take effect. It couldn't send gratuitous ARP. So I made a patch to fix this issue. It's my first patch for kernel. Thanks a lot for your *understanding* for any *inconvenience* caused. Patches may only be sent for mainline kernel. Since you're trying to fix 2.6.32, you first need

PATCH V6 7/8] net/bonding: Delay sending of gratuitous ARP to avoid failure

); + if (bond-curr_active_slave + test_bit(__LINK_STATE_LINKWATCH_PENDING, + bond-curr_active_slave-dev-state)) { + dprintk(delaying gratuitous arp on %s\n, + bond

[PATCH 7/9] net/bonding: Delay sending of gratuitous ARP to avoid failure

(delaying gratuitous arp on %s\n, + bond-curr_active_slave-dev-name); + bond-send_grat_arp = 1; + } else + bond_send_gratuitous_arp(bond); } } @@ -2073,6 +2079,17 @@ void bond_mii_monitor(struct net_device

PATCH V6 7/9] net/bonding: Delay sending of gratuitous ARP to avoid failure

gratuitous arp on %s\n, + bond-curr_active_slave-dev-name); + bond-send_grat_arp = 1; + } else + bond_send_gratuitous_arp(bond); } } @@ -2083,6 +2089,17 @@ void bond_mii_monitor(struct net_device

PATCH V5 9/11] net/bonding: Delay sending of gratuitous ARP to avoid failure

gratuitous arp on %s\n, + bond-curr_active_slave-dev-name); + bond-send_grat_arp = 1; + } else + bond_send_gratuitous_arp(bond); } } @@ -2083,6 +2089,17 @@ void bond_mii_monitor(struct net_device

[PATCH 9/11] net/bonding: Delay sending of gratuitous ARP to avoid failure

gratuitous arp on %s\n, + bond-curr_active_slave-dev-name); + bond-send_grat_arp = 1; + } else + bond_send_gratuitous_arp(bond); } } @@ -2083,6 +2089,17 @@ void bond_mii_monitor(struct net_device

PATCH V4 9/10] net/bonding: Delay sending of gratuitous ARP to avoid failure

gratuitous arp on %s\n, + bond-curr_active_slave-dev-name); + bond-send_grat_arp = 1; + } else + bond_send_gratuitous_arp(bond); } } @@ -2083,6 +2089,17 @@ void bond_mii_monitor(struct net_device

[PATCH V3 7/7] net/bonding: Delay sending of gratuitous ARP to avoid failure

, new_active-dev-addr_len); - - bond_send_gratuitous_arp(bond); + if (bond-curr_active_slave + test_bit(__LINK_STATE_LINKWATCH_PENDING, bond-curr_active_slave-dev-state)){ + dprintk(delaying gratuitous arp on %s\n,bond-curr_active_slave

Re: [PATCH V3 7/7] net/bonding: Delay sending of gratuitous ARP to avoid failure

Moni Shoua [EMAIL PROTECTED] wrote: Delay sending a gratuitous_arp when LINK_STATE_LINKWATCH_PENDING bit in dev-state field is on. This improves the chances for the arp packet to be transmitted. Under what circumstances were you seeing problems that delaying the gratuitous ARP until

Re: gratuitous arp

On Sun, 26 Nov 2006, James Courtier-Dutton wrote: dean gaudet wrote: On Sun, 26 Nov 2006, James Courtier-Dutton wrote: dean gaudet wrote: hi... i ran into some problems recently which would have been avoided if my box did a gratuitous arp as it brought up all interfaces (the router took

Re: gratuitous arp

On Sun, 26 Nov 2006, James Courtier-Dutton wrote: dean gaudet wrote: On Sun, 26 Nov 2006, James Courtier-Dutton wrote: dean gaudet wrote: hi... i ran into some problems recently which would have been avoided if my box did a gratuitous arp as it brought up all

Re: gratuitous arp

before i go opening bugs with the distribution folks, could someone chime in as to what is the recommended approach these days? did grat arp fall out of favour, or is it just a case of userland not keeping up? The ifup script in iproute2 does it in user land, but nobody uses it directly

gratuitous arp

hi... i ran into some problems recently which would have been avoided if my box did a gratuitous arp as it brought up all interfaces (the router took forever to timeout the ARP entries for interface aliases). so i set about looking to see why that wasn't happening. i either missed

Re: gratuitous arp

dean gaudet wrote: hi... i ran into some problems recently which would have been avoided if my box did a gratuitous arp as it brought up all interfaces (the router took forever to timeout the ARP entries for interface aliases). so i set about looking to see why that wasn't happening. i

Re: gratuitous arp

On Sun, 26 Nov 2006, James Courtier-Dutton wrote: dean gaudet wrote: hi... i ran into some problems recently which would have been avoided if my box did a gratuitous arp as it brought up all interfaces (the router took forever to timeout the ARP entries for interface aliases). so i

Re: gratuitous arp

On Sat, 2006-11-25 at 18:31 -0800, dean gaudet wrote: but there's no gratuitous arp for any eth0:N aliased interfaces... and the cisco ARP cache on this ISP router seems to be set to a long timeout. i could reach eth0:N from local net, but couldn't get outside local net from eth0:N