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] [day] [month] [year] [list]
Message-ID: <4D8E4D75.1020206@gmail.com>
Date:	Sat, 26 Mar 2011 21:32:53 +0100
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Michał Mirosław <mirqus@...il.com>,
	Leonardo Borda <leonardo.borda@...onical.com>
CC:	Jiri Pirko <jpirko@...hat.com>,
	Nicolas de Pesloüan 
	<nicolas.2p.debian@...e.fr>,
	Bridge <bridge@...ts.linux-foundation.org>,
	bonding-devel@...ts.sourceforge.net,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Bonding-devel] bonding inside a bridge does not work when using
 arp monitoring

Le 26/03/2011 16:42, Michał Mirosław a écrit :
> 2011/3/26 Jiri Pirko<jpirko@...hat.com>:
>> Sat, Mar 26, 2011 at 01:20:22PM CET, nicolas.2p.debian@...il.com wrote:
>>> Le 23/03/2011 22:13, Leonardo Borda a écrit :
>>>> Thank you for answering my question.
>>>> Actually this is what I want to achieve:
>>>>
>>>> eth0----+               +----bond0.100----br0-100---{+virtual machines
>>>>            |             |
>>>>            +----bond0----+----br0---(LAN)
>>>>            |             |
>>>> eth1----+               +----bond0.200----br0-200---{+virtual machines
>>>
>>> Hi Leonardo,
>>>
>>> I'm not sure recent kernels allow for a given interface to be a port
>>> for a bridge and the base interface for vlan interfaces at the same
>>> time. This might be particularly true for 2.6.38 or 2.6.38+, because
>>> of the new rx_handler usage.
>>
>> This topology is not legit and should/will be prohibited.
>>
>> Only consider that you have + br0.100 device on top of br0. Where should
>> the packet go?
>>
>> I suggest to consider topology change.
>
> It should be possible to have bridge for untagged (or 802.1p only)
> packets independent of 802.1q tagged packets. I wonder if tag 0
> devices should be expanded to have a flag that will enable handling
> untagged packets by it.

Isn't the BROUTING chain of the broute table of ebtables designed exactly for that?

I think DROPing in this chain should allow delivery to VLAN:

In br_input.c :

                 rhook = rcu_dereference(br_should_route_hook);
                 if (rhook) {
                         if ((*rhook)(skb)) {
                                 *pskb = skb;
                                 return RX_HANDLER_PASS;
                         }

RX_HANDLER_PASS causes the skb to be normally delivered in __netif_receive_skb.

Leonardo, would you please try to DROP vlan tagged packets in the BROUTING chain of the broute table 
of ebtables?

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