From: Benjamin Berg benjamin@sipsolutions.net
[ 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 ---
Based on my analysis of the commit and the code, here is my assessment: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## 1. Bug Fix Analysis The commit fixes a clear logical bug in the mesh networking HWMP (Hybrid Wireless Mesh Protocol) path selection algorithm. When `dot11MeshForwarding` is disabled, the code was incorrectly: - Still performing mesh path lookups for PREQ (Path Request) messages - Potentially replying with mesh path information even though forwarding was disabled - Creating indirect mesh path entries when it shouldn't ## 2. Code Analysis Looking at the changes in `/net/mac80211/mesh_hwmp.c:619-676`: **Before the fix:** - Line 639: `} else {` - The final else branch handles the case where the target is neither local nor broadcast - Lines 640-656: This section performs mesh path lookup and potentially replies with path information **regardless** of forwarding status - Line 657: `} else {` - Only sets `forward = false` but after potentially harmful operations **After the fix:** - Line 639: `} else if (ifmsh->mshcfg.dot11MeshForwarding) {` - Now conditions the mesh path lookup on forwarding being enabled - Lines 657-659: `} else { forward = false; }` - Clean fallback when forwarding is disabled ## 3. Impact Assessment This is a **contained, low-risk fix** that: - **Fixes incorrect behavior**: Prevents mesh nodes from providing routing information when they won't actually forward packets - **Prevents resource waste**: Avoids unnecessary mesh path lookups when forwarding is disabled - **Improves network correctness**: Fixes the inconsistency where nodes advertise paths they won't use - **Addresses real-world issue**: The commit message mentions this was observed in the Freifunk community ## 4. Comparison with Similar Commits This fix aligns perfectly with the **YES** backport examples: **Similar to Commit #1 (mesh: Do not send PREQ if HWMP is disabled):** - Both prevent sending/processing mesh protocol messages when a feature is disabled - Both are small, surgical fixes to logical conditions - Both prevent waste of network resources **Similar to Commit #3 (fix mesh path discovery):** - Both fix incorrect mesh path handling logic - Both have small, focused changes - Both include explicit mention of fixing behavior observed in real deployments **Similar to Commit #4 (fix mesh forwarding):** - Both are mesh forwarding-related fixes - Both are minimal changes with clear intent - Both fix protocol correctness issues ## 5. Stable Backport Criteria Check ✅ **Fixes important bug**: Yes - incorrect mesh protocol behavior ✅ **Small and contained**: Yes - only 4 lines changed, well-isolated ✅ **No new features**: Correct - only fixes existing logic ✅ **No architectural changes**: Correct - just reorders existing conditions ✅ **Low regression risk**: Very low - change is localized and logical ✅ **Clear side effects**: None beyond the intended fix ## 6. Risk Assessment The change is **extremely low risk** because: - It only affects the specific case where `dot11MeshForwarding` is disabled - It makes the code behavior more consistent (when forwarding is off, don't provide path info) - The change is in line with the intended semantics of the forwarding flag - It's a pure logic fix without touching data structures or complex algorithms This commit represents exactly the type of fix that stable trees are meant to include: a small, well-understood bug fix that improves correctness without introducing regression risk.
net/mac80211/mesh_hwmp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c index 295f98b4502e0..ae1c700dc82e8 100644 --- a/net/mac80211/mesh_hwmp.c +++ b/net/mac80211/mesh_hwmp.c @@ -620,7 +620,7 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata, mesh_path_add_gate(mpath); } rcu_read_unlock(); - } else { + } else if (ifmsh->mshcfg.dot11MeshForwarding) { rcu_read_lock(); mpath = mesh_path_lookup(sdata, target_addr); if (mpath) { @@ -638,6 +638,8 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata, } } rcu_read_unlock(); + } else { + forward = false; }
if (reply) { @@ -655,7 +657,7 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata, } }
- if (forward && ifmsh->mshcfg.dot11MeshForwarding) { + if (forward) { u32 preq_id; u8 hopcount;