[ath9k-devel] Stable Version for ath9k_htc in AP Mode?

[Oleksij Rempel <linux@rempel-privat.de>]

Am 12.05.2014 03:46, schrieb Aaron Hamilton:
> No, they're connected directly to the device's 5V rail, which was also
> contributing to the "Target is Unresponsive" errors until the more
> recent drivers.
> 
> The specific chip we're using is a ZCN-722m. Datasheet here:
> http://www.zcomax.com/embedded/ZCN-722M/ZX-ZCN-722M-DS.pdf. Hi-res
> image here: http://www.zcomax.com/embedded/ZCN-722M/ZCN-722M.jpg

I can see on this image two test points. It is actual UART, find RX pin
and use it to grub firmware log.

> The following is the dmesg output on the device that's currently not
> allowing connections:

From dmesg i see that, to one USB 1.1 root-hub attached two device,
ath9k_htc and GobiNet. GobiNet was recognised as eth1 + 3 x ttyUSB.
IMO, it is a lot for one USB 1.1.

> Linux version 2.6.39.4-ts-armv4l (root at hans) (gcc version 4.4.4 (GCC)
> ) #1 Sun Apr 27 21:45:33 PDT 2014
> CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Atmel AT91RM9200-EK
> Memory policy: ECC disabled, Data cache writeback
> Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz
> On node 0 totalpages: 8192
> free_area_init_node: node 0, pgdat c0308580, node_mem_map c031c000
>   Normal zone: 64 pages used for memmap
>   Normal zone: 0 pages reserved
>   Normal zone: 8128 pages, LIFO batch:0
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
> Kernel command line: root=/dev/mtdblock2 rootfstype=jffs2
> console=ttyS0,115200,mem=32M
> PID hash table entries: 128 (order: -3, 512 bytes)
> Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> Memory: 32MB = 32MB total
> Memory: 29260k/29260k available, 3508k reserved, 0K highmem
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
>     vmalloc : 0xc2800000 - 0xfee00000   ( 966 MB)
>     lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)
>     modules : 0xbf000000 - 0xc0000000   (  16 MB)
>       .init : 0xc0008000 - 0xc0027000   ( 124 kB)
>       .text : 0xc0027000 - 0xc02e9000   (2824 kB)
>       .data : 0xc02ea000 - 0xc0308c20   ( 124 kB)
> SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> NR_IRQS:192
> AT91: 128 gpio irqs in 4 banks
> Console: colour dummy device 80x30
> console [ttyS0] enabled
> Calibrating delay loop... 89.49 BogoMIPS (lpj=447488)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> devtmpfs: initialized
> NET: Registered protocol family 16
> bio: create slab <bio-0> at 0
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Switching to clocksource 32k_counter
> Switched to NOHz mode on CPU #0
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 1024 (order: 1, 8192 bytes)
> TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> TCP: Hash tables configured (established 1024 bind 1024)
> TCP reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> NetWinder Floating Point Emulator V0.97 (double precision)
> JFFS2 version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
> msgmni has been set to 57
> NET: Registered protocol family 38
> io scheduler noop registered (default)
> atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
> atmel_usart.1: ttyS1 at MMIO 0xfffc4000 (irq = 7) is a ATMEL_SERIAL
> atmel_usart.2: ttyS2 at MMIO 0xfffc8000 (irq = 8) is a ATMEL_SERIAL
> atmel_usart.3: ttyS3 at MMIO 0xfffcc000 (irq = 9) is a ATMEL_SERIAL
> atmel_usart.4: ttyS4 at MMIO 0xfffc0000 (irq = 6) is a ATMEL_SERIAL
> brd: module loaded
> physmap platform flash device: 00800000 at 10000000
> physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank.
> Manufacturer ID 0x000001 Chip ID 0x001000
> Amd/Fujitsu Extended Query Table at 0x0040
>   Amd/Fujitsu Extended Query version 1.3.
> number of CFI chips: 1
> physmap platform flash device: 00800000 at 30000000
> physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank.
> Manufacturer ID 0x000001 Chip ID 0x001000
> Amd/Fujitsu Extended Query Table at 0x0040
>   Amd/Fujitsu Extended Query version 1.3.
> number of CFI chips: 1
> physmap platform flash device: 00800000 at 40000000
> physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank.
> Manufacturer ID 0x000001 Chip ID 0x001000
> Amd/Fujitsu Extended Query Table at 0x0040
>   Amd/Fujitsu Extended Query version 1.3.
> number of CFI chips: 1
> Concatenating MTD devices:
> (0): "physmap-flash.0"
> (1): "physmap-flash.0"
> (2): "physmap-flash.0"
> into device "physmap-flash.0"
> RedBoot partition parsing not available
> Using physmap partition information
> Creating 4 MTD partitions on "physmap-flash.0":
> 0x000000000000-0x000000030000 : "boot"
> 0x000000030000-0x000000230000 : "kernel"
> 0x000000230000-0x000001400000 : "jffs2"
> 0x000001400000-0x000001800000 : "odp"
> PPP generic driver version 2.4.2
> PPP Deflate Compression module registered
> PPP BSD Compression module registered
> NET: Registered protocol family 24
> eth0: Link now 100-FullDuplex
> eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:11:db:06:a4:26)
> eth0: Micrel KSZ8873 Switch
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> at91_ohci at91_ohci: AT91 OHCI
> at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
> at91_ohci at91_ohci: irq 23, io mem 0x00300000
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> usbcore: registered new interface driver usbserial
> USB Serial support registered for generic
> usbcore: registered new interface driver usbserial_generic
> usbserial: USB Serial Driver core
> USB Serial support registered for MCT U232
> usbcore: registered new interface driver mct_u232
> mct_u232: z2.1:Magic Control Technology USB-RS232 converter driver
> USB Serial support registered for pl2303
> usbcore: registered new interface driver pl2303
> pl2303: Prolific PL2303 USB to serial adaptor driver
> USB Serial support registered for Sierra USB modem
> usbcore: registered new interface driver sierra
> sierra: v.1.7.16:USB Driver for Sierra Wireless USB modems
> udc: at91_udc version 3 May 2006
> g_serial gadget: Gadget Serial v2.4
> g_serial gadget: g_serial ready
> at91_rtc at91_rtc: rtc core: registered at91_rtc as rtc0
> AT91 Real Time Clock driver.
> AT91 Watchdog Timer enabled (5 seconds, nowayout)
> Netfilter messages via NETLINK v0.30.
> nf_conntrack version 0.5.0 (457 buckets, 1828 max)
> ctnetlink v0.93: registering with nfnetlink.
> IPv4 over IPv4 tunneling driver
> ip_tables: (C) 2000-2006 Netfilter Core Team
> TCP cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Bridge firewalling registered
> L2TP core driver, V2.0
> PPPoL2TP kernel driver, V2.0
> at91_rtc at91_rtc: setting system clock to 1998-01-01 00:00:38 UTC (883612838)
> usb 1-2: new full speed USB device number 2 using at91_ohci
> usb 1-1: new full speed USB device number 3 using at91_ohci
> VFS: Mounted root (jffs2 filesystem) on device 31:2.
> Freeing init memory: 124K
> Loading modules backported from Linux version v3.12.8-0-g97f15f1
> Backport generated by backports.git v3.12.8-1-0-geb41fad
> cfg80211: Calling CRDA to update world regulatory domain
> usb 1-2: ath9k_htc: Firmware htc_9271.fw requested
> usbcore: registered new interface driver ath9k_htc
> GobiNet: 2012-10-18/SWI_2.13
> GobiNet 1-1:1.0: eth1: register 'GobiNet' at usb-at91-1, GobiNet
> Ethernet Device, da:03:38:1a:54:04
> usb 1-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008
> ath9k_htc 1-2:1.0: ath9k_htc: HTC initialized with 33 credits
> creating qcqmi1
> usbcore: registered new interface driver GobiNet
> USB Serial support registered for GobiSerial
> GobiSerial 1-1:1.1: GobiSerial converter detected
> usb 1-1: GobiSerial converter now attached to ttyUSB0
> GobiSerial 1-1:1.2: GobiSerial converter detected
> usb 1-1: GobiSerial converter now attached to ttyUSB1
> GobiSerial 1-1:1.3: GobiSerial converter detected
> usb 1-1: GobiSerial converter now attached to ttyUSB2
> usbcore: registered new interface driver GobiSerial
> GobiSerial: 2012-10-18/SWI_2.8
> eth0: Link now 100-FullDuplex
> ath9k_htc 1-2:1.0: ath9k_htc: FW Version: 1.4
> ath: EEPROM regdomain: 0x10
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: CO
> ath: Regpair used: 0x10
> cfg80211: wext will not work because kernel was compiled with
> CONFIG_WIRELESS_EXT=n. Tools using wext interface, like iwconfig will
> not work.
> ieee80211 phy0: Atheros AR9271 Rev:1
> device wlan0 entered promiscuous mode
> device wlan0 left promiscuous mode
> device wlan0 entered promiscuous mode
> device wlan0 left promiscuous mode
> 
> 
> On Sun, May 11, 2014 at 8:40 AM, Adrian Chadd <adrian@freebsd.org> wrote:
>> Hi,
>>
>> are you running these devices through a powered hub? If not, can you test that?
>>
>> I've read the above emails and the first email still rings worrysome.
>> You don't want to be under-powering the NIC in any way or things may
>> get extremely pissed off.
>>
>> Are you using an AR9170, or an actual ath9k_htc part?
>>
>> Can you post a dmesg?
>>
>>
>> -a
>>
>>
>> On 10 May 2014 23:40, Aaron Hamilton <aaron@logicdatasystems.net> wrote:
>>> I'll give the patches/config a try and see if it helps anything. Also,
>>> the line "supported_rates=10 20 55" doesn't seem to be working. When I
>>> do a station dump, the tx rate is reported as 6.5 Mbit/s.
>>>
>>> On the device that is currently locked up and not accepting
>>> connections, what are some options for obtaining useful data on the
>>> current state of the device (i.e. queue status, etc)? I know I can
>>> restart hostapd to fix it, but that doesn't help me find the root
>>> cause (and thus how to fix it).
>>>
>>> I've gone through an incredible amount of iterations of kernel
>>> configurations, hostapd changes, etc and I'm pulling my hair out not
>>> getting any closer to finding the problem. I really appreciate all the
>>> help thus far, but it would be awesome to be able to see the state of
>>> the queues and see if/where anything is locked up or pending.
>>>
>>> On Sat, May 10, 2014 at 2:26 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>> Am 09.05.2014 00:57, schrieb Aaron Hamilton:
>>>>> Did further testing and we still seem to have issues with clients
>>>>> connecting. Here's our scenario:
>>>>>
>>>>> ** Problem 1 - Extreme Latency **
>>>>>
>>>>> 1) Connect a Panasonic Toughbook laptop to the WiFi AP. Connection
>>>>> appears to come up without any issues. We initiate ongoing pings to
>>>>> the computer from the AP with consistent 3ms to 10ms responses.
>>>>>
>>>>> 2) Connect an embedded device to the AP (dnsmasq reports vendor class
>>>>> udhcp 1.18.5). When we initiate pings from the AP to the device,
>>>>> responses take between 500ms and 1000ms.
>>>>>
>>>>> We then powered down both client devices and reconnected only the
>>>>> embedded client. This time the pings started at 32ms and increased in
>>>>> latency for every subsequent ping. The following is a capture from the
>>>>> AP. It appears as though each subsequent ping is further delayed by
>>>>> approximately 20ms. During this time, only the one client is
>>>>> connected. Also, the only traffic coming across the interface are
>>>>> pings, which leads me to believe this is not a bandwidth problem.
>>>>
>>>> I'm 100% sure, it is about bandwidth.
>>>> Right now i did test with one AP (ath9k_htc) + 2 STAs.
>>>> AR9271 adapter is connected to USB 2.0 in high speed mode.
>>>>
>>>> Ping test:
>>>> - both STAs provide stable PING with ~2ms if they are in one room.
>>>> - After one STA was moved behind two walls it got less stable ping which
>>>> was variating 2-100ms.
>>>>
>>>> Bench test:
>>>> - Each STA run two stream netperf. AP is in HT20 since there is another
>>>> AP with HT40 in same room.
>>>> - The STA behind two walls had almost no chance. It got some 100KB/s
>>>> - The closest STA had about 4MB/s
>>>>
>>>> Well, for this kind of device it is acceptable:
>>>> https://wikidevi.com/wiki/ThinkPenguin_TPE-N150USB
>>>>
>>>>> # ping 192.168.2.192
>>>>> PING 192.168.2.192 (192.168.2.192): 56 data bytes
>>>>> 64 bytes from 192.168.2.192: seq=32 ttl=64 time=32.043 ms
>>>>> 64 bytes from 192.168.2.192: seq=33 ttl=64 time=155.090 ms
>>>>> 64 bytes from 192.168.2.192: seq=34 ttl=64 time=1013.031 ms
>>>>> 64 bytes from 192.168.2.192: seq=35 ttl=64 time=21.302 ms
>>>>> 64 bytes from 192.168.2.192: seq=36 ttl=64 time=6.622 ms
>>>>> 64 bytes from 192.168.2.192: seq=37 ttl=64 time=8.240 ms
>>>>> 64 bytes from 192.168.2.192: seq=38 ttl=64 time=79.743 ms
>>>>> 64 bytes from 192.168.2.192: seq=39 ttl=64 time=103.089 ms
>>>>> 64 bytes from 192.168.2.192: seq=40 ttl=64 time=121.613 ms
>>>>> 64 bytes from 192.168.2.192: seq=41 ttl=64 time=143.677 ms
>>>>> 64 bytes from 192.168.2.192: seq=42 ttl=64 time=167.053 ms
>>>>> 64 bytes from 192.168.2.192: seq=43 ttl=64 time=190.735 ms
>>>>> 64 bytes from 192.168.2.192: seq=44 ttl=64 time=215.027 ms
>>>>> 64 bytes from 192.168.2.192: seq=45 ttl=64 time=236.206 ms
>>>>> 64 bytes from 192.168.2.192: seq=46 ttl=64 time=259.461 ms
>>>>> 64 bytes from 192.168.2.192: seq=47 ttl=64 time=283.142 ms
>>>>> 64 bytes from 192.168.2.192: seq=48 ttl=64 time=302.704 ms
>>>>> 64 bytes from 192.168.2.192: seq=49 ttl=64 time=325.379 ms
>>>>> 64 bytes from 192.168.2.192: seq=50 ttl=64 time=364.105 ms
>>>>> 64 bytes from 192.168.2.192: seq=51 ttl=64 time=372.955 ms
>>>>> 64 bytes from 192.168.2.192: seq=52 ttl=64 time=394.073 ms
>>>>> 64 bytes from 192.168.2.192: seq=53 ttl=64 time=433.075 ms
>>>>> 64 bytes from 192.168.2.192: seq=54 ttl=64 time=436.615 ms
>>>>> 64 bytes from 192.168.2.192: seq=55 ttl=64 time=462.372 ms
>>>>> 64 bytes from 192.168.2.192: seq=56 ttl=64 time=484.283 ms
>>>>> 64 bytes from 192.168.2.192: seq=57 ttl=64 time=510.132 ms
>>>>> 64 bytes from 192.168.2.192: seq=58 ttl=64 time=534.637 ms
>>>>> 64 bytes from 192.168.2.192: seq=59 ttl=64 time=552.154 ms
>>>>> 64 bytes from 192.168.2.192: seq=60 ttl=64 time=571.411 ms
>>>>> 64 bytes from 192.168.2.192: seq=61 ttl=64 time=594.605 ms
>>>>> 64 bytes from 192.168.2.192: seq=62 ttl=64 time=616.638 ms
>>>>> 64 bytes from 192.168.2.192: seq=63 ttl=64 time=535.492 ms
>>>>> 64 bytes from 192.168.2.192: seq=64 ttl=64 time=661.377 ms
>>>>> 64 bytes from 192.168.2.192: seq=65 ttl=64 time=685.821 ms
>>>>> 64 bytes from 192.168.2.192: seq=66 ttl=64 time=708.862 ms
>>>>> ^C
>>>>> --- 192.168.2.192 ping statistics ---
>>>>> 68 packets transmitted, 35 packets received, 48% packet loss
>>>>> round-trip min/avg/max = 6.622/359.507/1013.031 ms
>>>>> #
>>>>
>>>> I would expect this kind of behaviour with high packet loss.
>>>>
>>>>> ** Problem 2 - Total Loss of Connectivity **
>>>>>
>>>>> Another issue we have is that WiFi clients loose their ability to
>>>>> connect to the AP after a period of time. I have remote access into an
>>>>> AP currently exhibiting this behavior. Here's what we're seeing:
>>>>>
>>>>> 1) WiFi beacon is being broadcast and is visible to clients
>>>>>
>>>>> 2) Client connection attempt fails and nothing appears in log
>>>>> indicating an attempt is made. Typically we would at least see
>>>>> association/authentication messages in the syslog.
>>>>>
>>>>> 3) Nothing unusual is reported by dmesg
>>>>>
>>>>> 4) If hostapd is restarted, connections will come back up
>>>>>
>>>>> Any ideas?  Is there anything I can gather from debugfs or other means?
>>>>
>>>> Firmware is defiantly not oopsed.
>>>> In some cases i noticed that firmware was not able to provide
>>>> notification about send or field TX packets because
>>>>  event queue was full. With slow usb i would assume that this queue will
>>>> often make some problems. But kernel driver was able to recover
>>>> connection even in this case. So, i don't think it will stall forever.
>>>>
>>>> You can try to add "disassoc_low_ack=1" to hostapd.conf which may be
>>>> will refresh some stalled connections.
>>>>
>>>> Other idea is to disbale ani. Try this workaround:
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
>>>> b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
>>>> index f46cd02..e89f85c 100644
>>>> --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
>>>> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
>>>> @@ -744,6 +744,8 @@ void ath9k_htc_start_ani(struct ath9k_htc_priv *priv)
>>>>         struct ath_common *common = ath9k_hw_common(priv->ah);
>>>>         unsigned long timestamp = jiffies_to_msecs(jiffies);
>>>>
>>>> +       return;
>>>> +
>>>>         common->ani.longcal_timer = timestamp;
>>>>         common->ani.shortcal_timer = timestamp;
>>>>         common->ani.checkani_timer = timestamp;
>>>>
>>>>
>>>>
>>>>
>>>>> On Tue, May 6, 2014 at 12:21 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>>>
>>>>>> Am 06.05.2014 03:57, schrieb Aaron Hamilton:
>>>>>>> Oh ok. Is this not already handled by hostapd or the wifi drivers?
>>>>>>
>>>>>> No. hostapd suggest which rutaes should be used and driver, btw.
>>>>>> mac80211 should fallow this suggestion. ip layer is not touched.
>>>>>>
>>>>>>>
>>>>>>> Also, I reverted back to backports-3.12.8-1 and now trying to see if
>>>>>>> there's a difference when using sch_codel.ko and sch_fq_codel.ko
>>>>>>> (previously these two modules were not used as I was trying to minimize
>>>>>>> the number of moving parts). Which by the way, am I gaining or loosing
>>>>>>> anything with these? I'm not quiet sure what their purpose is.
>>>>>>
>>>>>> Scheduling is good for many reasons. For example, if you know what
>>>>>> bandwidth you have (in your case you know it) it is possible to use
>>>>>> priority for critical applications. DNS and ICMP traffic will have
>>>>>> higher priority then HTTP, and so on. Read more about QoS.
>>>>>> I would suggest to set scheduler to bandwidth lover then your USB
>>>>>> bandwidth. It should reduces usage of ath9k_htc_fw buffer. If you
>>>>>> configure scheduler, please try remove "supported_rates=10 20 55" from
>>>>>> you config.
>>>>>>
>>>>>> Don't forget. It is not enough to add scheduler module. You will need
>>>>>> configure it.
>>>>>>
>>>>>>> I'm also using the attached hostapd.conf file. Previously, when two
>>>>>>> devices were on the WiFi, one would always have ping latency of several
>>>>>>> hundred milliseconds despite minimal traffic on either host. Now latency
>>>>>>> only seems to spike when a large continuous file is moved across the
>>>>>>> WiFi. Streaming of music for example doesn't seem to have much effect on
>>>>>>> the other WiFi clients.
>>>>>>
>>>>>> How about filed tests? Do you still have stability issues?
>>>>>>
>>>>>>> # Begin hosatpd.conf
>>>>>>> interface=wlan0
>>>>>>> driver=nl80211
>>>>>>>
>>>>>>> hw_mode=g
>>>>>>>
>>>>>>> dump_file=/tmp/hostapd.dump
>>>>>>> ctrl_interface=/var/run/hostapd
>>>>>>> ctrl_interface_group=0
>>>>>>>
>>>>>>> logger_syslog=-1
>>>>>>> logger_syslog_level=2
>>>>>>> beacon_int=500
>>>>>>> dtim_period=2
>>>>>>>
>>>>>>> supported_rates=10 20 55
>>>>>>>
>>>>>>> max_num_sta=5
>>>>>>> rts_threshold=2347
>>>>>>> fragm_threshold=2346
>>>>>>>
>>>>>>> macaddr_acl=0
>>>>>>> eapol_version=1
>>>>>>> eapol_key_index_workaround=0
>>>>>>>
>>>>>>> # Attempting max time-outs for increased reliability
>>>>>>> wpa_group_rekey=0
>>>>>>> wpa_gmk_rekey=86400
>>>>>>> # wmm_enabled=1
>>>>>>> ieee80211n=1
>>>>>>> ieee80211d=1
>>>>>>> country_code=DE
>>>>>>> ht_capab=[HT40+][RX-STBC1][DSSS_CCK-40][SHORT-GI-40]
>>>>>>> ignore_broadcast_ssid=0
>>>>>>> channel=1
>>>>>>> ssid=TestSSID
>>>>>>>
>>>>>>> auth_algs=1
>>>>>>> wpa=2
>>>>>>> wpa_key_mgmt=WPA-PSK
>>>>>>>
>>>>>>> wpa_pairwise=CCMP
>>>>>>> rsn_pairwise=CCMP
>>>>>>>
>>>>>>> wpa_passphrase=fixmeplease
>>>>>>> # end hostapd.conf
>>>>>>>
>>>>>>>
>>>>>>> On Mon, May 5, 2014 at 12:32 PM, Oleksij Rempel <linux@rempel-privat.de
>>>>>>> <mailto:linux@rempel-privat.de>> wrote:
>>>>>>>
>>>>>>>     Am 05.05.2014 20:09, schrieb Aaron Hamilton:
>>>>>>>     > I'm sorry, what's TC?
>>>>>>>
>>>>>>>     http://linux.die.net/man/8/tc
>>>>>>>
>>>>>>>     > On Sat, May 3, 2014 at 2:07 AM, Oleksij Rempel
>>>>>>>     <linux at rempel-privat.de <mailto:linux@rempel-privat.de>
>>>>>>>     > <mailto:linux at rempel-privat.de <mailto:linux@rempel-privat.de>>>
>>>>>>>     wrote:
>>>>>>>     >
>>>>>>>     >     Am 02.05.2014 12:11, schrieb Aaron Hamilton:
>>>>>>>     >     > Ok, I updated the drivers to backports 3.14-1 and configured the
>>>>>>>     >     > following hostapd settings. I connected an iPad and a
>>>>>>>     Windows PC, then
>>>>>>>     >     > ran continuous pings. For the first couple seconds
>>>>>>>     everything was
>>>>>>>     >     > returning in a few milliseconds. Within 30 seconds, the
>>>>>>>     pings started
>>>>>>>     >     > getting into the several hundred ms range (or timing out)
>>>>>>>     and remained
>>>>>>>     >     > there (for both the iPad and PC).
>>>>>>>     >     >
>>>>>>>     >     > After I disconnected the PC from the WiFi, the iPad's pings
>>>>>>>     dropped to
>>>>>>>     >     > an average of 15ms (about 30s to a minute after the PC was
>>>>>>>     moved to
>>>>>>>     >     > another AP).
>>>>>>>
>>>>>>>     --
>>>>>>>     Regards,
>>>>>>>     Oleksij
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Oleksij
>>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Oleksij
>>>>
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140512/43706238/attachment.pgp