From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis R. Rodriguez Date: Wed, 5 Aug 2009 13:53:12 -0700 Subject: [ath9k-devel] N mode In-Reply-To: <4A79E72B.7030207@gmail.com> References: <20090616003715.GA5492@tesla> <4A6A56AD.2090104@gmail.com> <4A78FFE6.4030701@gmail.com> <20090805153427.GA4727@mosca> <4A79AB23.7020007@gmail.com> <4A79B49A.2060902@gmail.com> <20090805171151.GD4727@mosca> <4A79E2CB.5020508@gmail.com> <4A79E72B.7030207@gmail.com> Message-ID: <20090805205312.GG4727@mosca> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Wed, Aug 05, 2009 at 01:10:19PM -0700, Dmitri Seletski wrote: > Sorry, please cut out the emotional part. > script seemed to help me a bit... Dmitry, I don't have time to look at your logs right now, but am hoping someone in our team will be soon. But as far as your disconnects are concerned I'll note that some others users were experiencing similar issues when using wireless-testing, a few patches were added recently to address some of these issues, namely: commit 3810f40f71ccf690bc10152fb0706f7a4e9b8e87 Author: Maxim Levitsky Date: Fri Jul 31 18:54:23 2009 +0300 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 Acked-by: Johannes Berg Tested-by: Marcel Holtmann Signed-off-by: John W. Linville commit 9004c35534fbdb452d2f544c8ae59dcadc486465 Author: Maxim Levitsky Date: Fri Jul 31 18:54:12 2009 +0300 mac80211: Retry probe request few times Retry 5 times (chosen arbitary ), before assuming that station is out of range. Fixes frequent disassociations while connected to weak, and sometimes even strong access points. Signed-off-by: Maxim Levitky Acked-by: Johannes Berg Signed-off-by: John W. Linville Check git log net/mac80211/ and see if you see these there. Also, there does seem to be a regression on wireless-testing right now regarding re-association, I'll let you know more about it the more I find but I believe Johannes is already working on it, I am not really sure of the details or if this can be affecting you right now. Also, 'iw dev wlan0 connect foo' will work but expect to be disconnected eventually due to noise or in your case due to inactivity. Instead of scripting out a way to always connect you can just use wpa_supplicant to help 'roam' so that it keeps re-associating for you if disconnected. I tend to use 'iw dev wlan0 connect foo' only to test things, if I want to ensure I always remain connected I use wpa_supplicant with roaming enabled, I do this even with no encryption enabled. mcgrof at tux ~ $ cat mosca.conf ctrl_interface=/var/run/wpa_supplicant ap_scan=1 network={ ssid="mosca" scan_ssid=1 key_mgmt=NONE } sudo wpa_supplicant -D nl80211 -c mosca.conf -i wlan0 While at it you might as well get the latest supplicant from git: git clone git://w1.fi/srv/git/hostap.git cd hostap/wpa_supplicant cp defconfig .config Then edit .config and ensure you have these enabled: # Driver interface for generic Linux wireless extensions CONFIG_DRIVER_WEXT=y # Driver interface for Linux drivers using the nl80211 kernel interface CONFIG_DRIVER_NL80211=y Build it and install it. Keep in mind we need to address two issues here: 1) Your current disconnect issues 2) Your card not being able to complete association (was this the issue?) to your AP when 802.11n is enabled. We should focus on both for sure but be sure to help try to isolate the issues so we don't get them mixed up. To help more with this it may help for you to put logs for both separetely, from the kernel, 'iw event -t', and the wpa_supplicant logs with "-d" added to increase verbosity. Can you please create two directories and put logs into them for both of these issues? The easier it is to separate the issues and review the logs the easier it will be review your issues and help you resolve them. Don't bother with tcpdump/wireshark dumps for now. Only provide them if you are asked. Luis