netdev - Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D6D658C.90300@gmail.com>
Date:	Tue, 01 Mar 2011 22:30:52 +0100
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Andy Gospodarek <andy@...yhouse.net>
CC:	Jay Vosburgh <fubar@...ibm.com>, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	Jiri Pirko <jpirko@...hat.com>
Subject: Re: [PATCH net-2.6] bonding: drop frames received with master's	source
 MAC

Le 01/03/2011 19:16, Andy Gospodarek a écrit :

[snip]

> Knowing that I'm using an unmanaged switch with balance-rr probably
> helps understand how this is happening.  I'll clarify this however, so
> we are all on the same page.
>
> In my situation, eth2 and eth3 are in bond0.  When bond0 transmits the
> NS, let's say it goes out eth3.  Since it is a multicast frame my switch
> will broadcast this to all ports and eth2 will receive the frame with
> the source MAC address being the same as bond0's MAC address.  This
> frame is passed up the stack to the ipv6 layer and appears to be a
> response to the NS from another host and is dropped.

'sounds perfectly normal.

This problem is described in detail in chapter 5.4.3 and appendix A of RFC4862 "IPv6 Stateless 
Address Autoconfiguration".

As this is clearly IPv6 related, it sounds normal from my point of view to fix it at the 
ndisc_recv_ns() level.

Quoting the RFC:

   "In those cases where the hardware cannot suppress loopbacks, however,
    one possible software heuristic to filter out unwanted loopbacks is
    to discard any received packet whose link-layer source address is the
    same as the receiving interface's.  There is even a link-layer
    specification that requires that any such packets be discarded
    [IEEE802.11].  Unfortunately, use of that criteria also results in
    the discarding of all packets sent by another node using the same
    link-layer address.  Duplicate Address Detection will fail on
    interfaces that filter received packets in this manner:

    [snip]

    Thus, to perform Duplicate Address Detection correctly in the case
    where two interfaces are using the same link-layer address, an
    implementation must have a good understanding of the interface's
    multicast loopback semantics, and the interface cannot discard
    received packets simply because the source link-layer address is the
    same as the interface's."

So, simply dropping frames whose source MAC == local MAC is apparently not the right solution.

	Nicolas.
--
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