From: Mohammed Shafi <shafi.wireless@gmail.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss
Date: Mon, 22 Nov 2010 20:39:15 +0530 [thread overview]
Message-ID: <AANLkTim0nV6f_C5mYDH3geho6G7soJX5=OeL_-8a=4PY@mail.gmail.com> (raw)
In-Reply-To: <AANLkTiktvydY2NQhMq8kQ39FQWpy0tnjC7yCgfPRkCoD@mail.gmail.com>
On Mon, Nov 22, 2010 at 8:38 PM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Mon, Nov 22, 2010 at 8:11 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-11-22 7:49 AM, Mohammed Shafi wrote:
>>> On Sat, Nov 20, 2010 at 8:09 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>> On 2010-11-19 10:55 PM, Felix Fietkau wrote:
>>>>> Waiting for 500 ms after sending a probe request seems a bit excessive,
>>>>> especially when doing 5 attempts. If the connection is bad enough to make
>>>>> multiple requests time out, then user space should try to quickly find a
>>>>> new AP.
>>> This might improve fail over roaming to a small extent but ?as per the
>>> commit id d1c5091f23fed5195271e2849f89017d3a126521 it was mentioned
>>> this might affect robustness against 'slow AP's'
>>>
>>>> Hmm, don't merge this patch yet, it can cause background scans to
>>>> trigger reconnects.
>>>>
>>> I am not sure ?how this affects background scan.bgscan will be enabled
>>> even before the beacon loss and it is based on RSSI(please correct me
>>> if I am wrong).
>> I'm not sure either, this showed up in my tests. I'm pretty sure that
>> this change is not the root cause, but I don't want to see it merged
>> until the cause is figured out. My guess is that it's related to the
>> issues with the nullfunc probe request patch that Paul pointed out.
>> I'll do some more testing after I've fixed that one.
>>
>
> Ok.
>> - Felix
>>
>
next prev parent reply other threads:[~2010-11-22 15:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-19 21:55 [PATCH 1/4] mac80211: restart beacon miss timer on system resume from suspend Felix Fietkau
2010-11-19 21:55 ` [PATCH 2/4] mac80211: calculate beacon loss time accurately Felix Fietkau
2010-11-19 21:55 ` [PATCH 3/4] mac80211: probe the AP when resuming Felix Fietkau
2010-11-19 21:55 ` [PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss Felix Fietkau
2010-11-19 22:04 ` Ben Greear
2010-11-20 2:39 ` Felix Fietkau
2010-11-22 6:49 ` Mohammed Shafi
2010-11-22 14:41 ` Felix Fietkau
[not found] ` <AANLkTiktvydY2NQhMq8kQ39FQWpy0tnjC7yCgfPRkCoD@mail.gmail.com>
2010-11-22 15:09 ` Mohammed Shafi [this message]
2010-12-08 20:27 ` John W. Linville
2010-11-23 19:28 ` [PATCH v2 3/4] mac80211: probe the AP when resuming Felix Fietkau
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='AANLkTim0nV6f_C5mYDH3geho6G7soJX5=OeL_-8a=4PY@mail.gmail.com' \
--to=shafi.wireless@gmail.com \
--cc=ath9k-devel@lists.ath9k.org \
/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.