| 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
| ||
|
Date: Fri, 05 Dec 2008 09:43:25 -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. 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.... 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. 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