netdev - Re: [PATCH v2] mac80211: add assoc beacon timeout logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Nov 2013 17:41:07 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	linux-wireless Mailing List <linux-wireless@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v2] mac80211: add assoc beacon timeout logic

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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html