build_patches: Add hack which fixes forwarding on a stacked bridge #211

fbl · 2022-02-27T01:53:52+01:00

fbl commented

2022-02-27 01:53:52 +01:00

Currently we are utilizing stacked bridges to keep configuration of DSA
devices as close as possible to swconfig devices. The lower bridge is
for configuration of the DSA hardware and is vlan-aware, while the upper
bridge is used to connect wireless interfaces to the client interface.

A packet arriving from the switch might have the offload_fwd_mark flag
set in the skb to prevent it from being sent to DSA ports, as this has
already been done in hardware.

However, this flag is not cleared before the skb is processed by the
upper bridge, which prevents it from being sent to any other ports of
that bridge. Therefore, communication is not possible between different
ports of that bridge, while communication with the bridge interface
itself is possible.

This issue affects both the layer3 and node variant, but due to the
layer 2 architecture of the node firmware, it is far more noticeable in
the node firmware, as it prevents ethernet clients from sending packets
to the gateway.

Work around this issue by clearing the offload_fwd_mark flag before
passing the skb up.

Fixes: #205

Currently we are utilizing stacked bridges to keep configuration of DSA devices as close as possible to swconfig devices. The lower bridge is for configuration of the DSA hardware and is vlan-aware, while the upper bridge is used to connect wireless interfaces to the client interface. A packet arriving from the switch might have the offload_fwd_mark flag set in the skb to prevent it from being sent to DSA ports, as this has already been done in hardware. However, this flag is not cleared before the skb is processed by the upper bridge, which prevents it from being sent to any other ports of that bridge. Therefore, communication is not possible between different ports of that bridge, while communication with the bridge interface itself is possible. This issue affects both the layer3 and node variant, but due to the layer 2 architecture of the node firmware, it is far more noticeable in the node firmware, as it prevents ethernet clients from sending packets to the gateway. Work around this issue by clearing the offload_fwd_mark flag before passing the skb up. Fixes: #205

fbl added this to the next-bugfix milestone 2022-02-27 01:53:52 +01:00

fbl self-assigned this 2022-02-27 01:53:52 +01:00

fbl added 1 commit 2022-02-27 01:53:52 +01:00

9e21995bca build_patches: Add hack which fixes forwarding on a stacked bridge

Currently we are utilizing stacked bridges to keep configuration of DSA
devices as close as possible to swconfig devices. The lower bridge is
for configuration of the DSA hardware and is vlan-aware, while the upper
bridge is used to connect wireless interfaces to the client interface.

A packet arriving from the switch might have the offload_fwd_mark flag
set in the skb to prevent it from being sent to DSA ports, as this has
already been done in hardware.

However, this flag is not cleared before the skb is processed by the
upper bridge, which prevents it from being sent to any other ports of
that bridge. Therefore, communication is not possible between different
ports of that bridge, while communication with the bridge interface
itself is possible.

This issue affects both the layer3 and node variant, but due to the
layer 2 architecture of the node firmware, it is far more noticeable in
the node firmware, as it prevents ethernet clients from sending packets
to the gateway.

Work around this issue by clearing the offload_fwd_mark flag before
passing the skb up.

Fixes: #205

Signed-off-by: Fabian Bläse <fabian@blaese.de>

fbl requested review from jkimmel 2022-02-27 01:54:00 +01:00

jkimmel approved these changes 2022-03-03 14:26:21 +01:00

jkimmel commented

2022-03-03 14:30:11 +01:00

Wir haben noch einmal zusammen das Problem über eine Stunde lang untersucht. Der Patch ist so erst einmal die richtige Lösung für das Problem. Möglicherweise ist das sogar eine Sache, die Upstream übernommen werden sollte.

Reviewed-by: Johannes Kimmel <fff@bareminimum.eu>

Wir haben noch einmal zusammen das Problem über eine Stunde lang untersucht. Der Patch ist so erst einmal die richtige Lösung für das Problem. Möglicherweise ist das sogar eine Sache, die Upstream übernommen werden sollte. `Reviewed-by: Johannes Kimmel <fff@bareminimum.eu>`

fbl modified the milestone from next-bugfix to 20220405-beta

2022-03-03 15:42:46 +01:00

fbl commented

2022-03-05 19:27:03 +01:00

Auf meinen staging tree applied.

fbl closed this pull request

2022-03-05 19:27:03 +01:00

fbl deleted branch dsabrfix

2022-03-05 19:27:06 +01:00