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

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

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 <linux@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 <linux@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

-------------- 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/20140502/b954678e/attachment.pgp