netdev - Re: Bridging behavior apparently changed around the Fedora 14 time

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]

Date:	Mon, 11 Jul 2011 13:49:38 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	"Greg Scott" <GregScott@...rasupport.com>
Cc:	<netdev@...r.kernel.org>,
	"Lynn Hanson" <LynnHanson@...anhills.org>,
	"Joe Whalen" <JoeWhalen@...anhills.org>
Subject: Re: Bridging behavior apparently changed around the Fedora 14 time

On Mon, 11 Jul 2011 15:41:35 -0500
"Greg Scott" <GregScott@...rasupport.com> wrote:

> The NICs are 3Com 3C905B's.  The iptables config is complex - I'll paste
> in the relevant pieces.  Note that it all works as expected when I put
> the br0 device into promiscuous mode.  I included all the layer 2 MAC
> address info in the original email.  
> 
> > Do you have reverse path filtering enabled/disabled?  
> 
> rp_filter doesn't seem to effect the behavior one way or the other.
> I've tried with rp_filter set to both 0 and 1 on eth0, eth1, and br0
> with no change in behavior.  

What about console dmesg output.
Because you can fix by putting in promiscuous mode, I suspect the
problem is outside of the bridge itself, could be the drivers.
The bridge itself puts the device into promiscuous mode already.

Lastly, the Fedora and upstream kernels are not exactly the same.
Please retest with a standard upstream kernel (like 2.6.39.2).
--
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