netdev - Re: Is it valid to add a macvlan virtual interface to a bridge? If so, there seems to be a bug with it.

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: <20081206092448.0c83d606.ipng@69706e6720323030352d30312d31340a.nosense.org>
Date:	Sat, 6 Dec 2008 09:24:48 +1030
From:	Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
To:	Ben Greear <greearb@...delatech.com>
Cc:	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org
Subject: Re: Is it valid to add a macvlan virtual interface to a bridge? If
 so, there seems to be a bug with it.

Hi,

On Fri, 05 Dec 2008 09:43:25 -0800
Ben Greear <greearb@...delatech.com> wrote:

> Patrick McHardy wrote:
> 
> >> Should what I'm doing be working or possible? If not, could something
> >> be added to the kernel to prevent macvlan interfaces being added to
> >> bridge instances, to stop other people spending time trying to do what
> >> I've tried to do?
> > 
> > Unfortunately one of both combinations will not work, no matter
> > what we do. The bridge code could issue a warning when adding
> > a bridge on top of a macvlan device, but there's no clean indication
> > that something is a macvlan device besides dev->rtnl_link_ops->kind
> > being "macvlan".
> 
> A mac-vlan can't really be PROMISC either since it only receives
> BCAST frames and packets destined for it's own MAC, so I can't see
> how it could work in a bridge....
> 

Would handling of frames for promiscuous macvlan interfaces be quite
similar to handling of incoming broadcast and multicast frames e.g.
for an incoming frame, walk through the list of macvlan interfaces (or
a separate list of promiscuous macvlan interfaces) that are currently in
promiscuous mode, and hand them a copy of the incoming frame?

> user-space brctl could check for the driver string returned by
> ethtool API to check if no one wants any additional cruft in
> the kernel...
> 
> 
> You might try using a pair of VETH interfaces to bridge between
> your host and virtual host.
> 

What I was fundamentally trying to achieve was to avoid using any more
than one physical interface on the box (excepting a separate
management interface) to do this testing. While I happened to have
another unused interface I could bridge this virtual host onto, in some
cases you might not. Conceptually when using them, it is very easy to
think of the macvlan interfaces as nothing very different to having
multiple physical interfaces sitting on the same LAN segment. In my
scenario, bridging only one of them for this specific case of a
virtual guest host seemed like quite a logical thing to do.

Would veth interfaces facilitate the sharing of a single physical
interface between bridged and non-bridged processes on the host?

Regards,
Mark.
--
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