From: Marcel Holtmann <marcel@holtmann.org>
To: Jouni Malinen <j@w1.fi>
Cc: Jouni Malinen <jouni.malinen@atheros.com>,
"John W. Linville" <linville@tuxdriver.com>,
Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/3] mac80211: Add a timeout for frames in the RX reorder buffer
Date: Sat, 09 May 2009 10:05:53 -0700 [thread overview]
Message-ID: <1241888753.4903.97.camel@localhost.localdomain> (raw)
In-Reply-To: <20090509080838.GA1206@jm.kir.nu>
Hi Jouni,
> > > I can confirm that this used to be a regular situation between my X200
> > > and a D-Link access point.
>
> Which D-Link model is that AP? I think I should try to get one of those
> added to me test bed.. ;-)
from the WPS information element:
* Version: 1.0
* Manufacturer: D-Link Systems
* Model: DIR-615
* Device name: Wireless N Router
* Config methods: Label
I bought it over a year ago in Canada. It is actually my second of these
since I fried the first one :)
> > so I finally got the debug output for you. Took only over a day :)
>
> Thanks! Would you happen to have timing information available for these
> (e.g., from klogd)? It looks like the AP is sending out an ADDBA Request
> to update some parameters, but we currently ignore that request.
> However, at least in this particular case, our RX reorder bug head_seq
> matches with the ssn from the ADDBA Request, so I'm not sure whether
> ignoring the ADDBA contents is really causing harm here (anyway, we
> should really process these updates, too).
>
> The timeouts on RX reorder frames look similar to what I have seen in my
> tests and the workaround was indeed trying to address that type of
> issue, so it is nice to hear that it helped in this case, too.
I don't have the timing details since my Fedora for some reason doesn't
log them to the filesystem. I have to fix that.
Also re-producing this is not as simple as you think. I have no idea
when this happens. There is no way to actually trigger it from my side.
Regards
Marcel
next prev parent reply other threads:[~2009-05-09 17:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-05 17:35 [PATCH 0/3] mac80211: HT RX reorder buffer cleanup and timeout workaround Jouni Malinen
2009-05-05 17:35 ` [PATCH 1/3] mac80211: Use a shared function to release frames from RX reorder buf Jouni Malinen
2009-05-05 17:35 ` [PATCH 2/3] mac80211: Add a timeout for frames in the RX reorder buffer Jouni Malinen
2009-05-07 15:15 ` Marcel Holtmann
2009-05-09 1:48 ` Marcel Holtmann
2009-05-09 8:08 ` Jouni Malinen
2009-05-09 17:05 ` Marcel Holtmann [this message]
2009-05-10 20:29 ` Jouni Malinen
2009-05-10 21:07 ` Marcel Holtmann
2009-05-11 13:55 ` Dan Williams
2009-05-10 0:08 ` Marcel Holtmann
2009-05-11 4:45 ` Marcel Holtmann
2009-05-05 17:35 ` [PATCH 3/3] mac80211: Comment the order of HT RX reorder handler vs. RX handlers Jouni Malinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1241888753.4903.97.camel@localhost.localdomain \
--to=marcel@holtmann.org \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=jouni.malinen@atheros.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.