[PATCH 11/12] mesh: Send peering open frame again if beacon from listen state peer is received
Masashi Honma
masashi.honma
Tue Nov 4 23:29:34 PST 2014
2014-11-04 23:12 GMT+09:00 Bob Copeland <me at bobcopeland.com>:
>> @@ -411,7 +412,7 @@ static void plink_timer(void *eloop_ctx, void *user_data)
>> /* confirm timer */
>> if (!reason)
>> reason = WLAN_REASON_MESH_CONFIRM_TIMEOUT;
>> - sta->plink_state = PLINK_HOLDING;
>> + wpa_mesh_set_plink_state(wpa_s, sta, PLINK_HOLDING);
>> eloop_register_timeout(conf->dot11MeshHoldingTimeout / 1000,
>> (conf->dot11MeshHoldingTimeout % 1000) * 1000,
>> plink_timer, wpa_s, sta);
>
> I think this is an unrelated change?
Yes. Unrelated.
>
>> #ifdef CONFIG_IEEE80211N
>> copy_sta_ht_capab(data, sta, elems->ht_capabilities,
>> - elems->ht_capabilities_len);
>> + elems->ht_capabilities_len);
>> update_ht_state(data, sta);
>> #endif /* CONFIG_IEEE80211N */
>
> Unrelated change.
This is unrelated. wpa_supplicant coding rule.
>> @@ -537,11 +538,12 @@ void wpa_mesh_new_mesh_peer(struct wpa_supplicant *wpa_s, const u8 *addr,
>> int ret = 0;
>>
>> sta = ap_get_sta(data, addr);
>> - if (!sta) {
>> - sta = ap_sta_add(data, addr);
>> - if (!sta)
>> - return;
>> - }
>> + if (sta != NULL)
>> + return;
>> +
>> + sta = ap_sta_add(data, addr);
>> + if (sta == NULL)
>> + return;
>
> This is an unrelated change.
Ordinary processing is like this.
--------
kernel: Receive a beacon from peer
kernel: Fire notify_new_peer_candidate event
wpa_supplicant: Receive EVENT_NEW_PEER_CANDIDATE event
wpa_supplicant: Start peering
wpa_supplicant: Success peering
--------
But peering can fail like this.
--------
kernel: Receive a beacon from peer
kernel: Fire notify_new_peer_candidate event
wpa_supplicant: Receive EVENT_NEW_PEER_CANDIDATE event
wpa_supplicant: Start peering
wpa_supplicant: *** FAIL *** peering (because of fail to receive
peerinf frame etc...)
kernel: Receive a beacon from peer
kernel: Don't fire notify_new_peer_candidate event. Because of known peer
wpa_supplicant: Can not start peering any more
--------
This patch fix the problem like this.
--------
kernel: Receive a beacon from peer
kernel: Fire notify_new_peer_candidate event
wpa_supplicant: Receive EVENT_NEW_PEER_CANDIDATE event
wpa_supplicant: Start peering
wpa_supplicant: *** FAIL *** peering (because of fail to receive
peerinf frame etc...)
kernel: Receive a beacon from peer
kernel: Fire notify_new_peer_candidate event <- new !
wpa_supplicant: Receive EVENT_NEW_PEER_CANDIDATE event
--------
We modified linux kernel mac80211 (See attached file "patch_kernel") to fire
notify_new_peer_candidate event even if the sta is known.
So now wpa_supplicant can re-start peering.
>
>
>> @@ -588,10 +590,15 @@ void wpa_mesh_new_mesh_peer(struct wpa_supplicant *wpa_s, const u8 *addr,
>> return;
>> }
>>
>> - if (conf->security == MESH_CONF_SEC_NONE)
>> - mesh_mpm_plink_open(wpa_s, sta, PLINK_OPEN_SENT);
>> - else
>> - mesh_rsn_auth_sae_sta(wpa_s, sta);
>> + if (sta->plink_state == PLINK_LISTEN) {
>> + if (!sta->my_lid)
>> + mesh_mpm_init_link(wpa_s, sta);
>> + if (conf->security == MESH_CONF_SEC_NONE) {
>> + mesh_mpm_plink_open(wpa_s, sta, PLINK_OPEN_SENT);
>> + } else {
>> + mesh_rsn_auth_sae_sta(wpa_s, sta);
>> + }
>> + }
>> }
>
> I guess this, plus masking off the ASSOC flag, are the functionality
> changes of interest. Hmm, I would expect plink_state to always be
> LISTEN at this point. We already call mesh_mpm_init_link()
> unconditionally at the top of this function.
Sorry. This is my mistake on merge.
The sentense should be outside of if clause.
See attached "patch_wpa_supplicant".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_kernel
Type: application/octet-stream
Size: 724 bytes
Desc: not available
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20141105/391e5d39/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_wpa_supplicant
Type: application/octet-stream
Size: 3475 bytes
Desc: not available
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20141105/391e5d39/attachment-0001.obj>
More information about the Hostap
mailing list