Hi Maxim, > > > Fix it then. Offer an implementation of your superior solution. > > > > I just don't think that this patch is a solution because it means that > > we'll be connected to the AP forever, without knowing anything is wrong, > > if the AP can reach us but we can't reach the AP (maybe because we have > > a good Intel card with great sensitivity). > > > > Sure -- it's possible to factor in transmit status reports (but remember > > that not all hardware gives those reliably) or do things on a different > > schedule etc. But as long as nobody wants to really improve things I > > don't see why we should take the regression and _remove_ the current > > behaviour. > > It is ok to send probes every minute or so, but not each second, and > probes must be retried. > > Because of these probes, wireless literally reconnects every 5 seconds, > here, and I am 10 meters from the AP. even with Reinette's patch, I am seeing this: [18594.423855] wlan0: cancelling probereq poll due to a received beacon [18629.544841] No probe response from AP 00:1c:f0:xx:xx:xx after 200ms, disconnecting. So that is with the patch, being 1m away from the AP, in the 18th floor of a building and with only another 10 APs around me. The Bluetooth world calls this link supervision timeout and the default value for that timeout is 30 seconds. I think it is the best to make this value configurable and increase it to at least 30 seconds by default. Within Bluetooth you can change it and runtime. Johannes, I don't care how good or bad some hardware is. How sensitive or not. This is a clear regression and you are overdoing it here with only waiting for 200ms. Regards Marcel -- 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
