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. # 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 # ** 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? 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 > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
