| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 6 Oct 2011 17:03:46 -0700
From: Yinglin Sun <Yinglin.Sun@....com>
To: Jay Vosburgh <fubar@...ibm.com>
Cc: Neil Horman <nhorman@...driver.com>,
"David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
James Morris <jmorris@...ei.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] IPv6: DAD from bonding iface is treated as dup address
from others
On Thu, Oct 6, 2011 at 3:17 PM, Yinglin Sun <Yinglin.Sun@....com> wrote:
>
> On Thu, Oct 6, 2011 at 12:05 PM, Jay Vosburgh <fubar@...ibm.com> wrote:
> >
> > Neil Horman <nhorman@...driver.com> wrote:
> >
> > >On Wed, Oct 05, 2011 at 08:59:10PM -0700, Yinglin Sun wrote:
> > >> Steps to reproduce this issue:
> > >> 1. create bond0 over eth0 and eth1, set the mode to balance-xor
> > >> 2. add an IPv6 address to bond0
> > >> 3. DAD packet is sent out from one slave and then is looped back from
> > >> the other slave. Therefore, it is treated as a duplicate address and
> > >> stays tentative afterwards:
> > >> kern.info:
> > >> Oct 5 11:50:18 testvm1 kernel: [ 129.224353] bond0: IPv6 duplicate address 1234::1 detected!
> > >>
> > >> Signed-off-by: Yinglin Sun <Yinglin.Sun@....com>
> > >> ---
> > >> net/ipv6/ndisc.c | 15 +++++++++++++--
> > >> 1 files changed, 13 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> > >> index 9da6e02..c82f4c7 100644
> > >> --- a/net/ipv6/ndisc.c
> > >> +++ b/net/ipv6/ndisc.c
> > >> @@ -809,9 +809,10 @@ static void ndisc_recv_ns(struct sk_buff *skb)
> > >>
> > >> if (ifp->flags & (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)) {
> > >> if (dad) {
> > >> + const unsigned char *sadr;
> > >> + sadr = skb_mac_header(skb);
> > >> +
> > >> if (dev->type == ARPHRD_IEEE802_TR) {
> > >> - const unsigned char *sadr;
> > >> - sadr = skb_mac_header(skb);
> > >> if (((sadr[8] ^ dev->dev_addr[0]) & 0x7f) == 0 &&
> > >> sadr[9] == dev->dev_addr[1] &&
> > >> sadr[10] == dev->dev_addr[2] &&
> > >> @@ -821,6 +822,16 @@ static void ndisc_recv_ns(struct sk_buff *skb)
> > >> /* looped-back to us */
> > >> goto out;
> > >> }
> > >> + } else if (dev->type == ARPHRD_ETHER) {
> > >> + if (sadr[6] == dev->dev_addr[0] &&
> > >> + sadr[7] == dev->dev_addr[1] &&
> > >> + sadr[8] == dev->dev_addr[2] &&
> > >> + sadr[9] == dev->dev_addr[3] &&
> > >> + sadr[10] == dev->dev_addr[4] &&
> > >> + sadr[11] == dev->dev_addr[5]) {
> > >> + /* looped-back to us */
> > >> + goto out;
> > >> + }
> > >> }
> > >>
> > >> /*
> > >> --
> > >> 1.7.4.1
> > >>
> > >Nack, This seems like it will just completely break DAD. What if theres another
> > >system out there with the same mac address. A response from that system would
> > >get dropped by this filter, instead of causing The local system to stop using
> > >the address. What you really want to do is modify
> > >bond_should_deliver_exact_match to detect this frame on the inactive slave or
> > >some such, and drop the frame there.
> >
> > Also NACK; and adding a bit of information. The balance-xor
> > mode is nominally expecting to interact with a switch whose ports are
> > set for etherchannel ("static link aggregation"), in which case the
> > switch will not loop the packet back around.
> >
> > If your switch can do etherchannel, then enable it and the
> > problem should go away. If your switch cannot do this, then you may
> > have other issues, because all of the multicast or broadcast packets
> > going out any bonding slave will loop around to another slave. You
> > could also use 802.3ad / LACP if you switch supports that.
> >
> > For balance-xor (or balance-rr, for that matter) mode to a
> > non-etherchannel switch, it's going to be difficult, if not impossible,
> > to modify bond_should_deliver_exact_match, because there are no inactive
> > slaves. In this mode, bonding is expecting the switch to balance
> > incoming traffic across the ports, and not deliver looped back packets
> > or duplicates. There are no restrictions on what type of traffic
> > (mcast, bcast, ucast) may arrive on any given port.
> >
> > I can't think of a way to make the non-etherchannel case work
> > for balance-xor (or balance-rr) without breaking the DAD functionality
> > in the case of an actual duplicate. I'm not aware of a way to
> > distinguish a looped back DAD probe from an actual duplicate address
> > probe elsewhere on the network.
> >
>
> Hi Neil & Jay,
>
> Thanks a lot for the comments.
>
> The use case is to add IPv6 address on the bonding interface first,
> and then set up port channel on switch. We'll hit this issue and the
> new address will stay tentative and unusable after port channel is set
> up on switch. This patch is for this valid use case.
>
> Except failover mode, all slaves are active on receiving packets, so
> we are receiving such looped back DAD and the bonding driver cannot
> ignore them. I cannot think of a way to distinguish if a DAD is looped
> back or from someone else having the same mac address. They look the
> same to the host. If there is another machine having the same mac
> address, this code path gets executed if both are doing DAD at the
> same time for the same IPv6 address. Maybe we should find out what the
> specification defines for this case?
>
RFC4862 has a discussion about this issue:
http://tools.ietf.org/html/rfc4862#appendix-A
The better solution could be to record the number of DAD sent out. If
we received more DAD packets than we sent out, there is someone else
on the network who has the same mac address and sent DAD for the same
IPv6 address. However, this solution doesn't work with bonding
interface, since all other active slaves but the one sending out DAD
will receive packet looped back. It doesn't seem there is a simple
solution for this issue.
Yinglin
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists