* [B.A.T.M.A.N.] Roaming trouble with bridge & multicast snooping
@ 2015-09-08 3:11 ` Linus Lüssing
0 siblings, 0 replies; 6+ messages in thread
From: Linus Lüssing @ 2015-09-08 3:11 UTC (permalink / raw)
To: bridge, b.a.t.m.a.n
Hi bridge folks,
I'm currently stuck with a simple scenario where enabling bridge
multicast snooping causes packetloss for some time:
----------
(c) <~~~> (A) <---> (B)
(c) is a wifi client, connected to a wifi access point (A).
(B) is another AP connected to (A) via ethernet cable.
The wifi-ap and ethernet interface are bridged on both (A) and (B).
Now (c) roams from (A) to (B):
(A) <---> (B) <~~~> (c)
----------
Until the next multicast query is send (up to 125 seconds), (c)
will experience multicast packet loss: (B) does not know which
multicast traffic (c) wants yet and blocks forwarding multicast
traffic to it.
I couldn't find an IETF standard or discussion saying something
about how to deal with multicast snooping and roaming yet (I still
have the feeling I must have overlooked something as this scenario
seems common to me). Does anyone know anything about that or how
vendors implement that on their snooping switches?
The behaviour of (c) running a 3.16 kernel is:
After setting its wifi interface up, it stays quiet. After getting
a link / wifi connects, it sends an IGMP/MLD report first, without
waiting for a query. It then sends the IPv6 Neighbor Solicitation
messages for Duplicate Address Detection to be able to claim its
own IPv6 addresses.
However it does not resend reports / Neighbor Solicitations after
the link goes down and up again while the interface itself stays up.
I could think of two ways to solve the issue:
Either let mac80211 (hostapd?) notify the bridge once a new client
connects. Then let the bridge send a query to the client
immediately and directly.
Or once the bridge adds an fdb entry for a new host, send a query
to this host (no matter if it's wireless or not) immediately,
directly.
The "directly" could be implemented by setting the ethernet
destination to the according unicast MAC instead.
Even though slightly more latency, I'd opt (and would going to
provide a patch) for the second case.
What do others think about this?
Cheers, Linus
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bridge] Roaming trouble with bridge & multicast snooping
@ 2015-09-08 3:11 ` Linus Lüssing
0 siblings, 0 replies; 6+ messages in thread
From: Linus Lüssing @ 2015-09-08 3:11 UTC (permalink / raw)
To: bridge, b.a.t.m.a.n
Hi bridge folks,
I'm currently stuck with a simple scenario where enabling bridge
multicast snooping causes packetloss for some time:
----------
(c) <~~~> (A) <---> (B)
(c) is a wifi client, connected to a wifi access point (A).
(B) is another AP connected to (A) via ethernet cable.
The wifi-ap and ethernet interface are bridged on both (A) and (B).
Now (c) roams from (A) to (B):
(A) <---> (B) <~~~> (c)
----------
Until the next multicast query is send (up to 125 seconds), (c)
will experience multicast packet loss: (B) does not know which
multicast traffic (c) wants yet and blocks forwarding multicast
traffic to it.
I couldn't find an IETF standard or discussion saying something
about how to deal with multicast snooping and roaming yet (I still
have the feeling I must have overlooked something as this scenario
seems common to me). Does anyone know anything about that or how
vendors implement that on their snooping switches?
The behaviour of (c) running a 3.16 kernel is:
After setting its wifi interface up, it stays quiet. After getting
a link / wifi connects, it sends an IGMP/MLD report first, without
waiting for a query. It then sends the IPv6 Neighbor Solicitation
messages for Duplicate Address Detection to be able to claim its
own IPv6 addresses.
However it does not resend reports / Neighbor Solicitations after
the link goes down and up again while the interface itself stays up.
I could think of two ways to solve the issue:
Either let mac80211 (hostapd?) notify the bridge once a new client
connects. Then let the bridge send a query to the client
immediately and directly.
Or once the bridge adds an fdb entry for a new host, send a query
to this host (no matter if it's wireless or not) immediately,
directly.
The "directly" could be implemented by setting the ethernet
destination to the according unicast MAC instead.
Even though slightly more latency, I'd opt (and would going to
provide a patch) for the second case.
What do others think about this?
Cheers, Linus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [B.A.T.M.A.N.] [Bridge] Roaming trouble with bridge & multicast snooping
2015-09-08 3:11 ` [Bridge] " Linus Lüssing
@ 2015-09-08 15:52 ` Stephen Hemminger
-1 siblings, 0 replies; 6+ messages in thread
From: Stephen Hemminger @ 2015-09-08 15:52 UTC (permalink / raw)
To: Linus Lüssing; +Cc: bridge, b.a.t.m.a.n
On Tue, 8 Sep 2015 05:11:22 +0200
Linus Lüssing <linus.luessing@c0d3.blue> wrote:
> Hi bridge folks,
>
> I'm currently stuck with a simple scenario where enabling bridge
> multicast snooping causes packetloss for some time:
>
> ----------
>
> (c) <~~~> (A) <---> (B)
>
> (c) is a wifi client, connected to a wifi access point (A).
> (B) is another AP connected to (A) via ethernet cable.
> The wifi-ap and ethernet interface are bridged on both (A) and (B).
>
>
> Now (c) roams from (A) to (B):
>
> (A) <---> (B) <~~~> (c)
>
> ----------
>
> Until the next multicast query is send (up to 125 seconds), (c)
> will experience multicast packet loss: (B) does not know which
> multicast traffic (c) wants yet and blocks forwarding multicast
> traffic to it.
>
> I couldn't find an IETF standard or discussion saying something
> about how to deal with multicast snooping and roaming yet (I still
> have the feeling I must have overlooked something as this scenario
> seems common to me). Does anyone know anything about that or how
> vendors implement that on their snooping switches?
>
>
> The behaviour of (c) running a 3.16 kernel is:
> After setting its wifi interface up, it stays quiet. After getting
> a link / wifi connects, it sends an IGMP/MLD report first, without
> waiting for a query. It then sends the IPv6 Neighbor Solicitation
> messages for Duplicate Address Detection to be able to claim its
> own IPv6 addresses.
>
> However it does not resend reports / Neighbor Solicitations after
> the link goes down and up again while the interface itself stays up.
>
>
> I could think of two ways to solve the issue:
>
> Either let mac80211 (hostapd?) notify the bridge once a new client
> connects. Then let the bridge send a query to the client
> immediately and directly.
>
> Or once the bridge adds an fdb entry for a new host, send a query
> to this host (no matter if it's wireless or not) immediately,
> directly.
>
>
> The "directly" could be implemented by setting the ethernet
> destination to the according unicast MAC instead.
>
>
> Even though slightly more latency, I'd opt (and would going to
> provide a patch) for the second case.
>
>
> What do others think about this?
The only entity in this scenario that knows that it has changed
state is (c). Why doesn't the client resend a IGMP when it notes
a connection change?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bridge] Roaming trouble with bridge & multicast snooping
@ 2015-09-08 15:52 ` Stephen Hemminger
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Hemminger @ 2015-09-08 15:52 UTC (permalink / raw)
To: Linus Lüssing; +Cc: bridge, b.a.t.m.a.n
On Tue, 8 Sep 2015 05:11:22 +0200
Linus Lüssing <linus.luessing@c0d3.blue> wrote:
> Hi bridge folks,
>
> I'm currently stuck with a simple scenario where enabling bridge
> multicast snooping causes packetloss for some time:
>
> ----------
>
> (c) <~~~> (A) <---> (B)
>
> (c) is a wifi client, connected to a wifi access point (A).
> (B) is another AP connected to (A) via ethernet cable.
> The wifi-ap and ethernet interface are bridged on both (A) and (B).
>
>
> Now (c) roams from (A) to (B):
>
> (A) <---> (B) <~~~> (c)
>
> ----------
>
> Until the next multicast query is send (up to 125 seconds), (c)
> will experience multicast packet loss: (B) does not know which
> multicast traffic (c) wants yet and blocks forwarding multicast
> traffic to it.
>
> I couldn't find an IETF standard or discussion saying something
> about how to deal with multicast snooping and roaming yet (I still
> have the feeling I must have overlooked something as this scenario
> seems common to me). Does anyone know anything about that or how
> vendors implement that on their snooping switches?
>
>
> The behaviour of (c) running a 3.16 kernel is:
> After setting its wifi interface up, it stays quiet. After getting
> a link / wifi connects, it sends an IGMP/MLD report first, without
> waiting for a query. It then sends the IPv6 Neighbor Solicitation
> messages for Duplicate Address Detection to be able to claim its
> own IPv6 addresses.
>
> However it does not resend reports / Neighbor Solicitations after
> the link goes down and up again while the interface itself stays up.
>
>
> I could think of two ways to solve the issue:
>
> Either let mac80211 (hostapd?) notify the bridge once a new client
> connects. Then let the bridge send a query to the client
> immediately and directly.
>
> Or once the bridge adds an fdb entry for a new host, send a query
> to this host (no matter if it's wireless or not) immediately,
> directly.
>
>
> The "directly" could be implemented by setting the ethernet
> destination to the according unicast MAC instead.
>
>
> Even though slightly more latency, I'd opt (and would going to
> provide a patch) for the second case.
>
>
> What do others think about this?
The only entity in this scenario that knows that it has changed
state is (c). Why doesn't the client resend a IGMP when it notes
a connection change?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [B.A.T.M.A.N.] [Bridge] Roaming trouble with bridge & multicast snooping
2015-09-08 15:52 ` Stephen Hemminger
@ 2015-09-10 14:42 ` Linus Lüssing
-1 siblings, 0 replies; 6+ messages in thread
From: Linus Lüssing @ 2015-09-10 14:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bridge, b.a.t.m.a.n
On Tue, Sep 08, 2015 at 08:52:56AM -0700, Stephen Hemminger wrote:
> Why doesn't the client resend a IGMP when it notes
> a connection change?
>
Good question, I actually had expected that too. My guess is that the
network stack might be interpreting the RFCs in a "conservative
way". RFC3376 ("Internet Group Management Protocol, Version 3" in
section 5 only describes the following two cases where a report should
be send:
-----
* a change of the interface reception state, caused by a local
invocation of IPMulticastListen [!= interface link state].
* reception of a Query.
-----
Seems like another case where no one @IETF had thought about
layer 2 multicast snooping :(.
> The only entity in this scenario that knows that it has changed
> state is (c).
Hm, (B) should know so too as (c) authenticates to an 802.11
access point first before using it. So the mac80211 on (B) should
be aware of the new host immediately.
I'm wondering whether it'd be sufficient to change multicast
listener behaviour in Linux or whether the majority of wifi capable
devices would still experience multicast packetloss on roaming.
Anyone having an Apple or Microsoft device :)?
Cheers, Linus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bridge] Roaming trouble with bridge & multicast snooping
@ 2015-09-10 14:42 ` Linus Lüssing
0 siblings, 0 replies; 6+ messages in thread
From: Linus Lüssing @ 2015-09-10 14:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bridge, b.a.t.m.a.n
On Tue, Sep 08, 2015 at 08:52:56AM -0700, Stephen Hemminger wrote:
> Why doesn't the client resend a IGMP when it notes
> a connection change?
>
Good question, I actually had expected that too. My guess is that the
network stack might be interpreting the RFCs in a "conservative
way". RFC3376 ("Internet Group Management Protocol, Version 3" in
section 5 only describes the following two cases where a report should
be send:
-----
* a change of the interface reception state, caused by a local
invocation of IPMulticastListen [!= interface link state].
* reception of a Query.
-----
Seems like another case where no one @IETF had thought about
layer 2 multicast snooping :(.
> The only entity in this scenario that knows that it has changed
> state is (c).
Hm, (B) should know so too as (c) authenticates to an 802.11
access point first before using it. So the mac80211 on (B) should
be aware of the new host immediately.
I'm wondering whether it'd be sufficient to change multicast
listener behaviour in Linux or whether the majority of wifi capable
devices would still experience multicast packetloss on roaming.
Anyone having an Apple or Microsoft device :)?
Cheers, Linus
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-09-10 14:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-08 3:11 [B.A.T.M.A.N.] Roaming trouble with bridge & multicast snooping Linus Lüssing
2015-09-08 3:11 ` [Bridge] " Linus Lüssing
2015-09-08 15:52 ` [B.A.T.M.A.N.] " Stephen Hemminger
2015-09-08 15:52 ` Stephen Hemminger
2015-09-10 14:42 ` [B.A.T.M.A.N.] " Linus Lüssing
2015-09-10 14:42 ` Linus Lüssing
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.