From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Andy Gospodarek <andy@greyhouse.net>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
Herbert Xu <herbert@gondor.hengli.com.au>,
Jay Vosburgh <fubar@us.ibm.com>, Jiri Pirko <jpirko@redhat.com>
Subject: Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC
Date: Fri, 25 Feb 2011 23:04:27 +0100 [thread overview]
Message-ID: <4D68276B.90104@gmail.com> (raw)
In-Reply-To: <1298668408-14849-1-git-send-email-andy@greyhouse.net>
Le 25/02/2011 22:13, Andy Gospodarek a écrit :
> I was looking at my system and wondering why I sometimes saw these
> DAD messages in my logs:
>
> bond0: IPv6 duplicate address fe80::21b:21ff:fe38:2ec4 detected!
>
> I traced it back and realized the IPv6 Neighbor Solicitations I was
> sending were also coming back into the stack on the slave(s) that did
> not transmit the frames. I could not think of a compelling reason to
> notify the user that a NS we sent came back, so I set out to just drop
> the frame silently in ndisc_recv_ns drop.
>
> That seemed to work well, but when I thought about it I could not
> compelling reason to save any of these frames. Dropping them as soon as
> we get them seems like a much better idea as it fixes other issues that
> may exist for more than just IPv6 DAD.
>
> I chose to check the incoming frame against the master's MAC address as
> that should be the MAC address used anytime a broadcast frame is sent by
> the bonding driver that had the chance to make its way back into one of
> the other devices.
I think this could break the ARP monitoring. ARP monitoring rely on a normal protocol handler,
registered in bond_main.c.
void bond_register_arp(struct bonding *bond)
{
struct packet_type *pt = &bond->arp_mon_pt;
if (pt->type)
return;
pt->type = htons(ETH_P_ARP);
pt->dev = bond->dev;
pt->func = bond_arp_rcv;
dev_add_pack(pt);
}
For as far as I understand, some variants of arp_validate require the backup interfaces to receive
ARP requests sent from the master, through the active interface, presumably with the master MAC as
the source MAC.
As this protocol handler is registered at the master level, the exact match logic in
__netif_receive_skb(), which apply at the slave level, shouldn't deliver this skb to bond_arp_rcv().
Can someone confirm ? Jay ?
Nicolas.
> Signed-off-by: Andy Gospodarek<andy@greyhouse.net>
> Cc: David Miller<davem@davemloft.net>
> Cc: Herbert Xu<herbert@gondor.apana.org.au>
> Cc: Jay Vosburgh<fubar@us.ibm.com>
> Cc: Jiri Pirko<jpirko@redhat.com>
>
> ---
>
> I realize this patch comes right in the middle of Jiri Pirko's attempts
> to move this functionality to the bonding driver, but I think this may
> be important enough to include now (possibly in 2.6.38 and to -stable)
> if others agree.
>
> ---
> net/core/dev.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8ae6631..4a76ccd 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2971,6 +2971,11 @@ static inline void skb_bond_set_mac_by_master(struct sk_buff *skb,
> int __skb_bond_should_drop(struct sk_buff *skb, struct net_device *master)
> {
> struct net_device *dev = skb->dev;
> + struct ethhdr *eth = eth_hdr(skb);
> +
> + /* Drop all frames with the bond master's source address. */
> + if (unlikely(!compare_ether_addr(eth->h_source, master->dev_addr)))
> + return 1;
>
> if (master->priv_flags& IFF_MASTER_ARPMON)
> dev->last_rx = jiffies;
next prev parent reply other threads:[~2011-02-25 22:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-25 21:13 [PATCH net-2.6] bonding: drop frames received with master's source MAC Andy Gospodarek
2011-02-25 22:04 ` Nicolas de Pesloüan [this message]
2011-02-25 22:24 ` Andy Gospodarek
2011-02-25 23:08 ` Nicolas de Pesloüan
2011-02-28 16:32 ` Andy Gospodarek
2011-02-28 21:45 ` Nicolas de Pesloüan
2011-03-01 2:35 ` Andy Gospodarek
2011-03-01 5:46 ` Jay Vosburgh
2011-03-01 18:16 ` Andy Gospodarek
2011-03-01 21:30 ` Nicolas de Pesloüan
2011-03-01 22:25 ` Jay Vosburgh
2011-03-01 23:08 ` Nicolas de Pesloüan
[not found] ` <AANLkTi=QTDNBf7Jskj55NP64Os8kgEs1WMpFGHMo+K3B@mail.gmail.com>
2011-03-02 12:30 ` Herbert Xu
2011-03-02 20:30 ` Nicolas de Pesloüan
2011-03-02 20:26 ` Nicolas de Pesloüan
2011-02-25 22:28 ` Jay Vosburgh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D68276B.90104@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=herbert@gondor.hengli.com.au \
--cc=jpirko@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).