]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
wifi: mac80211: do not offer a mesh path if forwarding is disabled
authorBenjamin Berg <benjamin@sipsolutions.net>
Wed, 30 Apr 2025 19:10:42 +0000 (21:10 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 27 Jun 2025 10:07:34 +0000 (11:07 +0100)
commitc2dfce3d291ffb05914958c5d5cc1eebe211cd81
tree078f9b96c4993797f448c771d97ed25e6d2b5cfa
parentb42c3e22e9d0bfeb2643c95f750149dd83affe31
wifi: mac80211: do not offer a mesh path if forwarding is disabled

[ Upstream commit cf1b684a06170d253b47d6a5287821de976435bd ]

When processing a PREQ the code would always check whether we have a
mesh path locally and reply accordingly. However, when forwarding is
disabled then we should not reply with this information as we will not
forward data packets down that path.

Move the check for dot11MeshForwarding up in the function and skip the
mesh path lookup in that case. In the else block, set forward to false
so that the rest of the function becomes a no-op and the
dot11MeshForwarding check does not need to be duplicated.

This explains an effect observed in the Freifunk community where mesh
forwarding is disabled. In that case a mesh with three STAs and only bad
links in between them, individual STAs would occionally have indirect
mpath entries. This should not have happened.

Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Reviewed-by: Rouven Czerwinski <rouven@czerwinskis.de>
Link: https://patch.msgid.link/20250430191042.3287004-1-benjamin@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net/mac80211/mesh_hwmp.c