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. - Felix -- 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
