On Mon, 2013-11-11 at 10:23 -0600, Felipe Contreras wrote: > The driver is not receiving it at all. I already debugged this: > > http://article.gmane.org/gmane.linux.kernel.wireless.general/115429 Hmm, ok. I pretty much didn't read that thread since some others were jumping in. > However, I noticed that once in a very long time, sometimes it does > receive the corrupted frame and the association continues, and the > driver code detects it's a corrupted beacon frame. So how does it treat the corruption? > > The firmware still > > shouldn't be filtering anything since it doesn't really look at the > > beacon information (or maybe it filters based on the DS IE? I'm not > > entirely sure) > > That's what I thought, but I don't see it at all (only in monitor > mode, and in ad-hoc). Yes, that part is odd - that's really the root cause. I didn't quickly find in the threads what device and firmware you were using, mind identifying it (again)? > Nope, it keeps trying forever. > > Oct 13 14:33:15 nysa kernel: wlan0: authenticate with e0:1d:3b:46:82:a0 > Oct 13 14:33:15 nysa kernel: wlan0: send auth to e0:1d:3b:46:82:a0 (try 1/3) > Oct 13 14:33:15 nysa kernel: wlan0: authenticated > Oct 13 14:33:15 nysa kernel: wlan0: waiting for beacon from e0:1d:3b:46:82:a0 > Oct 13 14:33:18 nysa kernel: wlan0: authenticate with e0:1d:3b:46:82:a0 > Oct 13 14:33:18 nysa kernel: wlan0: send auth to e0:1d:3b:46:82:a0 (try 1/3) > Oct 13 14:33:18 nysa kernel: wlan0: authenticated > Oct 13 14:33:18 nysa kernel: wlan0: waiting for beacon from e0:1d:3b:46:82:a0 > Oct 13 14:33:22 nysa kernel: wlan0: authenticate with e0:1d:3b:46:82:a0 > Oct 13 14:33:22 nysa kernel: wlan0: send auth to e0:1d:3b:46:82:a0 (try 1/3) > Oct 13 14:33:22 nysa kernel: wlan0: authenticated > Oct 13 14:33:22 nysa kernel: wlan0: waiting for beacon from e0:1d:3b:46:82:a0 > ... I see the same behaviour - but it's the supplicant's doing, it is indeed getting the event that the AP connection failed (timed out): wlan0: Event ASSOC_TIMED_OUT (15) received > > This isn't really true like I said above - the kernel can only drop the > > association, if userspace *insists* then it will try again and again. > > But it's not doing this: > > ieee80211_destroy_assoc_data(sdata, false); > cfg80211_assoc_timeout(sdata->dev, bss); > > Which is what causes the association to stop for me. > > So where exactly in the code is the association being "dropped"? This does get called in my setup. > I would rather fix the problem at the two levels, so even if the > firmware passes the corrupt frames correctly, the driver would still > somewhat work when there's no beacon frames at all. Like I said before - trying to work with an AP without beacons at all is really bad, we shouldn't be doing it. We might not properly react to radar events, and other things, for example. johannes -- 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
