netdev - 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-next>] [day] [month] [year] [list]

Date:	Thu, 4 Dec 2008 20:33:52 +1030
From:	Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
To:	kaber@...sh.net, netdev@...r.kernel.org
Subject: Is it valid to add a macvlan virtual interface to a bridge? If so,
 there seems to be a bug with it.

Hi,

Is it valid to add a macvlan interface to a bridge? I've been having
some trouble with inbound unicast traffic not being forwarded into or
across the bridge, yet inbound broadcast or outbound unicast traffic
being delivered across the bridge correctly.

My setup has been as follows:

o  One physical ethernet interface, purely used to "host" macvlan
interfaces i.e. no IP address, not added to the bridge.

o  Quite a number of macvlan interfaces (I've found the limit of
99 :-) ).

o  Most of those macvlan interfaces are used by individual
instances of roaring penguin pppoe-server. This has worked fine.

o  One of the macvlan interfaces is in a bridge instance, with the
other interface in the bridge being a tap interface. Attached to the
tap interface is guest virtual host, also running a pppoe server.

This bridged macvlan setup seemed to be working ok, as I was seeing
incoming broadcast traffic and outgoing unicast traffic. My full setup
wasn't working correctly, so I spent quite a bit of time investigating
other possible causes. I finally came back around to the bridged macvlan
interface, and then noticed that only incoming unicast traffic wasn't
being bridged/forwarded to the device behind the tap interface.
Bridging the tap interface with another real physical interface resolved
the issue.

I've had a look at the dev.c file in 2.6.27, and my very naive guess
is that as the handle_bridge() call is before the handle_macvlan() call,
because the incoming real physical interface is not part of the bridge,
the incoming unicast packet is being dropped, before the macvlan code
gets a look at it.

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?

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