| Message ID | 1249056817.20593.1.camel@maxim-laptop (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Fri, 2009-07-31 at 09:13 -0700, Maxim Levitsky wrote: > Hi, here is the updated version of these two patches that fix the > $SUBJECT issue. > > I attach these (in case mailer mangles them), and reply with patches. > > Tested both with low quality signal, and beacon loss. > Lack of TX is found, every 30 seconds now, and quite reliable. > Lack of beacons, triggers probe like it did every 2 seconds. Thanks! I've been running with this for two hours now with no disconnects. This is where before the patches I would get disconnected after a few minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx after 500ms, try 1" messages in my log. Reinette -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2009-07-31 at 11:52 -0700, reinette chatre wrote: > On Fri, 2009-07-31 at 09:13 -0700, Maxim Levitsky wrote: > > Hi, here is the updated version of these two patches that fix the > > $SUBJECT issue. > > > > I attach these (in case mailer mangles them), and reply with patches. > > > > Tested both with low quality signal, and beacon loss. > > Lack of TX is found, every 30 seconds now, and quite reliable. > > Lack of beacons, triggers probe like it did every 2 seconds. > > Thanks! > > I've been running with this for two hours now with no disconnects. This > is where before the patches I would get disconnected after a few > minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx > after 500ms, try 1" messages in my log. This is normal, or at least can be normal, I patched the driver to display this message, when there is a probe timeout, but instead of disconnect, it retries, currently 5 times, but this can be even further increased is necessarily. (these messages are only in logs when verbose mac debugging is enabled) I don't know exactly why probes aren't answered, but I strongly suspect that my AP sometimes 'goes out to lunch' and then answers, since typically after a failed probe it sends many replies. (Or it could be some buffering done by iwl3945 microcode). I currently can't monitor the connection from outside, but as soon as I can I see whether the above is true. Nevertheless if signal quality isn't great, there are valid reasons for probe loss, and it shouldn't cause all the fuzz (and since I use WPA2, every reconnection causes whole WPA handshake to be preformed, and this takes at least 2 seconds, and if a reconnection happens each 5 seconds, it gets very very annoying, and almost unusable. And polling every 2 seconds, this way or another, I think is too much anyway. Best regards, Maxim Levitsky > > Reinette > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Maxim, > > > Hi, here is the updated version of these two patches that fix the > > > $SUBJECT issue. > > > > > > I attach these (in case mailer mangles them), and reply with patches. > > > > > > Tested both with low quality signal, and beacon loss. > > > Lack of TX is found, every 30 seconds now, and quite reliable. > > > Lack of beacons, triggers probe like it did every 2 seconds. > > > > Thanks! > > > > I've been running with this for two hours now with no disconnects. This > > is where before the patches I would get disconnected after a few > > minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx > > after 500ms, try 1" messages in my log. > This is normal, or at least can be normal, I patched the driver to > display this message, when there is a probe timeout, but instead of > disconnect, it retries, currently 5 times, but this can be even further > increased is necessarily. > (these messages are only in logs when verbose mac debugging is enabled) > > I don't know exactly why probes aren't answered, but I strongly suspect > that my AP sometimes 'goes out to lunch' and then answers, since > typically after a failed probe it sends many replies. > (Or it could be some buffering done by iwl3945 microcode). I currently > can't monitor the connection from outside, but as soon as I can I see > whether the above is true. Nevertheless if signal quality isn't great, > there are valid reasons for probe loss, and it shouldn't cause all the > fuzz (and since I use WPA2, every reconnection causes whole WPA > handshake to be preformed, and this takes at least 2 seconds, and if a > reconnection happens each 5 seconds, it gets very very annoying, and > almost unusable. I am testing your patches and so far so good. Seems to be working perfectly fine. I see this in the logs: [41027.333419] wlan0: detected beacon loss from AP - sending probe request [41027.389260] wlan0: cancelling probereq poll due to a received beacon [41027.793518] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 1 [41028.292731] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 2 Need to watch out if this pattern emerges and if the beacon loss trigger might give us an indication. Maybe the ucode is just not ready then. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2009-07-31 at 12:27 -0700, Marcel Holtmann wrote: > Hi Maxim, > > > > > Hi, here is the updated version of these two patches that fix the > > > > $SUBJECT issue. > > > > > > > > I attach these (in case mailer mangles them), and reply with patches. > > > > > > > > Tested both with low quality signal, and beacon loss. > > > > Lack of TX is found, every 30 seconds now, and quite reliable. > > > > Lack of beacons, triggers probe like it did every 2 seconds. > > > > > > Thanks! > > > > > > I've been running with this for two hours now with no disconnects. This > > > is where before the patches I would get disconnected after a few > > > minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx > > > after 500ms, try 1" messages in my log. > > This is normal, or at least can be normal, I patched the driver to > > display this message, when there is a probe timeout, but instead of > > disconnect, it retries, currently 5 times, but this can be even further > > increased is necessarily. > > (these messages are only in logs when verbose mac debugging is enabled) > > > > I don't know exactly why probes aren't answered, but I strongly suspect > > that my AP sometimes 'goes out to lunch' and then answers, since > > typically after a failed probe it sends many replies. > > (Or it could be some buffering done by iwl3945 microcode). I currently > > can't monitor the connection from outside, but as soon as I can I see > > whether the above is true. Nevertheless if signal quality isn't great, > > there are valid reasons for probe loss, and it shouldn't cause all the > > fuzz (and since I use WPA2, every reconnection causes whole WPA > > handshake to be preformed, and this takes at least 2 seconds, and if a > > reconnection happens each 5 seconds, it gets very very annoying, and > > almost unusable. > > I am testing your patches and so far so good. Seems to be working > perfectly fine. I see this in the logs: > > [41027.333419] wlan0: detected beacon loss from AP - sending probe request > [41027.389260] wlan0: cancelling probereq poll due to a received beacon > [41027.793518] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 1 > [41028.292731] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 2 > > Need to watch out if this pattern emerges and if the beacon loss trigger > might give us an indication. Maybe the ucode is just not ready then. Here (on my system) I see no beacon losses at all, like I said there could be many reasons behind packet losses, and best way to mitigate them is to retry. Your logs indicate that beacons weren't recieved for 2 seconds, then mac80211 tried to send a probe, but a beacon is recieved before the probe answer, this probe is canceled (at least should be) then after a while, a probe request (same one?) is time outed, and retried twice, then finally answered. Best regards, Maxim Levitsky > > Regards > > Marcel > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Maxim, > > > > > Hi, here is the updated version of these two patches that fix the > > > > > $SUBJECT issue. > > > > > > > > > > I attach these (in case mailer mangles them), and reply with patches. > > > > > > > > > > Tested both with low quality signal, and beacon loss. > > > > > Lack of TX is found, every 30 seconds now, and quite reliable. > > > > > Lack of beacons, triggers probe like it did every 2 seconds. > > > > > > > > Thanks! > > > > > > > > I've been running with this for two hours now with no disconnects. This > > > > is where before the patches I would get disconnected after a few > > > > minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx > > > > after 500ms, try 1" messages in my log. > > > This is normal, or at least can be normal, I patched the driver to > > > display this message, when there is a probe timeout, but instead of > > > disconnect, it retries, currently 5 times, but this can be even further > > > increased is necessarily. > > > (these messages are only in logs when verbose mac debugging is enabled) > > > > > > I don't know exactly why probes aren't answered, but I strongly suspect > > > that my AP sometimes 'goes out to lunch' and then answers, since > > > typically after a failed probe it sends many replies. > > > (Or it could be some buffering done by iwl3945 microcode). I currently > > > can't monitor the connection from outside, but as soon as I can I see > > > whether the above is true. Nevertheless if signal quality isn't great, > > > there are valid reasons for probe loss, and it shouldn't cause all the > > > fuzz (and since I use WPA2, every reconnection causes whole WPA > > > handshake to be preformed, and this takes at least 2 seconds, and if a > > > reconnection happens each 5 seconds, it gets very very annoying, and > > > almost unusable. > > > > I am testing your patches and so far so good. Seems to be working > > perfectly fine. I see this in the logs: > > > > [41027.333419] wlan0: detected beacon loss from AP - sending probe request > > [41027.389260] wlan0: cancelling probereq poll due to a received beacon > > [41027.793518] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 1 > > [41028.292731] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 2 > > > > Need to watch out if this pattern emerges and if the beacon loss trigger > > might give us an indication. Maybe the ucode is just not ready then. > Here (on my system) I see no beacon losses at all, like I said there > could be many reasons behind packet losses, and best way to mitigate > them is to retry. > > Your logs indicate that beacons weren't recieved for 2 seconds, then > mac80211 tried to send a probe, but a beacon is recieved before the > probe answer, this probe is canceled (at least should be) then after a > while, a probe request (same one?) is time outed, and retried twice, > then finally answered. it looked related, but it wasn't at all. I have this running for over 24 hours by now and the patches work perfectly fine. Today it saw for the first time a try 4 message. Otherwise it only had to try up to three times before it succeeded. Tested-by: Marcel Holtmann <marcel@holtmann.org> Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2009-07-31 at 19:13 +0300, Maxim Levitsky wrote: > Hi, here is the updated version of these two patches that fix the > $SUBJECT issue. > > I attach these (in case mailer mangles them), and reply with patches. > > Tested both with low quality signal, and beacon loss. > Lack of TX is found, every 30 seconds now, and quite reliable. > Lack of beacons, triggers probe like it did every 2 seconds. > > > > Best regards, > Maxim Levitsky Just a question, when to see these in wireless-testing? Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi John, > > Hi, here is the updated version of these two patches that fix the > > $SUBJECT issue. > > > > I attach these (in case mailer mangles them), and reply with patches. > > > > Tested both with low quality signal, and beacon loss. > > Lack of TX is found, every 30 seconds now, and quite reliable. > > Lack of beacons, triggers probe like it did every 2 seconds. > > > > > > > > Best regards, > > Maxim Levitsky > > Just a question, when to see these in wireless-testing? patches have been acked and tested by various people. Should be pretty much safe to apply and they are helping many of us to get back a stable WiFi connection. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From 04976d22d45f26aa4b4dece5dd520e3347ac32d7 Mon Sep 17 00:00:00 2001 From: Maxim Levitsky <maximlevitsky@gmail.com> Date: Fri, 31 Jul 2009 18:54:23 +0300 Subject: [PATCH] [MAC80211] Increase timeouts for station polling Do a probe request every 30 seconds, and wait for probe response, half a second This should lower the traffic that card sends, thus save power Wainting longer for response makes probe more robust against 'slow' access points Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> --- net/mac80211/mlme.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 1d8640a..e4bb590 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -42,13 +42,13 @@ * Time the connection can be idle before we probe * it to see if we can still talk to the AP. */ -#define IEEE80211_CONNECTION_IDLE_TIME (2 * HZ) +#define IEEE80211_CONNECTION_IDLE_TIME (30 * HZ) /* * Time we wait for a probe response after sending * a probe request because of beacon loss or for * checking the connection still works. */ -#define IEEE80211_PROBE_WAIT (HZ / 5) +#define IEEE80211_PROBE_WAIT (HZ / 2) #define TMR_RUNNING_TIMER 0 #define TMR_RUNNING_CHANSW 1 -- 1.6.0.4