]> 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:05:32 +0000 (11:05 +0100)
commitd7ef254e72074b48b4d6cad5fa0b49d8b1566e3d
treed298b4bf4ae05f4a1c5ed0f89cc288f5e5baae4e
parent0d4a81c341ebc10e8b0e45405702dadb296e8bbf
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