From: Felipe Contreras <hidden> Date: 2013-11-11 16:23:05
On Mon, Nov 11, 2013 at 9:43 AM, Johannes Berg
[off-list ref] wrote:
On Mon, 2013-11-11 at 04:59 -0600, Felipe Contreras wrote:
quoted
Well the AP is sending beacons, but they seem to be corrupted,
although the corruption often seems to happen in a place that is not
so important.
Indeed - the beacon you sent to me in private is damaged somewhere
towards the end of the frame. Are we actually receiving it but ignoring
it because it doesn't have the data we need?
The driver is not receiving it at all. I already debugged this:
http://article.gmane.org/gmane.linux.kernel.wireless.general/115429
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.
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).
quoted
However, if I apply this patch, I don't notice any issue, it
associates and works fine. Maybe there's some subtle issues with
features I don't personally use, or perhaps there's the occasional
disconnection (although that could be due to something else), but
that's light years away from not associating at all.
I'd say between a) some features not working and b) nothing working at
all, a) is preferred.
If you think it's better that nothing works at all, then wouldn't it
make sense to time out and return an error? Currently we just keep
trying to associate *forever*.
That's wpa_supplicant/userspace behaviour. The kernel will just drop the
connection.
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
...
quoted
quoted
If the AP is sending beacons but the device isn't receiving them, then
it's a driver bug and mac80211 shouldn't work around it.
I agree, but I can't seem to convince Intel guys of that. The firmware
is dropping the corrupt beacon frames (although not always), so
there's nothing the driver can do afterwards.
You realize I work for the same team in Intel as well? :)
Now I do.
quoted
But even if there were not beacons at all (corrupt or otherwise), I
still think waiting *forever* in a loop is not ideal, a) is preferred;
not having all the features, but still somehow work (from my point of
view it's more than somewhat).
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"?
I'd much rather try to get to the bottom of this. Maybe the firmware is
dropping the beacon because the DS IE is broken? Or are we receiving it
but ignoring it because it's broken?
It's not the latter.
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.
Unfortunately, there's only so much we can do to work around broken APs.
Indeed, but 'so much' for this AP is really nothing, while with my
patch it's quite a lot.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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?
quoted
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
quoted
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
From: Felipe Contreras <hidden> Date: 2013-11-11 16:54:00
On Mon, Nov 11, 2013 at 10:41 AM, Johannes Berg
[off-list ref] wrote:
On Mon, 2013-11-11 at 10:23 -0600, Felipe Contreras wrote:
quoted
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?
wlan0: associating with AP with corrupt beacon
quoted
quoted
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
Not in my setup.
quoted
quoted
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.
Yes, because your setup is receiving beacons.
Check the code:
if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
ieee80211_do_assoc(sdata)) {
struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
ieee80211_destroy_assoc_data(sdata, false);
cfg80211_assoc_timeout(sdata->dev, bss);
}
If there's no beacon, cfg80211_assoc_timeout() is not called.
I'm sure if you don't call ieee80211_rx_mgmt_beacon() at all you will
see the same behavior I see.
quoted
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.
Why not? For all intents and purposes my system is not receiving any
beacons, and I don't see any problems.
What would you prefer? That nothing works at all?
We might not properly react to
radar events, and other things, for example.
So? I don't know what that means, but it can't be worst than not being
able to connect to the Internet whatsoever at all.
Cheers.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2013-11-11 16:56:58
On Mon, Nov 11, 2013 at 10:53 AM, Felipe Contreras
[off-list ref] wrote:
On Mon, Nov 11, 2013 at 10:41 AM, Johannes Berg
[off-list ref] wrote:
quoted
On Mon, 2013-11-11 at 10:23 -0600, Felipe Contreras wrote:
quoted
quoted
quoted
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.
Yes, because your setup is receiving beacons.
Check the code:
if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
ieee80211_do_assoc(sdata)) {
struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
ieee80211_destroy_assoc_data(sdata, false);
cfg80211_assoc_timeout(sdata->dev, bss);
}
If there's no beacon, cfg80211_assoc_timeout() is not called.
I'm sure if you don't call ieee80211_rx_mgmt_beacon() at all you will
see the same behavior I see.
My bad, actually the code that is not being called is:
cfg80211_unlink_bss(local->hw.wiphy, assoc_data->bss);
In ieee80211_do_assoc().
--
Felipe Contreras
From: Johannes Berg <johannes@sipsolutions.net> Date: 2013-11-11 17:00:35
On Mon, 2013-11-11 at 10:53 -0600, Felipe Contreras wrote:
quoted
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
Not in my setup.
Well, dunno then. Different kernel versions? This clearly happens for
me.
quoted
quoted
quoted
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.
Yes, because your setup is receiving beacons.
No ... I tested on hwsim, making it ask for dtim-before-assoc, and
short-circuiting the beacon-TX routing. It can't have been seeing
beacons.
Check the code:
if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
ieee80211_do_assoc(sdata)) {
struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
ieee80211_destroy_assoc_data(sdata, false);
cfg80211_assoc_timeout(sdata->dev, bss);
}
If there's no beacon, cfg80211_assoc_timeout() is not called.
Yes it is.
"need_beacon && !have_beacon:
means - I wanted the beacon but didn't get it at the timeout.
I'm sure if you don't call ieee80211_rx_mgmt_beacon() at all you will
see the same behavior I see.
I'm sure I won't :)
quoted
Like I said before - trying to work with an AP without beacons at all is
really bad, we shouldn't be doing it.
Why not? For all intents and purposes my system is not receiving any
beacons, and I don't see any problems.
The not receiving part is a bug. I think you're probably receiving
beacons once associated though?
What would you prefer? That nothing works at all?
Yes, that'd be much safer.
quoted
We might not properly react to
radar events, and other things, for example.
So? I don't know what that means, but it can't be worst than not being
able to connect to the Internet whatsoever at all.
From: Johannes Berg <johannes@sipsolutions.net> Date: 2013-11-11 17:01:15
On Mon, 2013-11-11 at 10:56 -0600, Felipe Contreras wrote:
On Mon, Nov 11, 2013 at 10:53 AM, Felipe Contreras
[off-list ref] wrote:
quoted
On Mon, Nov 11, 2013 at 10:41 AM, Johannes Berg
[off-list ref] wrote:
quoted
On Mon, 2013-11-11 at 10:23 -0600, Felipe Contreras wrote:
quoted
quoted
quoted
quoted
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.
Yes, because your setup is receiving beacons.
Check the code:
if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
ieee80211_do_assoc(sdata)) {
struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
ieee80211_destroy_assoc_data(sdata, false);
cfg80211_assoc_timeout(sdata->dev, bss);
}
If there's no beacon, cfg80211_assoc_timeout() is not called.
I'm sure if you don't call ieee80211_rx_mgmt_beacon() at all you will
see the same behavior I see.
My bad, actually the code that is not being called is:
cfg80211_unlink_bss(local->hw.wiphy, assoc_data->bss);
In ieee80211_do_assoc().
That's not really interesting though, it just deletes the scan entry. If
it was deleted, then the supplicant would just scan again and probably
retry the connection.
johannes