From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Fietkau Date: Thu, 03 Feb 2011 03:13:00 +0100 Subject: [ath9k-devel] Weird error messages in logs In-Reply-To: References: <4D48FFF7.1050908@candelatech.com> <4D49692D.5090005@openwrt.org> <4D497C69.8070006@openwrt.org> <4D49F0A4.7080507@openwrt.org> Message-ID: <4D4A0F2C.8070605@openwrt.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Please copy the patch from http://nbd.name/560-ath9k_xmit_debug.patch into package/mac80211/patches/ in your OpenWrt build tree. Then recompile and update the ath9k package on your AP and see if it prints the "Aggregation session blocked..." messages when tx to the Intel client stops working. Thanks, - Felix On 2011-02-03 2:46 AM, Nikolay Martynov wrote: > Hi. > > I basically have three types of issues: > > 1) Almost no usable 'n' mode. It is somewhat usable if there is one > client on AP (and I guess relative silence in the air). If there are > two clients intel card becomes unusable - it seems to receive almost > no packets. Mac clients seems to work fine with same AP (didn't try > too long though). > > 2) I often get disconnected from AP with message like: wlan1: > deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3). > This happens for no apparent reason, in 'g' mode (and probably 'n' > too, I just do not run 'n' long enough). And this happens with macbook > too. I'm not sure that message is always the same - often there is no > disconnection message. When client tries to connect back there are > different types of timeouts: > a) on the client (intel): > [78513.691609] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 1/3) > [78513.888104] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 2/3) > [78514.088111] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 3/3) > [78514.288065] wlan1: direct probe to xx:xx:xx:xx:xx:xx timed out > b) on the client (intel): > [78471.324221] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1) > [78471.524074] wlan1: associate with xx:xx:xx:xx:xx:xx (try 2) > [78471.724064] wlan1: associate with xx:xx:xx:xx:xx:xx (try 3) > [78471.924055] wlan1: association with xx:xx:xx:xx:xx:xx timed out > a) and b) happen on intel. I often see 'timeout' in similar mac UI, > but I do not know how to get any diagnostics from mac. > At the same time on AP: > b) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: EAPOL-Key timeout > c) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not > acknowledge association response > b) and c) happen for both intel and mac clients. Moreover - one > client may keep trying to connect while other stays connected and > works fine. But if other disconnects it has problems connecting too. > Problem usually can be fixed by restarting 'wifi' on router. I do not > really know whether this is a ath9k problem, or some hostapd issue. > This may happen several times an hour, but sometimes doesn't happen > for hours. 'Disconnection' part happens more often on intel client. > > 3) Intel seems to loose heavy loaded tcp connection sometimes. I.e. > I upload something from laptop to machine connected by wire on the > same router and at some point upload stops and connection timeouts. > Or, if a type a lot of stuff in SSH session - ssh session locks. Looks > like bunch of packets get lost and tcp cannot recover. This happens in > 'g' mode. Often enough so I cannot upload 600Mb file without loosing > connection. Mac doesn't seem to have this problem. > > I have TEW-326BRP with trunk openwrt (kernel 2.6.37). > On the client - dell laptop with intel5300, to which I have only two > antennas connected - I replaced card from non-'n' and laptop has only > two antennas. OS - ubuntu, 2.6.38 kernel from it's repository + latest > compat wireless + exp ucode + patch from > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2214. > Another client - macbook pro. > I think I'm about 30 meters from AP - AP is no second floor and I'm > in the basement (basement has concrete walls - this might affect > signal quality I guess). > > It'd be really great to have reliable wifi, so I can devote time and > do whatever testing required. > Please let me know how I can help. > Thanks!