Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Mon, 2009-02-23 at 18:37 +0200, Kalle Valo wrote: > >> @@ -1356,6 +1359,8 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata, >> bss_conf->assoc_capability = capab_info; >> ieee80211_set_associated(sdata, changed); >> >> + ifmgd->last_beacon = jiffies; >> + > > That looks a little misplaced; I think it's actually intended > anyway? Yes, it's intended. We need to initialise the variable after a successful association, otherwise this test in ieee80211_associated() will trigger immediately: if (time_after(jiffies, ifmgd->last_beacon + IEEE80211_MONITORING_INTERVAL)) { printk(KERN_DEBUG "%s: beacon loss from AP %pM " "- sending probe request\n", sdata->dev->name, ifmgd->bssid); > Maybe add a comment? I will. >> - sta->last_rx = jiffies; >> + if (rx->sdata->vif.type == NL80211_IFTYPE_STATION && >> + ieee80211_is_beacon(hdr->frame_control)) { >> + rx->sdata->u.mgd.last_beacon = jiffies; >> + } else >> + sta->last_rx = jiffies; > > would it be more appropriate to do that in the function that processes > the beacon in mlme.c? Or does that not work because of the workqueue and > timing? The test is there because I didn't want to include beacons to sta->last_rx timestamp. That way I can send probe requests only during data path idle period: if (time_after(jiffies, sta->last_rx + IEEE80211_PROBE_IDLE_TIME)) { ifmgd->flags |= IEEE80211_STA_PROBEREQ_POLL; ieee80211_send_probe_req(sdata, ifmgd->bssid, ifmgd->ssid, ifmgd->ssid_len, NULL, 0); } sta->last_rx is used in master mode as well, so I might have to do some trickery if I move the code to mlme.c. But I do share your view of having mlme related code in mlme.c, it makes life a lot easier. I need to think this a bit more. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html