On 2017-01-11 13:15, IgorMitsyanko wrote:
> On 01/11/2017 02:30 PM, Felix Fietkau wrote:
>> On 2017-01-11 12:26, IgorMitsyanko wrote:
>>> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
On 2017-01-10 11:56, Johannes Berg wrote:
> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>
On 01/11/2017 02:30 PM, Felix Fietkau wrote:
On 2017-01-11 12:26, IgorMitsyanko wrote:
On 01/11/2017 12:27 AM, Felix Fietkau wrote:
On 2017-01-10 11:56, Johannes Berg wrote:
On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wro
On 2017-01-11 12:26, IgorMitsyanko wrote:
> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
>> On 2017-01-10 11:56, Johannes Berg wrote:
>>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> I wonder if MAC80211 should
On 01/11/2017 12:27 AM, Felix Fietkau wrote:
On 2017-01-10 11:56, Johannes Berg wrote:
On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
I wonder if MAC80211 should be doing IGMP snooping and not bridge
in this environmen
> > Exactly. My point is that this is breaking the expectation that
> > hosts are actually able to drop such packets.
>
> [readding CCs I removed earlier]
>
> Ah! Thanks. I was worried about creating packetloss :D.
Ah, well, no - at least not in this case.
> Hm, for this other other way round,
On 2017-01-10 11:56, Johannes Berg wrote:
> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>> > I wonder if MAC80211 should be doing IGMP snooping and not bridge
>> > in this environment.
>>
>> In the long term, yes. Fo
On Tue, Jan 10, 2017 at 9:23 AM, Felix Fietkau wrote:
> On 2017-01-10 18:17, Dave Taht wrote:
>> In the case of wifi I have 3 issues with this line of thought.
>>
>> multicast in wifi has generally supposed to be unreliable. This makes
>> it reliable. reliability comes at a cost -
>>
>> multicast
On 2017-01-10 18:17, Dave Taht wrote:
> In the case of wifi I have 3 issues with this line of thought.
>
> multicast in wifi has generally supposed to be unreliable. This makes
> it reliable. reliability comes at a cost -
>
> multicast is typically set at a fixed low rate today. unicast is
> retr
In the case of wifi I have 3 issues with this line of thought.
multicast in wifi has generally supposed to be unreliable. This makes
it reliable. reliability comes at a cost -
multicast is typically set at a fixed low rate today. unicast is
retried at different rates until it succeeds - for every
On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> > I wonder if MAC80211 should be doing IGMP snooping and not bridge
> > in this environment.
>
> In the long term, yes. For now, not quite sure.
There's no "for now" in t
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> I wonder if MAC80211 should be doing IGMP snooping and not bridge
> in this environment.
In the long term, yes. For now, not quite sure.
I personally like to go for simple solutions first :).
On Mon, Jan 09, 2017 at 10:42:46PM +0100, Johannes Berg wrote:
> On Mon, 2017-01-09 at 22:33 +0100, Linus Lüssing wrote:
> > On Mon, Jan 09, 2017 at 01:44:03PM +0100, Johannes Berg wrote:
> > >
> > > > > A host SHOULD silently discard a datagram that is
> > > > > received via
> > > > >
On Mon, 9 Jan 2017 22:23:45 +0100
Linus Lüssing wrote:
> On Mon, Jan 09, 2017 at 12:44:19PM +0100, M. Braun wrote:
> > Am 09.01.2017 um 09:08 schrieb Johannes Berg:
> > > Does it make sense to implement the two in separate layers though?
> > >
> > > Clearly, this part needs to be implemented i
On Mon, Jan 09, 2017 at 12:44:19PM +0100, M. Braun wrote:
> Am 09.01.2017 um 09:08 schrieb Johannes Berg:
> > Does it make sense to implement the two in separate layers though?
> >
> > Clearly, this part needs to be implemented in the bridge layer due to
> > the snooping knowledge, but the code is
On Mon, 2017-01-09 at 16:25 +0100, michael-dev wrote:
> Am 09.01.2017 13:15, schrieb Johannes Berg:
> > > That is bridge fdb entries (need to) expire so the bridge might
> > > "forget" a still-connected station not sending but only consuming
> > > broadcast traffic.
> >
> > Ok, that I don't know.
Am 09.01.2017 13:15, schrieb Johannes Berg:
That is bridge fdb entries (need to) expire so the bridge might
"forget" a still-connected station not sending but only consuming
broadcast traffic.
Ok, that I don't know. Somehow if you address a unicast packet there
the bridge has to make a decision
> > A host SHOULD silently discard a datagram that is received via
> > a link-layer broadcast (see Section 2.4) but does not specify
> > an IP multicast or broadcast destination address.
>
> This example is the other way round. It specifies how the IP
> destination shou
On Mon, Jan 09, 2017 at 09:05:49AM +0100, Johannes Berg wrote:
> On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote:
>
> > Actually, I do not quite understand that remark in the mac80211
> > multicast-to-unicast patch. IP should not care about the ethernet
> > header?
>
> But it does, for exa
On Mon, 2017-01-09 at 12:44 +0100, M. Braun wrote:
> Am 09.01.2017 um 09:08 schrieb Johannes Berg:
> > Does it make sense to implement the two in separate layers though?
> >
> > Clearly, this part needs to be implemented in the bridge layer due
> > to
> > the snooping knowledge, but the code is ve
Am 09.01.2017 um 09:08 schrieb Johannes Berg:
> Does it make sense to implement the two in separate layers though?
>
> Clearly, this part needs to be implemented in the bridge layer due to
> the snooping knowledge, but the code is very similar to what mac80211
> has now.
Does the bridge always kn
ler; bridge@lists.linux-
> foundation.org; linux-kernel@vger.kernel.org; linux-
> wirel...@vger.kernel.org; Felix Fietkau
> Objet : Re: [PATCH net-next] bridge: multicast to unicast
>
> On Mon, 2 Jan 2017 20:32:14 +0100
> Linus Lüssing wrote:
>
> > This feature is intended for int
On Sat, 2017-01-07 at 15:55 +0100, Linus Lüssing wrote:
> On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> > Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> > >
> > > > The bridge layer can use IGMP snooping to ensure that the
> > > > multicast
> > > > stream is only transmitted to clie
On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote:
> Actually, I do not quite understand that remark in the mac80211
> multicast-to-unicast patch. IP should not care about the ethernet
> header?
But it does, for example RFC 1122 states:
When a host sends a datagram to a link-layer
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the f
On Fri, Jan 06, 2017 at 07:13:56PM -0800, Stephen Hemminger wrote:
> On Mon, 2 Jan 2017 20:32:14 +0100
> Linus Lüssing wrote:
>
> > This feature is intended for interface types which have a more reliable
> > and/or efficient way to deliver unicast packets than broadcast ones
> > (e.g. wifi).
>
On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> >
> >> The bridge layer can use IGMP snooping to ensure that the multicast
> >> stream is only transmitted to clients that are actually a member of
> >> the group. Can the mac80211 feature d
Am 06.01.2017 um 14:54 schrieb Johannes Berg:
>
>> The bridge layer can use IGMP snooping to ensure that the multicast
>> stream is only transmitted to clients that are actually a member of
>> the group. Can the mac80211 feature do the same?
>
> No, it'll convert the packet for all clients that a
On Mon, 2 Jan 2017 20:32:14 +0100
Linus Lüssing wrote:
> This feature is intended for interface types which have a more reliable
> and/or efficient way to deliver unicast packets than broadcast ones
> (e.g. wifi).
Why is this not done in MAC80211 rather than bridge?
On 2017-01-06 14:54, Johannes Berg wrote:
>
>> The bridge layer can use IGMP snooping to ensure that the multicast
>> stream is only transmitted to clients that are actually a member of
>> the group. Can the mac80211 feature do the same?
>
> No, it'll convert the packet for all clients that are b
> The bridge layer can use IGMP snooping to ensure that the multicast
> stream is only transmitted to clients that are actually a member of
> the group. Can the mac80211 feature do the same?
No, it'll convert the packet for all clients that are behind that
netdev. But that's an argument for dropp
On 2017-01-06 13:47, Johannes Berg wrote:
> On Mon, 2017-01-02 at 20:32 +0100, Linus Lüssing wrote:
>> Implements an optional, per bridge port flag and feature to deliver
>> multicast packets to any host on the according port via unicast
>> individually. This is done by copying the packet per host
On Mon, 2017-01-02 at 20:32 +0100, Linus Lüssing wrote:
> Implements an optional, per bridge port flag and feature to deliver
> multicast packets to any host on the according port via unicast
> individually. This is done by copying the packet per host and
> changing the multicast destination MAC to
On 2017-01-02 20:32, Linus Lüssing wrote:
> Implements an optional, per bridge port flag and feature to deliver
> multicast packets to any host on the according port via unicast
> individually. This is done by copying the packet per host and
> changing the multicast destination MAC to a unicast one
On 02/01/17 20:32, Linus Lüssing wrote:
Implements an optional, per bridge port flag and feature to deliver
multicast packets to any host on the according port via unicast
individually. This is done by copying the packet per host and
changing the multicast destination MAC to a unicast one accordi
34 matches
Mail list logo
