netdev - Re: [PATCH RFC 0/7] Non-promisc bidge ports support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <530EB313.7090400@redhat.com>
Date:	Wed, 26 Feb 2014 22:37:55 -0500
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>, netdev@...r.kernel.org
CC:	bridge@...ts.linux-foundation.org, shemminger@...tta.com,
	mst@...hat.com, john.r.fastabend@...el.com
Subject: Re: [PATCH RFC 0/7] Non-promisc bidge ports support

On 02/26/2014 06:59 PM, Jamal Hadi Salim wrote:
> On 02/26/14 10:18, Vlad Yasevich wrote:
>> This patch series is a complete re-design and re-implementation of
>> prior attempts to support non-promiscuous bridge ports.
>>
>> The basic design is as follows.  The bridge keeps track of
>> all the ports that flood packets to unknown destinations.  If
>> the flooding is disabled on the port, to get traffic to flow
>> through, user/management would need to add an fdb describing
>> such traffic.  When such fdb is added, we save the address
>> to bridge private hardware address list.
> 
> Entering the addresses in the uc list on other bridgeports seems
> reasonable for the scenario described.
> But would it _also_ need to be added to the fdb of the bridge?
> i.e how does the bridge (if the packet was to be handed to it)
> know where to forward?

The fdb described here is actually added to the bridge.  In the case
when we are turning promiscuous mode off on a port, we program the
address from the fdb down to the port uc list as well.  This allows
the bridge to continue receiving traffic destined for this address even
though the port is not in promiscuous mode.

> BTW: on the comment that flooding off implies learning off: I would like
> to be able to turn off flooding on a specific bridge port but
> still want to learn from it. I dont think those two are mutually
> exclusive.

No they are not, but it does lead to some very interesting traffic
hang-ups that I've experienced first hand.  Everything works great
in the beginning.  However, if you go idle for a long enough period
that the fdb times out, re-establishing the connection take a rather
long time due to unicast ARPs being dropped by the bridge.  You end
up waiting until arp fails and switches to broadcast to restore the
connection.  So, this mode isn't really recommended.  Nothing currently
forbids it however.

-vlad
> 
> cheers,
> jamal

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