mac80211: don't invalidate SN on discovery failure
PATCH 1/1 mac80211: don't invalidate SN on discovery failure
From: Jesse Jones <[email protected]>
The 2012 spec mentions that path SNs can be invalid when created (see section 13.10.8.4 table 13-9) but AFAICT never talks about invalidating SNs. Which makes sense: if we have figured out the path to a target at a certain SN then we want to remember that fact. Failing to do so can lead to routing loops because if we don't have a valid SN then we have no way of knowing whether an incoming path message leads to or away from the target.
However currently when discovery fails we zero out mpath->flags which clears MESH_PATH_SN_VALID. This patch fixes that so that only the discovery relevant flags are cleared.
---
net/mac80211/mesh_hwmp.c +2 -1
@@ -1176,7 +1176,8 @@ void mesh_path_timer(unsigned long data)spin_unlock_bh (&mpath->state_lock);mesh_queue_preq (mpath,0 ); }else { - mpath->flags =0 ; + mpath->flags &= ~(MESH_PATH_RESOLVING | +MESH_PATH_RESOLVED |MESH_PATH_REQ_QUEUED ); mpath->exp_time = jiffies;spin_unlock_bh (&mpath->state_lock);if (!mpath->is_gate &&mesh_gate_num (sdata) >0 ) {
Quoted 10 lines · Alexis Green
From: Jesse Jones <[email protected]>
The 2012 spec mentions that path SNs can be invalid when created (see section 13.10.8.4 table 13-9) but AFAICT never talks about invalidating SNs. Which makes sense: if we have figured out the path to a target at a certain SN then we want to remember that fact. Failing to do so can lead to routing loops because if we don't have a valid SN then we have no way of knowing whether an incoming path message leads to or away from the target.
Quoted 3 lines
However currently when discovery fails we zero out
mpath->flagswhich clearsMESH_PATH_SN_VALID. This patch fixes that so that only the discovery relevant flags are cleared.
Applied; I fixed the indentation a bit.
Also, please mention "mesh" in the future in the subject of your patches, it makes it easier to pick out.
johannes