Bug 33572 - ath9k: numerous transmits of single packet when using block acks
Summary: ath9k: numerous transmits of single packet when using block acks
Status: RESOLVED OBSOLETE
Alias: None
Product: Networking
Classification: Unclassified
Component: Wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: networking_wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-18 14:12 UTC by jeroen
Modified: 2012-08-20 15:50 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.32.27 (openwrt backfire svn)
Subsystem:
Regression: No
Bisected commit-id:

Attachments
Removes tidno validation in ath_tx_complete_aggr. (223 bytes, patch)
2011-05-05 08:17 UTC, jeroen 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Description jeroen 2011-04-18 14:12:27 UTC 
Hey,

I'm testing the following setup with the svn backfire (18/04/2011 rev 26713).  I have an access point (192.168.1.253) configured with hostapd using the following configuration:

interface=wlan0
bridge=br0
driver=nl80211
auth_algs=3
debug=0
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
dump_file=/tmp/hostapd.dump
beacon_int=100
max_num_sta=255
hw_mode=a
ieee80211n=1
wmm_enabled=1
ieee80211n=1
wmm_enabled=1
ht_capab=[TX-STBC][RX-STBC12][DELAYED-BA][MAX-AMSDU-7935]
channel=48
rts_threshold=2347
fragm_threshold=2346
ssid=ntest
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ignore_broadcast_ssid=0

With another device (192.168.1.100) I connect to this access point.  Both devices are ubiquitity routerstation pros with a R52n-M wireless card (AR9220).  Once connected it will negotiate over the block acks which ends successfully.  Yet when I preform a ping from the client to the access point, the request is sent only once but the reply is sent multiple times.  All of the replies are acked with normal acks yet the access point appears to ignore the normal acks and sends out a block ack request.  The full trace can be found at https://euterpe.cmi.ua.ac.be/~javonts/tmp/duplicateDump.pcap .  Note that a bridge is used with the mac address 00:00:00:00:00:01, yet this doesn't influence the results. 

Regards
Jeroen
Comment 1 jeroen 2011-04-21 13:24:47 UTC 
The pervious test was with custom modifications to the driver:  The following test is without any extra modifications yet with the same problem:

AP execute script:
---begin
#!/bin/bash

cat >> /etc/hostapd/hostapd.conf << EOF
interface=wlan0
driver=nl80211
auth_algs=3
debug=0
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
dump_file=/tmp/hostapd.dump
beacon_int=100
max_num_sta=255
hw_mode=a
ieee80211n=1
wmm_enabled=1
ht_capab=
channel=48
rts_threshold=2347
fragm_threshold=2346
ssid=ntest
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ignore_broadcast_ssid=0
EOF

iw phy phy0 interface add wlan0 type managed
ifconfig wlan0 192.168.1.253
hostapd /etc/hostapd/hostapd.conf
---end

sta setup script:

--begin
#!/bin/bash

iw phy phy0 interface add wlan0 type managed
ifconfig wlan0 192.168.1.100
iw wlan0 connect ntest
sleep 5
ping -c 10 192.168.1.253
--end

Trace file can be found at https://euterpe.cmi.ua.ac.be/~javonts/tmp/duplicateDump3.pcap
Comment 2 jeroen 2011-04-27 09:29:55 UTC 
The bug is not always reproducible when using the setup above with the compat-wireless driver of 19-04-2011.  Sometimes I get all pings transmitted correctly, sometimes only one is being transmitted multiple times (https://euterpe.cmi.ua.ac.be/~javonts/tmp/110419_duplicate.pcap).  Could this be some kind of internal race condition?
Comment 3 jeroen 2011-04-27 10:00:57 UTC 
Posting just the important trace lines:


267 6.0   15.155253   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=985, FN=0, Flags=........C, BI=100, SSID="ntest"
    268 6.0   15.257721   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=986, FN=0, Flags=........C, BI=100, SSID="ntest"
    269 6.0   15.360182   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=987, FN=0, Flags=........C, BI=100, SSID="ntest"
    270 6.0   15.462545   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=988, FN=0, Flags=........C, BI=100, SSID="ntest"
    271 52.0  15.534799   192.168.1.100         192.168.1.253         ICMP     Echo (ping) request  (id=0x0480, seq(be/le)=8/2048, ttl=64)
    272 24.0  15.534816                         Routerbo_67:85:c0 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    273 130.0 15.535008   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    274 24.0  15.535021                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    275 130.0 15.535170   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    276 24.0  15.535179                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    277 130.0 15.535419   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    278 24.0  15.535426                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    279 130.0 15.535517   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    280 24.0  15.535524                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    281 130.0 15.535704   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    282 24.0  15.535711                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    283 130.0 15.535903   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    284 24.0  15.535910                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    285 130.0 15.536235   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    286 130.0 15.536240   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    287 24.0  15.536329                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    288 130.0 15.536425   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    289 24.0  15.536431                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    290 130.0 15.536741   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    291 24.0  15.536747                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    292 130.0 15.536838   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    293 24.0  15.536845                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    294 130.0 15.536979   192.168.1.253         192.168.1.100         ICMP     Echo (ping) reply    (id=0x0480, seq(be/le)=8/2048, ttl=64)
    295 24.0  15.536985                         Routerbo_67:86:13 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    296 6.0   15.537131   Routerbo_67:86:13 (TA) Routerbo_67:85:c0 (RA) IEEE 802.11 802.11 Block Ack Req, Flags=........C
    297 6.0   15.537221   Routerbo_67:85:c0 (TA) Routerbo_67:86:13 (RA) IEEE 802.11 802.11 Block Ack, Flags=........C
    298 6.0   15.564965   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=989, FN=0, Flags=........C, BI=100, SSID="ntest"
    299 52.0  15.628793   Routerbo_67:85:c0     Routerbo_67:86:13     IEEE 802.11 Null function (No data), SN=126, FN=0, Flags=...P...TC
    300 24.0  15.628809                         Routerbo_67:85:c0 (RA) IEEE 802.11 Acknowledgement, Flags=........C
    301 6.0   15.667330   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=990, FN=0, Flags=........C, BI=100, SSID="ntest"
    302 6.0   15.769728   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=991, FN=0, Flags=........C, BI=100, SSID="ntest"
    303 6.0   15.871984   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=992, FN=0, Flags=........C, BI=100, SSID="ntest"
    304 6.0   15.974482   Routerbo_67:86:13     Broadcast             IEEE 802.11 Beacon frame, SN=993, FN=0, Flags=........C, BI=100, SSID="ntest"
Comment 4 jeroen 2011-05-05 08:17:03 UTC 
Created attachment 56702 [details]
Removes tidno validation in ath_tx_complete_aggr.

Packtes are transmitted correctly when the tidno validation in ath_tx_complete_aggr is removed.
Comment 5 jeroen 2011-05-05 08:20:23 UTC 
The tid number returned by the driver does not correspond with the tid set in the packet.  Due to lack of documentation of the atheros status registers I'm unable to trace the actual problem, hence the removal of the tid validation lines.
Comment 6 John W. Linville 2011-05-11 16:22:51 UTC 
Great work, Jeroen!

Felix and the Atheros folks, any comments here?
Comment 7 John W. Linville 2011-06-28 18:17:12 UTC 
ath9k folks, ping?
Note You need to log in before you can comment on or make changes to this bug.