On Mon, Nov 22, 2010 at 03:41:23PM +0100, Felix Fietkau wrote: > On 2010-11-22 7:49 AM, Mohammed Shafi wrote: > > On Sat, Nov 20, 2010 at 8:09 AM, Felix Fietkau <nbd@xxxxxxxxxxx> 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. I'm dropping this from my queue -- please repost if you decide it is warranted. John -- John W. Linville Someday the world will need a hero, and you linville@xxxxxxxxxxxxx might be all we have. Be ready. -- 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