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@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 <adr...@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 <aa...@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 <li...@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 <li...@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 <li...@rempel-privat.de >>>>>>> <mailto:li...@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 >>>>>>> <li...@rempel-privat.de <mailto:li...@rempel-privat.de> >>>>>>> > <mailto:li...@rempel-privat.de <mailto:li...@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@lists.ath9k.org >>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
