netdev - Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure

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:	Fri, 11 Jan 2013 15:53:54 +0200
From:	Shmulik Ladkani <shmulik.ladkani@...il.com>
To:	vyasevic@...hat.com, Stephen Hemminger <shemminger@...tta.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, stephen@...hat.com,
	bridge@...ts.linux-foundation.org, mst@...hat.com
Subject: Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering
 infrastructure

Hi,

On Thu, 10 Jan 2013 20:14:01 -0500 Vlad Yasevich <vyasevic@...hat.com> wrote:
> On 01/10/2013 05:10 PM, Stephen Hemminger wrote:
> > Also the concept of different filters for egress vs ingress is feature
> > madness. It doesn't make sense to have half-duplex connectivity.
> 
> I am of the same opinion, but it actually simplified the code quite a 
> bit, but at the cost of additional memory footprint.  If you find this
> very objectionable, I can easily remove it.

Haven't looked on the V5 series yet, but just to clarify:

There's *no* different membership _filter_ for egress vs ingress.
The vlan's membership map is consulted on both ingress and egress.

However, upon egress, a vlan egress _policy_ should be applied, which
determines whether the frame should egress tagged/untagged on the egress
port.

The expected logic in detailed in [1] (please read "steps 1..5").
and the data structures needed are:
  - per port: PVID
  - per VLAN: port membership map
  - per VLAN: port egress policy map

Altough on 1st look it might look mad ;-)
But, this is genuinely simple, highly configurable and allows great
flexibility (IMO with no additional code complexity; Vlad can probably
comment).

The motivation is to be aligned with behavior and configurability of
vlan switches.

Regards,
Shmulik

[1]
http://marc.info/?l=linux-netdev&m=135603447030826&w=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