Lars, > A first analysis gives that the two delays are the ieee80211_sta_work() > timeout. There are many events trigging ieee80211_sta_work(), but > since only the timer sets IEEE80211_STA_REQ_RUN, nothing will happen. TBH I really no longer know the 2.6.30 code well, so I don't know. > Questions; > - Why does mac80211 tells the wpa_supplicant that the AP > is gone (87.632965), and then blocks/delays the actions taken by the > wpa_supplicant? The real question is: why the hell is it probing the AP? > [ 87.632965] wlan0: deauthenticated (Reason: 1) > [ 87.733979] [B] LaE: SCANRQUEST: SSID=AGV > [ 88.629931] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 1 > [ 88.829932] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 2 > [ 89.029944] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 3 > [ 89.230016] wlan0: direct probe to AP 00:40:96:a0:e7:e7 timed out It doesn't really block actions, but it delays the scan because it's busy doing the probing. So only after the probing fails will it start the scan, and complete it within about 1.4 seconds. > - Why are some wpa_supplicant actions (90.702325) > not event driven? > > It looks to me as if we have to decision makers here. For me the > wpa_supplicant is the one that make the decision. Once the mac80211 > gives up and feedback that the AP is gone, it should just sit > and wait for next decision from the wpa_supplicant. I agree -- the spurious probing is strange. But I also have to admit that basically I don't care as long as it works -- most of this is just a side effect of how wireless extensions work. > I had a few patches for this for .26, but since the code is changed > they do not apply. Before I create new patches I would like to get > your opinion on this. I would suggest you just use wpa_supplicant -Dnl80211, which should help a lot with this kind of things. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
