From owner-freebsd-wireless@FreeBSD.ORG Tue Jan 8 23:51:06 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A61AFACB for ; Tue, 8 Jan 2013 23:51:06 +0000 (UTC) (envelope-from andrew@ugh.net.au) Received: from starbug.ugh.net.au (starbug.ugh.net.au [202.3.36.37]) by mx1.freebsd.org (Postfix) with ESMTP id 61C783FB for ; Tue, 8 Jan 2013 23:51:06 +0000 (UTC) Received: from [10.0.0.11] (77-64-236-30.dynamic.primacom.net [77.64.236.30]) by starbug.ugh.net.au (Postfix) with ESMTPSA id 8E6A8386C57 for ; Wed, 9 Jan 2013 12:20:27 +1100 (EST) From: Andrew Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Debugging Stalls with ath(4) Date: Wed, 9 Jan 2013 00:50:57 +0100 Message-Id: To: freebsd-wireless@freebsd.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 23:51:06 -0000 Hi, I just installed a TP-Link TL-WN851ND PCI wireless card into my = 9.1-STABLE (r244942) box. It shows up in dmesg as Atheros 9287 mac 384.2 = RF5133. I am running it in hostap mode, 11g. Things seem to work OK but there = are occasionally stalls in traffic across the network. e.g. PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=3D0 ttl=3D64 time=3D13.134 ms 64 bytes from 10.0.0.1: icmp_seq=3D1 ttl=3D64 time=3D77.776 ms 64 bytes from 10.0.0.1: icmp_seq=3D2 ttl=3D64 time=3D246.675 ms Request timeout for icmp_seq 3 64 bytes from 10.0.0.1: icmp_seq=3D3 ttl=3D64 time=3D1037.327 ms 64 bytes from 10.0.0.1: icmp_seq=3D4 ttl=3D64 time=3D37.481 ms --- 10.0.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 13.134/282.479/1037.327/386.148 ms I was wondering how I would go about debugging the issue? I have been playing with wlandebug and I can see that the client I am = testing with (though it doesn't appear to be client specific) is listed = as going in and out of PS mode once or twice a second. Not sure that = that is a problem. Using "wlandebug rate" I see: Jan 9 00:45:25 sanna kernel: wlan0: [00:17:f2:e9:04:b0] = ath_rate_tx_complete: size 1600 (1167 bytes) OK rate/try 48 Mb /0/1 Jan 9 00:45:25 sanna kernel: wlan0: [00:17:f2:e9:04:b0] = ath_rate_tx_complete: size 1600 (1554 bytes) OK rate/try 48 Mb /0/1 Jan 9 00:45:25 sanna kernel: wlan0: [00:17:f2:e9:04:b0] = ath_rate_tx_complete: size 1600 (1554 bytes) OK rate/try 48 Mb /0/1 Jan 9 00:45:25 sanna kernel: wlan0: [7c:c5:37:6d:4c:7e] = ath_rate_tx_complete: size 250 (30 bytes) FAIL rate/try 1 Mb /0/7 Jan 9 00:45:25 sanna kernel: wlan0: [00:17:f2:e9:04:b0] = ath_rate_tx_complete: size 250 (106 bytes) OK rate/try 11 Mb /0/1 Jan 9 00:45:25 sanna kernel: wlan0: [00:17:f2:e9:04:b0] = ath_rate_tx_complete: size 250 (122 bytes) OK rate/try 11 Mb /0/1 Jan 9 00:45:26 sanna kernel: wlan0: [00:17:f2:e9:04:b0] = ath_rate_tx_complete: size 250 (138 bytes) OK rate/try 11 Mb /0/1 Jan 9 00:45:26 sanna kernel: wlan0: [00:23:14:98:15:b4] = ath_rate_findrate: size 250 switch rate 48 (1129/690) -> 54 (736/682) = after 2 packets mrr 0 Jan 9 00:45:26 sanna kernel: wlan0: [64:70:02:f0:c8:03] = ath_rate_tx_complete: size 250 FAIL rate/try 0/5 no rates yet Jan 9 00:45:26 sanna kernel: wlan0: [00:17:f2:e9:04:b0] = ath_rate_tx_complete: size 250 (94 bytes) OK rate/try 11 Mb /0/1 Jan 9 00:45:26 sanna last message repeated 2 times Jan 9 00:45:26 sanna kernel: wlan0: [00:23:14:98:15:b4] = ath_rate_tx_complete: size 250 (163 bytes) OK rate/try 54 Mb /0/2 Jan 9 00:45:26 sanna kernel: wlan0: [00:17:f2:e9:04:b0] = ath_rate_tx_complete: size 250 (137 bytes) OK rate/try 11 Mb /0/1 Given the proximity of the clients and the FreeBSD box I would have = expected it to not have had any trouble maintaing a high connection rate = - but perhaps this is a symptom of the stalls. Can anyone suggest where to go from here? Thanks, Andrew=