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: <4939C269.4010609@candelatech.com>
Date:	Fri, 05 Dec 2008 16:08:09 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
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.

Mark Smith wrote:
> Hi,

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

That could probably work.

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

A Veth pair is like two ports linked back to each other..what is tx'd on one
is rx'd on the other.

You could probably add eth0, veth1a, veth2a to a bridge,
then add macvlans on veth1b and have your virtual guest
talk to veth2b.

I do similar things with my redirdev devices, which are almost identical
to veths, so I think it will work.

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ