History

mac80211: keep sending peer candidate events while in listen state

Instead of sending peer candidate events just once, send them as long as the peer remains in the LISTEN state in the peering state machine, when userspace is implementing the peering manager. Userspace may silence the events from a peer by progressing the state machine or by setting the link state to BLOCKED. Fixes the problem that a mesh peering process won't be fired again after the previous first peering trial fails due to like air propagation error if the peering is managed by user space such as wpa_supplicant. This patch works with another patch for wpa_supplicant described here which fires a peering process again triggered by the notice from kernel. http://lists.shmoo.com/pipermail/hostap/2014-November/031235.html

Nishikawa, Kenzoh committed 11 years ago

Commit 2ae70ef1 parent 688b1ec1 file · +7 −0Browse files

Unified · Split

net/mac80211/mesh_plink.c+7−0
@@ -523,6 +523,13 @@ void mesh_neighbour_update(struct ieee80211_sub_if_data *sdata, · 522 unmodified lines
523 sdata->u.mesh.mshcfg.auto_open_plinks &&523 sdata->u.mesh.mshcfg.auto_open_plinks &&
524 rssi_threshold_check(sdata, sta))524 rssi_threshold_check(sdata, sta))
525 changed = mesh_plink_open(sta);525 changed = mesh_plink_open(sta);
526 else if (sta->plink_state == NL80211_PLINK_LISTEN &&
527 (sdata->u.mesh.user_mpm ||
528 sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED))
529 cfg80211_notify_new_peer_candidate(sdata->dev, hw_addr,
530 elems->ie_start,
531 elems->total_len,
532 GFP_ATOMIC);
526 533
527 ieee80211_mps_frame_release(sta, elems);534 ieee80211_mps_frame_release(sta, elems);
528out:535out:

Keyboard shortcuts

General

Show keyboard shortcuts
?
Focus the current search
/

Issues and pull requests

Open filters
f

Issues, pull requests and Inbox

Select next item
j↓
Select previous item
k↑
Open selected item
Enter
Dismiss filters or clear selection
Esc

Repository code

Go to file
t