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). I didn't run this test personally before, so I'm not sure if this is new behavior. # Hostapd.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=100 dtim_period=2 max_num_sta=7 rts_threshold=2347 fragm_threshold=2346 macaddr_acl=0 eapol_version=1 eapol_key_index_workaround=0 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 On Thu, May 1, 2014 at 11:27 PM, Aaron Hamilton <aa...@logicdatasystems.net> wrote: > Looks like "nohwcrypt=1" is a no-go. When this is configured, speed > tests initially show 2.2Mbps for about two seconds until the entire > device locks up and reboots. Without "nohwcrypt=1", I get 5 to 5.5Mbps > consistently. > > The wifi module is the only thing on the USB bus. But I'm happy with > 5Mbps if it's stable. > > On Thu, May 1, 2014 at 3:41 PM, Oleksij Rempel <li...@rempel-privat.de> wrote: >> Am 02.05.2014 00:00, schrieb Aaron Hamilton: >>> Considering the wifi card is attached to an at91rm9200 >>> (http://www.atmel.com/Images/1768s.pdf) that only has a 12 Mbps USB >>> port, does it matter if I enable 802.11n? >> >> Theoretically it will work at same speed as before, but transaction will >> take less air time. >> >> 12 MBps ... ufff.. i never tested FS mode. This device has huge >> difference on HS and SS hosts. There are different speed and stability >> issues. I won't be surprised if it is part of the problem. >> Interrupt traffic may reserve big part of your available usb bandwidth. >> How many devices do you have on same root hub? >> >> Did you tried to increase beacon interval to reduce usb traffic? >> >> >>> On Wed, Apr 30, 2014 at 10:37 PM, Oleksij Rempel <li...@rempel-privat.de> >>> wrote: >>>> Am 01.05.2014 01:03, schrieb Aaron Hamilton: >>>>> I believe CONFIG_ATH_DEBUG is enabled, but I'll double check again. >>>>> Attached is the hostapd.conf we're using. Right now the only logs we >>>>> see are what's in syslog or dmesg, but I'd be more than happy to >>>>> enable whatever I can. Just need to know what to configure. >>>> >>>> First mistake what i see in hostapd.conf is: >>>> max_num_sta=255 >>>> it should be 8 >>>> >>>> second, max_num_sta=255 is not enabled: >>>> ieee80211n=1 >>>> ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40][RX-STBC1] >>>> channel=11 >>>> ieee80211d=1 >>>> country_code=DE >>>> >>>> then you may try module parameter "nohwcrypt=1", just to make sure. >>>> >>>>> Thus far everytime we've had an issue with clients unable to connect, >>>>> a restart of hostapd fixed it. Strangely, the clients were able to see >>>>> the SSID broadcast, but failed immediately upon a connection attempt. >>>>> The problem also seems to be all or none. Once one client looses >>>>> connection, they all do until hostapd is restarted or the device is >>>>> power cycled. >>>> >>>> Did you tried to reproduce this problem with more then one STA? >>>> It look for me more like "max_num_sta=255" problem. >>>> >>>>> >>>>> On Wed, Apr 30, 2014 at 1:40 PM, Oleksij Rempel <li...@rempel-privat.de> >>>>> wrote: >>>>>> Am 30.04.2014 22:16, schrieb Oleksij Rempel: >>>>>>> Am 30.04.2014 20:59, schrieb Aaron Hamilton: >>>>>>>> Unfortunately our units are in another state, so we're unable to make >>>>>>>> the electrical connections. If the UART is RS-232, we might be able to >>>>>>>> modify some locally - but it'll be a rather difficult challenge. >>>>>>> >>>>>>> It is TTL level, 3,3 Volt. >>>>>>> >>>>>>>> Not >>>>>>>> to mention, we see a great deal of issues in the field, but can't >>>>>>>> duplicate them here. >>>>>>> >>>>>>> Did you tried to grab hostpad log to so what kind of connections do you >>>>>>> have? What is your hostapd config? >>>>>>> >>>>>>>> On the firmware, I'm pulling down io_clean-2014.04.29 right now. I'm >>>>>>>> assuming this is what I should be using? >>>>>>> >>>>>>> You can use it, but these changes should make sense only if you can get >>>>>>> oops log from firmware. Or at least FW panic report from dmesg. >>>>>>> >>>>>>> Theoretically this change set should not affect stability. >>>>>>> >>>>>>>> Are there any other options for debugging aside from the UART? We're >>>>>>>> really in a bind and feel like the only work around is to setup a task >>>>>>>> to restart hostapd every hour. >>>>>>> >>>>>>> Hmm.. restarting hostpad should not affect firmware. Is it really >>>>>>> working for you? >>>>>> >>>>>> Make sure you have CONFIG_ATH_DEBUG enabled. May be we can get some >>>>>> interesting information. For example WMI timeouts are printed with >>>>>> ath_dbg which is disable without CONFIG_ATH_DEBUG. >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Oleksij >>>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Oleksij >>>> >> >> >> -- >> Regards, >> Oleksij >> _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
