MLD queries are supposed to have an IPv6 link-local source address
according to RFC2710, section 4 and RFC3810, section 5.1.14. This patch
adds a sanity check to ignore such broken MLD queries.
Without this check, such malformed MLD queries can result in a
denial of service: The queries are ignore
On Mon, Mar 3, 2014 at 4:31 PM, Stephen Hemminger
wrote:
> On Mon, 3 Mar 2014 15:58:50 -0800
> "Luis R. Rodriguez" wrote:
>
>> On Mon, Mar 3, 2014 at 3:43 PM, Stephen Hemminger
>> wrote:
>> > Doing this in priv flags bloats what is a limited resource (# of bits).
>>
>> Agreed. I tried to avoid i
On Mon, 3 Mar 2014 15:58:50 -0800
"Luis R. Rodriguez" wrote:
> On Mon, Mar 3, 2014 at 3:43 PM, Stephen Hemminger
> wrote:
> > Doing this in priv flags bloats what is a limited resource (# of bits).
>
> Agreed. I tried to avoid it but saw no other option for addressing
> this during initializa
Hi Jan,
On Mon, Mar 03, 2014 at 05:45:49PM -0500, Jan Stancek wrote:
> There is also bridge on host B. I assume that doesn't matter
> but I could set up host B without bridge if needed.
It can matter, but in this case it doesn't :).
> > What I'm curious about is, whether the guest receives
> > t
On Mon, Mar 3, 2014 at 3:43 PM, Stephen Hemminger
wrote:
> Doing this in priv flags bloats what is a limited resource (# of bits).
Agreed. I tried to avoid it but saw no other option for addressing
this during initialization properly without requirng a userspace
upgrade.
> Plus there are issues
On Mon, 3 Mar 2014 14:47:03 -0800
"Luis R. Rodriguez" wrote:
> From: "Luis R. Rodriguez"
>
> root block support was added via 1007dd1a on v3.8 but toggling
> this flag is only allowed after a device has been registered and
> added to a bridge as its a bridge *port* primitive, not a *net_device
On Mon, Mar 03, 2014 at 04:40:40PM -0500, Vlad Yasevich wrote:
> I did notice a minor issue in the bridge code. The following
> code:
>/* Prevent flooding this packet if there is no listener present */
> if (!ipv6_addr_is_ll_all_nodes(&ip6h->daddr))
> BR_INPUT_SKB_C
From: "Luis R. Rodriguez"
The networking bridge module allows us to specify a
root block preference on net_devices but this feature
is a bridge port primitive. The bridge module assumes
that once a device is added as a slave to the brige
that it can be considered for the the root port.
Furthermor
From: "Luis R. Rodriguez"
The purpose of using a static MAC address of FE:FF:FF:FF:FF:FF
was to prevent our backend interfaces from being used by the
bridge and nominating our interface as a root port on the bridge.
This was possible given that the bridge code will use the lowest MAC
address for
From: "Luis R. Rodriguez"
Root port blocking was designed so that a bridge port can opt
out of becoming the designated root port for a bridge. If a port
however first becomes the designated root port and we then toggle
the root port block on it we currently don't kick that port out of
the designa
From: "Luis R. Rodriguez"
root block support was added via 1007dd1a on v3.8 but toggling
this flag is only allowed after a device has been registered and
added to a bridge as its a bridge *port* primitive, not a *net_device*
feature. There are work arounds possible to account for the lack
of netl
From: "Luis R. Rodriguez"
As it is now if you add create a bridge it gets started
with a random MAC address and if you then add a net_device
as a slave but later kick it out you end up with a zero
MAC address. Instead preserve the original random MAC
address and use it.
If you manually set the b
From: "Luis R. Rodriguez"
If netlink is used to tune a port we currently don't trigger a
new recalculation of the bridge id, ensure that happens just as
if we're adding a new net_device onto the bridge.
Cc: Stephen Hemminger
Cc: bridge@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Cc: l
Hi Jan,
On Mon, Mar 03, 2014 at 02:47:15PM -0500, Jan Stancek wrote:
> I'm seeing an issue where bridge (sometimes) stops forwarding ICMP6
> neighbor solicitation packets to KVM guest and as result KVM guest doesn't
> respond with neighbor advertisement.
Hm, okay, that's not supposed to happen.
(2014/02/27 0:18), Vlad Yasevich wrote:
> Keep track of bridge ports that have unicast flooding turned on.
> This will later be used by the algorithm to automatically manage
> address programming and promisc mode.
>
...
> @@ -383,6 +389,9 @@ int br_add_if(struct net_bridge *br, struct net_device
(2014/02/27 0:18), Vlad Yasevich wrote:
> If the user configures vlan interfaces on top of the bridge and the bridge
> doesn't have vlan filtering enabled, we have to place all the ports in
> promsic mode so that we can correctly receive tagged frames.
> When vlan filtering is enabled, the vlan con
On 20/02/14 20:24, Luis R. Rodriguez wrote:
On Thu, Feb 20, 2014 at 9:19 AM, Stephen Hemminger
wrote:
On Wed, 19 Feb 2014 09:59:33 -0800 "Luis R. Rodriguez"
wrote:
On Wed, Feb 19, 2014 at 9:08 AM, Stephen Hemminger
wrote:
Please only use the netlink/sysfs flags fields that already exist
On 20/02/14 20:01, Luis R. Rodriguez wrote:
On Thu, Feb 20, 2014 at 5:19 AM, Zoltan Kiss wrote:
How about this: netback sets the root_block flag and a random MAC by
default. So the default behaviour won't change, DAD will be happy, and
userspace don't have to do anything unless it's using netba
On 19/02/14 16:45, Luis R. Rodriguez wrote:
On Mon, Feb 17, 2014 at 9:52 AM, Zoltan Kiss wrote:
On 15/02/14 02:59, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
It doesn't make sense for some interfaces to become a root bridge
at any point in time. One example is virtual backend interf
On Fri, 2014-02-28 at 14:34 -0500, Vlad Yasevich wrote:
> On 02/27/2014 08:17 AM, Vlad Yasevich wrote:
> > On 02/27/2014 07:06 AM, Toshiaki Makita wrote:
> >> (2014/02/27 0:18), Vlad Yasevich wrote:
> >>> If the user configures vlan interfaces on top of the bridge and the bridge
> >>> doesn't have
On 19/02/14 09:52, Ian Campbell wrote:
On Tue, 2014-02-18 at 13:02 -0800, Luis R. Rodriguez wrote:
On Sun, Feb 16, 2014 at 10:57 AM, Stephen Hemminger
wrote:
On Fri, 14 Feb 2014 18:59:37 -0800
"Luis R. Rodriguez" wrote:
From: "Luis R. Rodriguez"
It doesn't make sense for some interfaces t
On 19/02/14 17:02, Luis R. Rodriguez wrote:
On Wed, Feb 19, 2014 at 6:35 AM, Zoltan Kiss wrote:
On 19/02/14 09:52, Ian Campbell wrote:
Can't we arrange things in the Xen hotplug scripts such that if the
root_block stuff isn't available/doesn't work we fallback to the
existing fe:ff:ff:ff:ff us
On 15/02/14 02:59, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
It doesn't make sense for some interfaces to become a root bridge
at any point in time. One example is virtual backend interfaces
which rely on other entities on the bridge for actual physical
connectivity. They only provide
On 03/01/2014 09:57 AM, Toshiaki Makita wrote:
> On Fri, 2014-02-28 at 14:34 -0500, Vlad Yasevich wrote:
>> On 02/27/2014 08:17 AM, Vlad Yasevich wrote:
>>> On 02/27/2014 07:06 AM, Toshiaki Makita wrote:
(2014/02/27 0:18), Vlad Yasevich wrote:
> If the user configures vlan interfaces on to
24 matches
Mail list logo
