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

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

[Aaron Hamilton]

Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?

I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).

Here's our setup:
- host: at91 ARM processor on 2.6.39.4 kernel
- runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
- hostapd-2.0
- latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)

At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.

Thanks in advance!

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

[Oleksij Rempel]

Am 28.04.2014 22:43, schrieb Aaron Hamilton:
> Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?

Usually i do benchmark tests and some hours of load tests. Some devices
fail on high load. Yesterday i was able to narrow down one of firmware
crashes, but with current fw and kernel, it will recover connection in
some seconds. So this problem is not nice, but not critical.

If you are able to grub firmware log from uart port on the chip, or get
panic report from kernel, if you have patched kernel, then it will be
good start.

In any case most interesting changes are from this year, so don't use
old backports.

If you have firmware crashes, i would suggest you todays FW source:
https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean

the difference to other branches is that panic report should show
address of function which made ioread/write request

> I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).

Are you sure you are using ar9710 with ath9k-htc?

> Here's our setup:
> - host: at91 ARM processor on 2.6.39.4 kernel
> - runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
> - hostapd-2.0
> - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)
> 
> At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.
> 
> Thanks in advance!
> _______________________________________________
> 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/20140429/ac12860a/attachment.pgp 

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

[Aaron Hamilton]

On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>
> Am 28.04.2014 22:43, schrieb Aaron Hamilton:
> > Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?
>
> Usually i do benchmark tests and some hours of load tests. Some devices
> fail on high load. Yesterday i was able to narrow down one of firmware
> crashes, but with current fw and kernel, it will recover connection in
> some seconds. So this problem is not nice, but not critical.
>
> If you are able to grub firmware log from uart port on the chip, or get
> panic report from kernel, if you have patched kernel, then it will be
> good start.

Unfortunately our modules don't have a UART port accessible. When
clients are no longer able to connect, I can't seem to find anything
unusual in dmesg. The only thing of interest are log entries for "IEEE
802.11: deauthenticated due to local deauth request". Although
sometimes there's no indicating or activity at all.

I'm deploying several units with debugfs enabled (wasn't there
previously). Is there anything I should be looking for there?

>
> In any case most interesting changes are from this year, so don't use
> old backports.
>
> If you have firmware crashes, i would suggest you todays FW source:
> https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean
>
> the difference to other branches is that panic report should show
> address of function which made ioread/write request
>
> > I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).
>
> Are you sure you are using ar9710 with ath9k-htc?
>

Sorry, that's a typo. We're using AR9271 Rev 1 chipsets. Here's an
image: http://www.zcom.com.tw/program1/big_pic/ZCN-722M.jpg

I also neglected to mention that I've compiled the kernel without QoS
support as that seems to make the problem worse.

> > Here's our setup:
> > - host: at91 ARM processor on 2.6.39.4 kernel
> > - runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
> > - hostapd-2.0
> > - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)
> >
> > At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.
> >
> > Thanks in advance!
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
>
>
> --
> Regards,
> Oleksij
>

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

[Oleksij Rempel]

Am 29.04.2014 08:19, schrieb Aaron Hamilton:
> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>
>> Am 28.04.2014 22:43, schrieb Aaron Hamilton:
>>> Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?
>>
>> Usually i do benchmark tests and some hours of load tests. Some devices
>> fail on high load. Yesterday i was able to narrow down one of firmware
>> crashes, but with current fw and kernel, it will recover connection in
>> some seconds. So this problem is not nice, but not critical.
>>
>> If you are able to grub firmware log from uart port on the chip, or get
>> panic report from kernel, if you have patched kernel, then it will be
>> good start.
> 
> Unfortunately our modules don't have a UART port accessible. When
> clients are no longer able to connect, I can't seem to find anything
> unusual in dmesg. The only thing of interest are log entries for "IEEE
> 802.11: deauthenticated due to local deauth request". Although
> sometimes there's no indicating or activity at all.

How many clients do you have? we can't handle more then 8. There is no
enough RAM for more.

> I'm deploying several units with debugfs enabled (wasn't there
> previously). Is there anything I should be looking for there?

No. Check if you have "ath9k_htc: catch fw panic pattern" patch.

>>
>> In any case most interesting changes are from this year, so don't use
>> old backports.
>>
>> If you have firmware crashes, i would suggest you todays FW source:
>> https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean
>>
>> the difference to other branches is that panic report should show
>> address of function which made ioread/write request
>>
>>> I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).
>>
>> Are you sure you are using ar9710 with ath9k-htc?
>>
> 
> Sorry, that's a typo. We're using AR9271 Rev 1 chipsets. Here's an
> image: http://www.zcom.com.tw/program1/big_pic/ZCN-722M.jpg
> 
> I also neglected to mention that I've compiled the kernel without QoS
> support as that seems to make the problem worse.
> 
>>> Here's our setup:
>>> - host: at91 ARM processor on 2.6.39.4 kernel
>>> - runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
>>> - hostapd-2.0
>>> - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)
>>>
>>> At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.
>>>
>>> Thanks in advance!
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>>
>> --
>> 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/20140429/e2b15fe4/attachment.pgp 

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

[Aaron Hamilton]

Typically there are only two clients at a time, sometimes three.

We're using backports-3.12.8-1, which doesn't appear to have the
patch. I've tried compiling both backports-3.14-1 and 3.15-rc1, but
both fail for various reasons. Hopefully someone on the backports
mailing list can help with that portion.

On Mon, Apr 28, 2014 at 11:31 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 29.04.2014 08:19, schrieb Aaron Hamilton:
>> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>
>>> Am 28.04.2014 22:43, schrieb Aaron Hamilton:
>>>> Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?
>>>
>>> Usually i do benchmark tests and some hours of load tests. Some devices
>>> fail on high load. Yesterday i was able to narrow down one of firmware
>>> crashes, but with current fw and kernel, it will recover connection in
>>> some seconds. So this problem is not nice, but not critical.
>>>
>>> If you are able to grub firmware log from uart port on the chip, or get
>>> panic report from kernel, if you have patched kernel, then it will be
>>> good start.
>>
>> Unfortunately our modules don't have a UART port accessible. When
>> clients are no longer able to connect, I can't seem to find anything
>> unusual in dmesg. The only thing of interest are log entries for "IEEE
>> 802.11: deauthenticated due to local deauth request". Although
>> sometimes there's no indicating or activity at all.
>
> How many clients do you have? we can't handle more then 8. There is no
> enough RAM for more.
>
>> I'm deploying several units with debugfs enabled (wasn't there
>> previously). Is there anything I should be looking for there?
>
> No. Check if you have "ath9k_htc: catch fw panic pattern" patch.
>
>>>
>>> In any case most interesting changes are from this year, so don't use
>>> old backports.
>>>
>>> If you have firmware crashes, i would suggest you todays FW source:
>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean
>>>
>>> the difference to other branches is that panic report should show
>>> address of function which made ioread/write request
>>>
>>>> I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).
>>>
>>> Are you sure you are using ar9710 with ath9k-htc?
>>>
>>
>> Sorry, that's a typo. We're using AR9271 Rev 1 chipsets. Here's an
>> image: http://www.zcom.com.tw/program1/big_pic/ZCN-722M.jpg
>>
>> I also neglected to mention that I've compiled the kernel without QoS
>> support as that seems to make the problem worse.
>>
>>>> Here's our setup:
>>>> - host: at91 ARM processor on 2.6.39.4 kernel
>>>> - runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
>>>> - hostapd-2.0
>>>> - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)
>>>>
>>>> At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.
>>>>
>>>> Thanks in advance!
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Oleksij
>>>
>
>
> --
> Regards,
> Oleksij
>

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

[Aaron Hamilton]

Ok, I was able to get backports-3.14-1 compiled by commenting out a
line in compat.h. However, even 3.14-1 doesn't appear to include your
patch for catching the fw panic. I'm patching these into 3.14-1 now
and deploying.

Also, we had another instance today of the wifi going down. There's
nothing unusual in dmesg and nothing shows up in the logs. The router
is currently in the locked state, so I'd be more than happy to do
whatever debugging or prodding is needed. I can also provide SSH
access if it helps.

Lastly is there a more stable source for accessing these updates
(OpenWrt maybe)? It seems like the backports releases for 3.15 and up
aren't meant to work on a 2.6.39.4 kernel (or have bugs preventing
them from compiling at least).

On Tue, Apr 29, 2014 at 2:08 AM, Aaron Hamilton
<aaron@logicdatasystems.net> wrote:
> Typically there are only two clients at a time, sometimes three.
>
> We're using backports-3.12.8-1, which doesn't appear to have the
> patch. I've tried compiling both backports-3.14-1 and 3.15-rc1, but
> both fail for various reasons. Hopefully someone on the backports
> mailing list can help with that portion.
>
> On Mon, Apr 28, 2014 at 11:31 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 29.04.2014 08:19, schrieb Aaron Hamilton:
>>> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>
>>>> Am 28.04.2014 22:43, schrieb Aaron Hamilton:
>>>>> Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?
>>>>
>>>> Usually i do benchmark tests and some hours of load tests. Some devices
>>>> fail on high load. Yesterday i was able to narrow down one of firmware
>>>> crashes, but with current fw and kernel, it will recover connection in
>>>> some seconds. So this problem is not nice, but not critical.
>>>>
>>>> If you are able to grub firmware log from uart port on the chip, or get
>>>> panic report from kernel, if you have patched kernel, then it will be
>>>> good start.
>>>
>>> Unfortunately our modules don't have a UART port accessible. When
>>> clients are no longer able to connect, I can't seem to find anything
>>> unusual in dmesg. The only thing of interest are log entries for "IEEE
>>> 802.11: deauthenticated due to local deauth request". Although
>>> sometimes there's no indicating or activity at all.
>>
>> How many clients do you have? we can't handle more then 8. There is no
>> enough RAM for more.
>>
>>> I'm deploying several units with debugfs enabled (wasn't there
>>> previously). Is there anything I should be looking for there?
>>
>> No. Check if you have "ath9k_htc: catch fw panic pattern" patch.
>>
>>>>
>>>> In any case most interesting changes are from this year, so don't use
>>>> old backports.
>>>>
>>>> If you have firmware crashes, i would suggest you todays FW source:
>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean
>>>>
>>>> the difference to other branches is that panic report should show
>>>> address of function which made ioread/write request
>>>>
>>>>> I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).
>>>>
>>>> Are you sure you are using ar9710 with ath9k-htc?
>>>>
>>>
>>> Sorry, that's a typo. We're using AR9271 Rev 1 chipsets. Here's an
>>> image: http://www.zcom.com.tw/program1/big_pic/ZCN-722M.jpg
>>>
>>> I also neglected to mention that I've compiled the kernel without QoS
>>> support as that seems to make the problem worse.
>>>
>>>>> Here's our setup:
>>>>> - host: at91 ARM processor on 2.6.39.4 kernel
>>>>> - runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
>>>>> - hostapd-2.0
>>>>> - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)
>>>>>
>>>>> At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.
>>>>>
>>>>> Thanks in advance!
>>>>> _______________________________________________
>>>>> ath9k-devel mailing list
>>>>> ath9k-devel at lists.ath9k.org
>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Oleksij
>>>>
>>
>>
>> --
>> Regards,
>> Oleksij
>>

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

[Oleksij Rempel]

Am 30.04.2014 19:29, schrieb Aaron Hamilton:
> Ok, I was able to get backports-3.14-1 compiled by commenting out a
> line in compat.h. However, even 3.14-1 doesn't appear to include your
> patch for catching the fw panic. I'm patching these into 3.14-1 now
> and deploying.

> Also, we had another instance today of the wifi going down. There's
> nothing unusual in dmesg and nothing shows up in the logs.
> The router is currently in the locked state, so I'd be more than happy to do
> whatever debugging or prodding is needed. I can also provide SSH
> access if it helps.

More important is to get UART work. You can solder a wire directly to
the chip.

> Lastly is there a more stable source for accessing these updates
> (OpenWrt maybe)? It seems like the backports releases for 3.15 and up
> aren't meant to work on a 2.6.39.4 kernel (or have bugs preventing
> them from compiling at least).
> 
> On Tue, Apr 29, 2014 at 2:08 AM, Aaron Hamilton
> <aaron@logicdatasystems.net> wrote:
>> Typically there are only two clients at a time, sometimes three.
>>
>> We're using backports-3.12.8-1, which doesn't appear to have the
>> patch. I've tried compiling both backports-3.14-1 and 3.15-rc1, but
>> both fail for various reasons. Hopefully someone on the backports
>> mailing list can help with that portion.
>>
>> On Mon, Apr 28, 2014 at 11:31 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>> Am 29.04.2014 08:19, schrieb Aaron Hamilton:
>>>> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>>
>>>>> Am 28.04.2014 22:43, schrieb Aaron Hamilton:
>>>>>> Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?
>>>>>
>>>>> Usually i do benchmark tests and some hours of load tests. Some devices
>>>>> fail on high load. Yesterday i was able to narrow down one of firmware
>>>>> crashes, but with current fw and kernel, it will recover connection in
>>>>> some seconds. So this problem is not nice, but not critical.
>>>>>
>>>>> If you are able to grub firmware log from uart port on the chip, or get
>>>>> panic report from kernel, if you have patched kernel, then it will be
>>>>> good start.
>>>>
>>>> Unfortunately our modules don't have a UART port accessible. When
>>>> clients are no longer able to connect, I can't seem to find anything
>>>> unusual in dmesg. The only thing of interest are log entries for "IEEE
>>>> 802.11: deauthenticated due to local deauth request". Although
>>>> sometimes there's no indicating or activity at all.
>>>
>>> How many clients do you have? we can't handle more then 8. There is no
>>> enough RAM for more.
>>>
>>>> I'm deploying several units with debugfs enabled (wasn't there
>>>> previously). Is there anything I should be looking for there?
>>>
>>> No. Check if you have "ath9k_htc: catch fw panic pattern" patch.
>>>
>>>>>
>>>>> In any case most interesting changes are from this year, so don't use
>>>>> old backports.
>>>>>
>>>>> If you have firmware crashes, i would suggest you todays FW source:
>>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean
>>>>>
>>>>> the difference to other branches is that panic report should show
>>>>> address of function which made ioread/write request
>>>>>
>>>>>> I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).
>>>>>
>>>>> Are you sure you are using ar9710 with ath9k-htc?
>>>>>
>>>>
>>>> Sorry, that's a typo. We're using AR9271 Rev 1 chipsets. Here's an
>>>> image: http://www.zcom.com.tw/program1/big_pic/ZCN-722M.jpg
>>>>
>>>> I also neglected to mention that I've compiled the kernel without QoS
>>>> support as that seems to make the problem worse.
>>>>
>>>>>> Here's our setup:
>>>>>> - host: at91 ARM processor on 2.6.39.4 kernel
>>>>>> - runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
>>>>>> - hostapd-2.0
>>>>>> - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)
>>>>>>
>>>>>> At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.
>>>>>>
>>>>>> Thanks in advance!
>>>>>> _______________________________________________
>>>>>> ath9k-devel mailing list
>>>>>> ath9k-devel at lists.ath9k.org
>>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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/20140430/199e7471/attachment.pgp 

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

[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. Not
to mention, we see a great deal of issues in the field, but can't
duplicate them here.

On the firmware, I'm pulling down io_clean-2014.04.29 right now. I'm
assuming this is what I should be using?

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.

On Wed, Apr 30, 2014 at 11:27 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 30.04.2014 19:29, schrieb Aaron Hamilton:
>> Ok, I was able to get backports-3.14-1 compiled by commenting out a
>> line in compat.h. However, even 3.14-1 doesn't appear to include your
>> patch for catching the fw panic. I'm patching these into 3.14-1 now
>> and deploying.
>
>> Also, we had another instance today of the wifi going down. There's
>> nothing unusual in dmesg and nothing shows up in the logs.
>> The router is currently in the locked state, so I'd be more than happy to do
>> whatever debugging or prodding is needed. I can also provide SSH
>> access if it helps.
>
> More important is to get UART work. You can solder a wire directly to
> the chip.
>
>> Lastly is there a more stable source for accessing these updates
>> (OpenWrt maybe)? It seems like the backports releases for 3.15 and up
>> aren't meant to work on a 2.6.39.4 kernel (or have bugs preventing
>> them from compiling at least).
>>
>> On Tue, Apr 29, 2014 at 2:08 AM, Aaron Hamilton
>> <aaron@logicdatasystems.net> wrote:
>>> Typically there are only two clients at a time, sometimes three.
>>>
>>> We're using backports-3.12.8-1, which doesn't appear to have the
>>> patch. I've tried compiling both backports-3.14-1 and 3.15-rc1, but
>>> both fail for various reasons. Hopefully someone on the backports
>>> mailing list can help with that portion.
>>>
>>> On Mon, Apr 28, 2014 at 11:31 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>> Am 29.04.2014 08:19, schrieb Aaron Hamilton:
>>>>> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>>>
>>>>>> Am 28.04.2014 22:43, schrieb Aaron Hamilton:
>>>>>>> Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?
>>>>>>
>>>>>> Usually i do benchmark tests and some hours of load tests. Some devices
>>>>>> fail on high load. Yesterday i was able to narrow down one of firmware
>>>>>> crashes, but with current fw and kernel, it will recover connection in
>>>>>> some seconds. So this problem is not nice, but not critical.
>>>>>>
>>>>>> If you are able to grub firmware log from uart port on the chip, or get
>>>>>> panic report from kernel, if you have patched kernel, then it will be
>>>>>> good start.
>>>>>
>>>>> Unfortunately our modules don't have a UART port accessible. When
>>>>> clients are no longer able to connect, I can't seem to find anything
>>>>> unusual in dmesg. The only thing of interest are log entries for "IEEE
>>>>> 802.11: deauthenticated due to local deauth request". Although
>>>>> sometimes there's no indicating or activity at all.
>>>>
>>>> How many clients do you have? we can't handle more then 8. There is no
>>>> enough RAM for more.
>>>>
>>>>> I'm deploying several units with debugfs enabled (wasn't there
>>>>> previously). Is there anything I should be looking for there?
>>>>
>>>> No. Check if you have "ath9k_htc: catch fw panic pattern" patch.
>>>>
>>>>>>
>>>>>> In any case most interesting changes are from this year, so don't use
>>>>>> old backports.
>>>>>>
>>>>>> If you have firmware crashes, i would suggest you todays FW source:
>>>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean
>>>>>>
>>>>>> the difference to other branches is that panic report should show
>>>>>> address of function which made ioread/write request
>>>>>>
>>>>>>> I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).
>>>>>>
>>>>>> Are you sure you are using ar9710 with ath9k-htc?
>>>>>>
>>>>>
>>>>> Sorry, that's a typo. We're using AR9271 Rev 1 chipsets. Here's an
>>>>> image: http://www.zcom.com.tw/program1/big_pic/ZCN-722M.jpg
>>>>>
>>>>> I also neglected to mention that I've compiled the kernel without QoS
>>>>> support as that seems to make the problem worse.
>>>>>
>>>>>>> Here's our setup:
>>>>>>> - host: at91 ARM processor on 2.6.39.4 kernel
>>>>>>> - runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
>>>>>>> - hostapd-2.0
>>>>>>> - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)
>>>>>>>
>>>>>>> At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.
>>>>>>>
>>>>>>> Thanks in advance!
>>>>>>> _______________________________________________
>>>>>>> ath9k-devel mailing list
>>>>>>> ath9k-devel at lists.ath9k.org
>>>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Oleksij
>>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Oleksij
>>>>
>
>
> --
> Regards,
> Oleksij
>

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

[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?

> On Wed, Apr 30, 2014 at 11:27 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 30.04.2014 19:29, schrieb Aaron Hamilton:
>>> Ok, I was able to get backports-3.14-1 compiled by commenting out a
>>> line in compat.h. However, even 3.14-1 doesn't appear to include your
>>> patch for catching the fw panic. I'm patching these into 3.14-1 now
>>> and deploying.
>>
>>> Also, we had another instance today of the wifi going down. There's
>>> nothing unusual in dmesg and nothing shows up in the logs.
>>> The router is currently in the locked state, so I'd be more than happy to do
>>> whatever debugging or prodding is needed. I can also provide SSH
>>> access if it helps.
>>
>> More important is to get UART work. You can solder a wire directly to
>> the chip.
>>
>>> Lastly is there a more stable source for accessing these updates
>>> (OpenWrt maybe)? It seems like the backports releases for 3.15 and up
>>> aren't meant to work on a 2.6.39.4 kernel (or have bugs preventing
>>> them from compiling at least).
>>>
>>> On Tue, Apr 29, 2014 at 2:08 AM, Aaron Hamilton
>>> <aaron@logicdatasystems.net> wrote:
>>>> Typically there are only two clients at a time, sometimes three.
>>>>
>>>> We're using backports-3.12.8-1, which doesn't appear to have the
>>>> patch. I've tried compiling both backports-3.14-1 and 3.15-rc1, but
>>>> both fail for various reasons. Hopefully someone on the backports
>>>> mailing list can help with that portion.
>>>>
>>>> On Mon, Apr 28, 2014 at 11:31 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>> Am 29.04.2014 08:19, schrieb Aaron Hamilton:
>>>>>> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>>>>
>>>>>>> Am 28.04.2014 22:43, schrieb Aaron Hamilton:
>>>>>>>> Has anyone had success running an ath9k_htc module in AP mode for any length of time? If so, what versions of OS/hostapd/ath are you using?  Would you mind sharing your magic config files for your kernel, backports, hostapd, etc?
>>>>>>>
>>>>>>> Usually i do benchmark tests and some hours of load tests. Some devices
>>>>>>> fail on high load. Yesterday i was able to narrow down one of firmware
>>>>>>> crashes, but with current fw and kernel, it will recover connection in
>>>>>>> some seconds. So this problem is not nice, but not critical.
>>>>>>>
>>>>>>> If you are able to grub firmware log from uart port on the chip, or get
>>>>>>> panic report from kernel, if you have patched kernel, then it will be
>>>>>>> good start.
>>>>>>
>>>>>> Unfortunately our modules don't have a UART port accessible. When
>>>>>> clients are no longer able to connect, I can't seem to find anything
>>>>>> unusual in dmesg. The only thing of interest are log entries for "IEEE
>>>>>> 802.11: deauthenticated due to local deauth request". Although
>>>>>> sometimes there's no indicating or activity at all.
>>>>>
>>>>> How many clients do you have? we can't handle more then 8. There is no
>>>>> enough RAM for more.
>>>>>
>>>>>> I'm deploying several units with debugfs enabled (wasn't there
>>>>>> previously). Is there anything I should be looking for there?
>>>>>
>>>>> No. Check if you have "ath9k_htc: catch fw panic pattern" patch.
>>>>>
>>>>>>>
>>>>>>> In any case most interesting changes are from this year, so don't use
>>>>>>> old backports.
>>>>>>>
>>>>>>> If you have firmware crashes, i would suggest you todays FW source:
>>>>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean
>>>>>>>
>>>>>>> the difference to other branches is that panic report should show
>>>>>>> address of function which made ioread/write request
>>>>>>>
>>>>>>>> I'm desperate for stability as this problem has been ongoing for quite some time. We are using ar9710 chips in vehicle hotspots and the best we've been able to achieve is a few days of connectivity. Usually within hours all wifi clients loose their connection which can only be corrected with a hostapd restart (or power cycle).
>>>>>>>
>>>>>>> Are you sure you are using ar9710 with ath9k-htc?
>>>>>>>
>>>>>>
>>>>>> Sorry, that's a typo. We're using AR9271 Rev 1 chipsets. Here's an
>>>>>> image: http://www.zcom.com.tw/program1/big_pic/ZCN-722M.jpg
>>>>>>
>>>>>> I also neglected to mention that I've compiled the kernel without QoS
>>>>>> support as that seems to make the problem worse.
>>>>>>
>>>>>>>> Here's our setup:
>>>>>>>> - host: at91 ARM processor on 2.6.39.4 kernel
>>>>>>>> - runtime power management and LED support removed from kernel (otherwise entire device reboots when load is put on wifi interface)
>>>>>>>> - hostapd-2.0
>>>>>>>> - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot)
>>>>>>>>
>>>>>>>> At this point I'm willing to try just about anything to get at least a week or more of ongoing stability.
-- 
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/20140430/2418b9a5/attachment-0001.pgp 

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

[Oleksij Rempel]

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

-------------- 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/20140430/f37d507a/attachment.pgp 

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

[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.

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.

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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostapd.conf
Type: application/octet-stream
Size: 771 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140430/b944cd6a/attachment.obj 

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

[Ben Greear]

On 04/30/2014 11:59 AM, Aaron Hamilton wrote:
> 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. Not
> to mention, we see a great deal of issues in the field, but can't
> duplicate them here.
>
> On the firmware, I'm pulling down io_clean-2014.04.29 right now. I'm
> assuming this is what I should be using?
>
> 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.

Can you use a 'real' ath9k NIC that doesn't use firmware?

I think any time you can get rid of the firmware layer you
are likely to get a much better result...

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

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

[Oleksij Rempel]

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

-------------- 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/20140501/e4032767/attachment.pgp 

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

[Aaron Hamilton]

Ok, I'll make the changes to hostapd and try again. As for the number
of stations, in all instances there have never been more than 3
devices even configured for the AP. So we know the max was only 3 at
any given time.

Also, this problem happens at multiple sites for multiple different
STAs. In each case, once one STA looses connectivity, all of them do.
Thus far a restart of hostapd always allows everything to connect
again.

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
>

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

[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?

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
>

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

[Oleksij Rempel]

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 

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

[Aaron Hamilton]

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

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

[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).

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

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

[Oleksij Rempel]

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).

Well, i would expected this behaviour. If usb bandwidth is lover then
WiFi speed, then all packets will stall in the queue of
ath9k_htc_firmware. You can try to reduce usb traffic by increesing
beacon interval in hostapd.conf "beacon_int=1000" and reduce bandwidth
by using TC or limit available rates to "supported_rates=10 20 55".

I would prefer TC variant, but may be in your case limiting rates will
work better. Field testing will show.

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


-- 
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/20140503/3ad59395/attachment.pgp 

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

[Aaron Hamilton]

I'm sorry, what's TC?

On Sat, May 3, 2014 at 2:07 AM, Oleksij Rempel <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).
>
> Well, i would expected this behaviour. If usb bandwidth is lover then
> WiFi speed, then all packets will stall in the queue of
> ath9k_htc_firmware. You can try to reduce usb traffic by increesing
> beacon interval in hostapd.conf "beacon_int=1000" and reduce bandwidth
> by using TC or limit available rates to "supported_rates=10 20 55".
>
> I would prefer TC variant, but may be in your case limiting rates will
> work better. Field testing will show.
>
> > 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
> > <aaron@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 <linux@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 <
> linux at 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 at 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
> >>>
>
>
> --
> Regards,
> Oleksij
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140505/d19befcd/attachment.htm 

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

[Oleksij Rempel]

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

-------------- 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/20140505/bbc259b6/attachment-0001.pgp 

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

[Aaron Hamilton]

Oh ok. Is this not already handled by hostapd or the wifi drivers?

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.

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.

# 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>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@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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140505/9f10a5b1/attachment.htm 

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

[Oleksij Rempel]

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

-------------- 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/20140506/9466fef2/attachment.pgp 

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

[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.

# 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 <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
>

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

[Oleksij Rempel]

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

-------------- 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/20140510/8af4cba8/attachment.pgp 

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

[Aaron Hamilton]

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] Stable Version for ath9k_htc in AP Mode?

[Adrian Chadd]

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

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

[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

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

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

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

[Oleksij Rempel]

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 

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

[Peter Stuge]

Oleksij Rempel wrote:
> 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.

True as that may be, if there is a bandwidth requirement for the
interface to function correctly and the USB protocol being used does
not guarantee that bandwidth (only control+interrupt transfers could
do it in a meaningful way, and they are rather low bandwidth) then
the USB stack would have to allow the driver to reserve bus time, and
the driver would have to make a reservation to successfully handle
worst-case load.

That's not neccessarily a small change. :\


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140512/5628d817/attachment.pgp 

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

[Oleksij Rempel]

Am 12.05.2014 15:11, schrieb Peter Stuge:
> Oleksij Rempel wrote:
>> 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.
> 
> True as that may be, if there is a bandwidth requirement for the
> interface to function correctly and the USB protocol being used does
> not guarantee that bandwidth (only control+interrupt transfers could
> do it in a meaningful way, and they are rather low bandwidth) then
> the USB stack would have to allow the driver to reserve bus time, and
> the driver would have to make a reservation to successfully handle
> worst-case load.
> 
> That's not neccessarily a small change. :\

I tested ath9k-htc on many different usb host controllers (not usb 1.1),
and noticed that most USB 2.0 controllers need some *msecs* to transfer
one Interrupt package to the adapter or at least to get ACK signal. USB
3.0 was transferring same package in some *usecs*. The results should be
similar for both controller, but it is not the case. Even different USB
2.0 controller was performing differently.

This big difference is responsible for extremely long scan time on
ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this
devices, reducing bandwidth and/or increasing transfer time for
Interrupt traffic will be critical.

Best indicator for this issue would be, disabling LED subsystem to get
better stability. What, according to Aaron, is the case.

-- 
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/86dc4932/attachment.pgp 

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

[Aaron Hamilton]

If one device has 7ms pings while the other consistently has 200 to 1500ms
pings, then wouldn't this rule out an interrupt issue? I'd assume if the
latency was caused by delays in interrupt processing, that both devices
would have similar latency problems?

The only difference I can see between the PC (no latency) and the embedded
device (high latency) is that the PC is also sending other traffic over the
interface while the embedded device is simply responding to pings. If it
helps, this is a station dump for the two devices:

Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC
inactive time: 35 ms
rx bytes: 345250
rx packets: 2488
tx bytes: 4568941
tx packets: 3258
tx retries: 0
tx failed: 0
signal:   -55 dBm
signal avg: -54 dBm
tx bitrate: 2.0 MBit/s
Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device
inactive time: 20136 ms
rx bytes: 40968
rx packets: 364
tx bytes: 18713
tx packets: 127
tx retries: 0
tx failed: 0
signal:   -52 dBm
signal avg: -52 dBm
tx bitrate: 2.0 MBit/s

I've also attached packet captures using tcpdump on the AP.

On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <linux@rempel-privat.de>wrote:

> Am 12.05.2014 15:11, schrieb Peter Stuge:
> > Oleksij Rempel wrote:
> >> 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.
> >
> > True as that may be, if there is a bandwidth requirement for the
> > interface to function correctly and the USB protocol being used does
> > not guarantee that bandwidth (only control+interrupt transfers could
> > do it in a meaningful way, and they are rather low bandwidth) then
> > the USB stack would have to allow the driver to reserve bus time, and
> > the driver would have to make a reservation to successfully handle
> > worst-case load.
> >
> > That's not neccessarily a small change. :\
>
> I tested ath9k-htc on many different usb host controllers (not usb 1.1),
> and noticed that most USB 2.0 controllers need some *msecs* to transfer
> one Interrupt package to the adapter or at least to get ACK signal. USB
> 3.0 was transferring same package in some *usecs*. The results should be
> similar for both controller, but it is not the case. Even different USB
> 2.0 controller was performing differently.
>
> This big difference is responsible for extremely long scan time on
> ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this
> devices, reducing bandwidth and/or increasing transfer time for
> Interrupt traffic will be critical.
>
> Best indicator for this issue would be, disabling LED subsystem to get
> better stability. What, according to Aaron, is the case.
>
> --
> Regards,
> Oleksij
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140527/f5335401/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defib_and_pc.pcap
Type: application/octet-stream
Size: 3697007 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140527/f5335401/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defib_only.pcap
Type: application/octet-stream
Size: 12228 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140527/f5335401/attachment-0003.obj 

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

[Oleksij Rempel]

Am 28.05.2014 07:36, schrieb Aaron Hamilton:
> If one device has 7ms pings while the other consistently has 200 to
> 1500ms pings, then wouldn't this rule out an interrupt issue? I'd assume
> if the latency was caused by delays in interrupt processing, that both
> devices would have similar latency problems?
>
> The only difference I can see between the PC (no latency) and the
> embedded device (high latency) is that the PC is also sending other
> traffic over the interface while the embedded device is simply
> responding to pings. If it helps, this is a station dump for the two
> devices:
> 
> Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC
> inactive time:35 ms
> rx bytes:345250
> rx packets:2488
> tx bytes:4568941
> tx packets:3258
> tx retries:0
> tx failed:0
> signal:  -55 dBm
> signal avg:-54 dBm
> tx bitrate:2.0 MBit/s
> Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device
> inactive time:20136 ms
> rx bytes:40968
> rx packets:364
> tx bytes:18713
> tx packets:127
> tx retries:0
> tx failed:0
> signal:  -52 dBm
> signal avg:-52 dBm
> tx bitrate:2.0 MBit/s
> 
> I've also attached packet captures using tcpdump on the AP.

IP level capture is not interesting. More interesting is radio level
capture - should be made in monitore mode with radiotap enabled. And
probably more important usb traffic capture - usbmonitore module should
be enabled.

> On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <linux@rempel-privat.de
> <mailto:linux@rempel-privat.de>> wrote:
> 
>     Am 12.05.2014 15:11, schrieb Peter Stuge:
>     > Oleksij Rempel wrote:
>     >> 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.
>     >
>     > True as that may be, if there is a bandwidth requirement for the
>     > interface to function correctly and the USB protocol being used does
>     > not guarantee that bandwidth (only control+interrupt transfers could
>     > do it in a meaningful way, and they are rather low bandwidth) then
>     > the USB stack would have to allow the driver to reserve bus time, and
>     > the driver would have to make a reservation to successfully handle
>     > worst-case load.
>     >
>     > That's not neccessarily a small change. :\
> 
>     I tested ath9k-htc on many different usb host controllers (not usb 1.1),
>     and noticed that most USB 2.0 controllers need some *msecs* to transfer
>     one Interrupt package to the adapter or at least to get ACK signal. USB
>     3.0 was transferring same package in some *usecs*. The results should be
>     similar for both controller, but it is not the case. Even different USB
>     2.0 controller was performing differently.
> 
>     This big difference is responsible for extremely long scan time on
>     ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this
>     devices, reducing bandwidth and/or increasing transfer time for
>     Interrupt traffic will be critical.
> 
>     Best indicator for this issue would be, disabling LED subsystem to get
>     better stability. What, according to Aaron, is the case.
> 
>     --
>     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/20140530/abe167c4/attachment.pgp 

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

[Aaron Hamilton]

I'll see if I can do some monitoring on the USB port. One thing I noticed:
If pinging from just the AP to the client device, the latency is high. But
as soon as pings are made from the client device to the AP, the latency
drops.

In case this is a kernel configuration issue, can someone point me to an
ARM kernel config they've used successfully with the ath9k_htc?

On Thu, May 29, 2014 at 9:21 PM, Oleksij Rempel <linux@rempel-privat.de>
wrote:

> Am 28.05.2014 07:36, schrieb Aaron Hamilton:
> > If one device has 7ms pings while the other consistently has 200 to
> > 1500ms pings, then wouldn't this rule out an interrupt issue? I'd assume
> > if the latency was caused by delays in interrupt processing, that both
> > devices would have similar latency problems?
> >
> > The only difference I can see between the PC (no latency) and the
> > embedded device (high latency) is that the PC is also sending other
> > traffic over the interface while the embedded device is simply
> > responding to pings. If it helps, this is a station dump for the two
> > devices:
> >
> > Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC
> > inactive time:35 ms
> > rx bytes:345250
> > rx packets:2488
> > tx bytes:4568941
> > tx packets:3258
> > tx retries:0
> > tx failed:0
> > signal:  -55 dBm
> > signal avg:-54 dBm
> > tx bitrate:2.0 MBit/s
> > Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device
> > inactive time:20136 ms
> > rx bytes:40968
> > rx packets:364
> > tx bytes:18713
> > tx packets:127
> > tx retries:0
> > tx failed:0
> > signal:  -52 dBm
> > signal avg:-52 dBm
> > tx bitrate:2.0 MBit/s
> >
> > I've also attached packet captures using tcpdump on the AP.
>
> IP level capture is not interesting. More interesting is radio level
> capture - should be made in monitore mode with radiotap enabled. And
> probably more important usb traffic capture - usbmonitore module should
> be enabled.
>
> > On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <linux@rempel-privat.de
> > <mailto:linux@rempel-privat.de>> wrote:
> >
> >     Am 12.05.2014 15:11, schrieb Peter Stuge:
> >     > Oleksij Rempel wrote:
> >     >> 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.
> >     >
> >     > True as that may be, if there is a bandwidth requirement for the
> >     > interface to function correctly and the USB protocol being used
> does
> >     > not guarantee that bandwidth (only control+interrupt transfers
> could
> >     > do it in a meaningful way, and they are rather low bandwidth) then
> >     > the USB stack would have to allow the driver to reserve bus time,
> and
> >     > the driver would have to make a reservation to successfully handle
> >     > worst-case load.
> >     >
> >     > That's not neccessarily a small change. :\
> >
> >     I tested ath9k-htc on many different usb host controllers (not usb
> 1.1),
> >     and noticed that most USB 2.0 controllers need some *msecs* to
> transfer
> >     one Interrupt package to the adapter or at least to get ACK signal.
> USB
> >     3.0 was transferring same package in some *usecs*. The results
> should be
> >     similar for both controller, but it is not the case. Even different
> USB
> >     2.0 controller was performing differently.
> >
> >     This big difference is responsible for extremely long scan time on
> >     ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on
> this
> >     devices, reducing bandwidth and/or increasing transfer time for
> >     Interrupt traffic will be critical.
> >
> >     Best indicator for this issue would be, disabling LED subsystem to
> get
> >     better stability. What, according to Aaron, is the case.
> >
> >     --
> >     Regards,
> >     Oleksij
> >
> >
> >
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
>
>
> --
> Regards,
> Oleksij
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140604/0a7115e1/attachment.htm 

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

[Aaron Hamilton]

I tried running ping tests again while capturing USB traffic, and in
doing so I set the hostapd beacon interval to roughly 5 seconds. While
doing this, I noticed the ping latency somehow correlates with the
beacon interval. Here's an example:

Ping from AP to client device with beacon interval ~5 seconds:

# ping 192.168.2.194
PING 192.168.2.194 (192.168.2.194): 56 data bytes
64 bytes from 192.168.2.194: seq=0 ttl=64 time=21549.225 ms
64 bytes from 192.168.2.194: seq=1 ttl=64 time=20535.767 ms
64 bytes from 192.168.2.194: seq=2 ttl=64 time=19535.339 ms
64 bytes from 192.168.2.194: seq=3 ttl=64 time=18528.473 ms
64 bytes from 192.168.2.194: seq=4 ttl=64 time=17517.608 ms
64 bytes from 192.168.2.194: seq=5 ttl=64 time=16510.559 ms
64 bytes from 192.168.2.194: seq=6 ttl=64 time=15508.789 ms
64 bytes from 192.168.2.194: seq=7 ttl=64 time=14502.075 ms
64 bytes from 192.168.2.194: seq=20 ttl=64 time=1377.839 ms
64 bytes from 192.168.2.194: seq=21 ttl=64 time=370.208 ms
64 bytes from 192.168.2.194: seq=22 ttl=64 time=189.728 ms
^C
--- 192.168.2.194 ping statistics ---
52 packets transmitted, 33 packets received, 36% packet loss
round-trip min/avg/max = 189.728/11757.569/21574.890 ms
#

Here are pings from the AP to the client with the beacon interval ~100ms:
# ping 192.168.2.194
PING 192.168.2.194 (192.168.2.194): 56 data bytes
64 bytes from 192.168.2.194: seq=0 ttl=64 time=347.351 ms
64 bytes from 192.168.2.194: seq=1 ttl=64 time=366.669 ms
64 bytes from 192.168.2.194: seq=2 ttl=64 time=380.005 ms
64 bytes from 192.168.2.194: seq=3 ttl=64 time=393.005 ms
64 bytes from 192.168.2.194: seq=4 ttl=64 time=221.405 ms
64 bytes from 192.168.2.194: seq=5 ttl=64 time=429.749 ms
64 bytes from 192.168.2.194: seq=6 ttl=64 time=453.522 ms
64 bytes from 192.168.2.194: seq=7 ttl=64 time=264.465 ms
64 bytes from 192.168.2.194: seq=8 ttl=64 time=72.845 ms
^C
--- 192.168.2.194 ping statistics ---
22 packets transmitted, 21 packets received, 4% packet loss
round-trip min/avg/max = 72.845/252.105/453.522 ms
#

When I ping from the client to the AP, the pings are consistently 10
to 15ms. Any idea why latency would be low in one direction, but not
the other?  And why it would correlate with the beacon interval?

If it helps, I've attached the USB capture from the first ping test.

On Wed, Jun 4, 2014 at 11:06 AM, Aaron Hamilton
<aaron@logicdatasystems.net> wrote:
>
> I'll see if I can do some monitoring on the USB port. One thing I noticed: If pinging from just the AP to the client device, the latency is high. But as soon as pings are made from the client device to the AP, the latency drops.
>
> In case this is a kernel configuration issue, can someone point me to an ARM kernel config they've used successfully with the ath9k_htc?
>
> On Thu, May 29, 2014 at 9:21 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>
>> Am 28.05.2014 07:36, schrieb Aaron Hamilton:
>> > If one device has 7ms pings while the other consistently has 200 to
>> > 1500ms pings, then wouldn't this rule out an interrupt issue? I'd assume
>> > if the latency was caused by delays in interrupt processing, that both
>> > devices would have similar latency problems?
>> >
>> > The only difference I can see between the PC (no latency) and the
>> > embedded device (high latency) is that the PC is also sending other
>> > traffic over the interface while the embedded device is simply
>> > responding to pings. If it helps, this is a station dump for the two
>> > devices:
>> >
>> > Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC
>> > inactive time:35 ms
>> > rx bytes:345250
>> > rx packets:2488
>> > tx bytes:4568941
>> > tx packets:3258
>> > tx retries:0
>> > tx failed:0
>> > signal:  -55 dBm
>> > signal avg:-54 dBm
>> > tx bitrate:2.0 MBit/s
>> > Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device
>> > inactive time:20136 ms
>> > rx bytes:40968
>> > rx packets:364
>> > tx bytes:18713
>> > tx packets:127
>> > tx retries:0
>> > tx failed:0
>> > signal:  -52 dBm
>> > signal avg:-52 dBm
>> > tx bitrate:2.0 MBit/s
>> >
>> > I've also attached packet captures using tcpdump on the AP.
>>
>> IP level capture is not interesting. More interesting is radio level
>> capture - should be made in monitore mode with radiotap enabled. And
>> probably more important usb traffic capture - usbmonitore module should
>> be enabled.
>>
>> > On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <linux@rempel-privat.de
>> > <mailto:linux@rempel-privat.de>> wrote:
>> >
>> >     Am 12.05.2014 15:11, schrieb Peter Stuge:
>> >     > Oleksij Rempel wrote:
>> >     >> 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.
>> >     >
>> >     > True as that may be, if there is a bandwidth requirement for the
>> >     > interface to function correctly and the USB protocol being used does
>> >     > not guarantee that bandwidth (only control+interrupt transfers could
>> >     > do it in a meaningful way, and they are rather low bandwidth) then
>> >     > the USB stack would have to allow the driver to reserve bus time, and
>> >     > the driver would have to make a reservation to successfully handle
>> >     > worst-case load.
>> >     >
>> >     > That's not neccessarily a small change. :\
>> >
>> >     I tested ath9k-htc on many different usb host controllers (not usb 1.1),
>> >     and noticed that most USB 2.0 controllers need some *msecs* to transfer
>> >     one Interrupt package to the adapter or at least to get ACK signal. USB
>> >     3.0 was transferring same package in some *usecs*. The results should be
>> >     similar for both controller, but it is not the case. Even different USB
>> >     2.0 controller was performing differently.
>> >
>> >     This big difference is responsible for extremely long scan time on
>> >     ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this
>> >     devices, reducing bandwidth and/or increasing transfer time for
>> >     Interrupt traffic will be critical.
>> >
>> >     Best indicator for this issue would be, disabling LED subsystem to get
>> >     better stability. What, according to Aaron, is the case.
>> >
>> >     --
>> >     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: usblog.pcap
Type: application/octet-stream
Size: 513892 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140605/09236c0c/attachment-0001.obj 

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

[Oleksij Rempel]

Am 06.06.2014 04:12, schrieb Aaron Hamilton:
> I tried running ping tests again while capturing USB traffic, and in
> doing so I set the hostapd beacon interval to roughly 5 seconds. While
> doing this, I noticed the ping latency somehow correlates with the
> beacon interval. Here's an example:
>
> Ping from AP to client device with beacon interval ~5 seconds:
> 
> # ping 192.168.2.194
> PING 192.168.2.194 (192.168.2.194): 56 data bytes
> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=21549.225 ms
> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=20535.767 ms
> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=19535.339 ms
> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=18528.473 ms
> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=17517.608 ms
> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=16510.559 ms
> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=15508.789 ms
> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=14502.075 ms
> 64 bytes from 192.168.2.194: seq=20 ttl=64 time=1377.839 ms
> 64 bytes from 192.168.2.194: seq=21 ttl=64 time=370.208 ms
> 64 bytes from 192.168.2.194: seq=22 ttl=64 time=189.728 ms
> ^C
> --- 192.168.2.194 ping statistics ---
> 52 packets transmitted, 33 packets received, 36% packet loss
> round-trip min/avg/max = 189.728/11757.569/21574.890 ms
> #
> 
> Here are pings from the AP to the client with the beacon interval ~100ms:
> # ping 192.168.2.194
> PING 192.168.2.194 (192.168.2.194): 56 data bytes
> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=347.351 ms
> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=366.669 ms
> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=380.005 ms
> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=393.005 ms
> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=221.405 ms
> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=429.749 ms
> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=453.522 ms
> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=264.465 ms
> 64 bytes from 192.168.2.194: seq=8 ttl=64 time=72.845 ms
> ^C
> --- 192.168.2.194 ping statistics ---
> 22 packets transmitted, 21 packets received, 4% packet loss
> round-trip min/avg/max = 72.845/252.105/453.522 ms
> #
> 
> When I ping from the client to the AP, the pings are consistently 10
> to 15ms. Any idea why latency would be low in one direction, but not
> the other? 

In this case latency = packet loss.

May be TTL time of AP is less then on Station? This is why all request
initiated from AP haw big packed loss. I mean dropped because of TTL.

> And why it would correlate with the beacon interval?

I have no idea.

> If it helps, I've attached the USB capture from the first ping test.

I was not able to identify ping packets from usb traffic. Please use
"pint -p aa IPADDR", it will provide easy searchable patter. To make
live easier, please provide captures of USB, network and WIFI (in
monitore mode) captures which was made at same time. Makes sure that the
time on all machines is synced. With this caps we should be able to
compare packages to see where are most packed dropped.

I noticed one issue in your usblog.pcap. There is a flood of incoming
usb packets. I forgot that WiFi interface is set to monitore mode to
provide AP functionality. It means, every thing what happens on that
channel is send over USB. In this case, USB1.1 with other concurrent
devices.

> On Wed, Jun 4, 2014 at 11:06 AM, Aaron Hamilton
> <aaron@logicdatasystems.net> wrote:
>>
>> I'll see if I can do some monitoring on the USB port. One thing I noticed: If pinging from just the AP to the client device, the latency is high. But as soon as pings are made from the client device to the AP, the latency drops.
>>
>> In case this is a kernel configuration issue, can someone point me to an ARM kernel config they've used successfully with the ath9k_htc?
>>
>> On Thu, May 29, 2014 at 9:21 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>
>>> Am 28.05.2014 07:36, schrieb Aaron Hamilton:
>>>> If one device has 7ms pings while the other consistently has 200 to
>>>> 1500ms pings, then wouldn't this rule out an interrupt issue? I'd assume
>>>> if the latency was caused by delays in interrupt processing, that both
>>>> devices would have similar latency problems?
>>>>
>>>> The only difference I can see between the PC (no latency) and the
>>>> embedded device (high latency) is that the PC is also sending other
>>>> traffic over the interface while the embedded device is simply
>>>> responding to pings. If it helps, this is a station dump for the two
>>>> devices:
>>>>
>>>> Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC
>>>> inactive time:35 ms
>>>> rx bytes:345250
>>>> rx packets:2488
>>>> tx bytes:4568941
>>>> tx packets:3258
>>>> tx retries:0
>>>> tx failed:0
>>>> signal:  -55 dBm
>>>> signal avg:-54 dBm
>>>> tx bitrate:2.0 MBit/s
>>>> Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device
>>>> inactive time:20136 ms
>>>> rx bytes:40968
>>>> rx packets:364
>>>> tx bytes:18713
>>>> tx packets:127
>>>> tx retries:0
>>>> tx failed:0
>>>> signal:  -52 dBm
>>>> signal avg:-52 dBm
>>>> tx bitrate:2.0 MBit/s
>>>>
>>>> I've also attached packet captures using tcpdump on the AP.
>>>
>>> IP level capture is not interesting. More interesting is radio level
>>> capture - should be made in monitore mode with radiotap enabled. And
>>> probably more important usb traffic capture - usbmonitore module should
>>> be enabled.
>>>
>>>> On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <linux@rempel-privat.de
>>>> <mailto:linux@rempel-privat.de>> wrote:
>>>>
>>>>     Am 12.05.2014 15:11, schrieb Peter Stuge:
>>>>     > Oleksij Rempel wrote:
>>>>     >> 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.
>>>>     >
>>>>     > True as that may be, if there is a bandwidth requirement for the
>>>>     > interface to function correctly and the USB protocol being used does
>>>>     > not guarantee that bandwidth (only control+interrupt transfers could
>>>>     > do it in a meaningful way, and they are rather low bandwidth) then
>>>>     > the USB stack would have to allow the driver to reserve bus time, and
>>>>     > the driver would have to make a reservation to successfully handle
>>>>     > worst-case load.
>>>>     >
>>>>     > That's not neccessarily a small change. :\
>>>>
>>>>     I tested ath9k-htc on many different usb host controllers (not usb 1.1),
>>>>     and noticed that most USB 2.0 controllers need some *msecs* to transfer
>>>>     one Interrupt package to the adapter or at least to get ACK signal. USB
>>>>     3.0 was transferring same package in some *usecs*. The results should be
>>>>     similar for both controller, but it is not the case. Even different USB
>>>>     2.0 controller was performing differently.
>>>>
>>>>     This big difference is responsible for extremely long scan time on
>>>>     ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this
>>>>     devices, reducing bandwidth and/or increasing transfer time for
>>>>     Interrupt traffic will be critical.
>>>>
>>>>     Best indicator for this issue would be, disabling LED subsystem to get
>>>>     better stability. What, according to Aaron, is the case.
>>>>
>>>>     --
>>>>     Regards,
>>>>     Oleksij
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>
>>>
>>>
>>> --
>>> 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/20140606/ea132210/attachment.pgp 

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

[Aaron Hamilton]

Just tried it with an rt73 module and the behavior is the same.
Appears the outbound traffic is getting queued up, then flushed at the
beacon interval.

If I initiate pings from the client to the AP (while still pinging
from AP to client), the client receives responses back consistently in
15ms. Also, the ping latency from the AP to the client starts dropping
and continues down until it reaches 7ms or so.

Looks like a transmit queue somewhere is not getting processed without
either the beacon, or rx traffic?  I'll work on getting a cleaner
capture with more info. In the mean time, is there a high level
overview of the interaction between the USB, mac80211, and network
systems somewhere? Or if someone knows the relevant code segments I
should look at, then hopefully I could start narrowing things down
further.

Thanks Oleksij and others for the assistance thus far. Feel like I'm
much closer to putting this thing to rest.

On Fri, Jun 6, 2014 at 12:52 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 06.06.2014 04:12, schrieb Aaron Hamilton:
>> I tried running ping tests again while capturing USB traffic, and in
>> doing so I set the hostapd beacon interval to roughly 5 seconds. While
>> doing this, I noticed the ping latency somehow correlates with the
>> beacon interval. Here's an example:
>>
>> Ping from AP to client device with beacon interval ~5 seconds:
>>
>> # ping 192.168.2.194
>> PING 192.168.2.194 (192.168.2.194): 56 data bytes
>> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=21549.225 ms
>> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=20535.767 ms
>> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=19535.339 ms
>> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=18528.473 ms
>> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=17517.608 ms
>> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=16510.559 ms
>> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=15508.789 ms
>> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=14502.075 ms
>> 64 bytes from 192.168.2.194: seq=20 ttl=64 time=1377.839 ms
>> 64 bytes from 192.168.2.194: seq=21 ttl=64 time=370.208 ms
>> 64 bytes from 192.168.2.194: seq=22 ttl=64 time=189.728 ms
>> ^C
>> --- 192.168.2.194 ping statistics ---
>> 52 packets transmitted, 33 packets received, 36% packet loss
>> round-trip min/avg/max = 189.728/11757.569/21574.890 ms
>> #
>>
>> Here are pings from the AP to the client with the beacon interval ~100ms:
>> # ping 192.168.2.194
>> PING 192.168.2.194 (192.168.2.194): 56 data bytes
>> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=347.351 ms
>> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=366.669 ms
>> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=380.005 ms
>> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=393.005 ms
>> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=221.405 ms
>> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=429.749 ms
>> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=453.522 ms
>> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=264.465 ms
>> 64 bytes from 192.168.2.194: seq=8 ttl=64 time=72.845 ms
>> ^C
>> --- 192.168.2.194 ping statistics ---
>> 22 packets transmitted, 21 packets received, 4% packet loss
>> round-trip min/avg/max = 72.845/252.105/453.522 ms
>> #
>>
>> When I ping from the client to the AP, the pings are consistently 10
>> to 15ms. Any idea why latency would be low in one direction, but not
>> the other?
>
> In this case latency = packet loss.
>
> May be TTL time of AP is less then on Station? This is why all request
> initiated from AP haw big packed loss. I mean dropped because of TTL.
>
>> And why it would correlate with the beacon interval?
>
> I have no idea.
>
>> If it helps, I've attached the USB capture from the first ping test.
>
> I was not able to identify ping packets from usb traffic. Please use
> "pint -p aa IPADDR", it will provide easy searchable patter. To make
> live easier, please provide captures of USB, network and WIFI (in
> monitore mode) captures which was made at same time. Makes sure that the
> time on all machines is synced. With this caps we should be able to
> compare packages to see where are most packed dropped.
>
> I noticed one issue in your usblog.pcap. There is a flood of incoming
> usb packets. I forgot that WiFi interface is set to monitore mode to
> provide AP functionality. It means, every thing what happens on that
> channel is send over USB. In this case, USB1.1 with other concurrent
> devices.
>
>> On Wed, Jun 4, 2014 at 11:06 AM, Aaron Hamilton
>> <aaron@logicdatasystems.net> wrote:
>>>
>>> I'll see if I can do some monitoring on the USB port. One thing I noticed: If pinging from just the AP to the client device, the latency is high. But as soon as pings are made from the client device to the AP, the latency drops.
>>>
>>> In case this is a kernel configuration issue, can someone point me to an ARM kernel config they've used successfully with the ath9k_htc?
>>>
>>> On Thu, May 29, 2014 at 9:21 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>
>>>> Am 28.05.2014 07:36, schrieb Aaron Hamilton:
>>>>> If one device has 7ms pings while the other consistently has 200 to
>>>>> 1500ms pings, then wouldn't this rule out an interrupt issue? I'd assume
>>>>> if the latency was caused by delays in interrupt processing, that both
>>>>> devices would have similar latency problems?
>>>>>
>>>>> The only difference I can see between the PC (no latency) and the
>>>>> embedded device (high latency) is that the PC is also sending other
>>>>> traffic over the interface while the embedded device is simply
>>>>> responding to pings. If it helps, this is a station dump for the two
>>>>> devices:
>>>>>
>>>>> Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC
>>>>> inactive time:35 ms
>>>>> rx bytes:345250
>>>>> rx packets:2488
>>>>> tx bytes:4568941
>>>>> tx packets:3258
>>>>> tx retries:0
>>>>> tx failed:0
>>>>> signal:  -55 dBm
>>>>> signal avg:-54 dBm
>>>>> tx bitrate:2.0 MBit/s
>>>>> Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device
>>>>> inactive time:20136 ms
>>>>> rx bytes:40968
>>>>> rx packets:364
>>>>> tx bytes:18713
>>>>> tx packets:127
>>>>> tx retries:0
>>>>> tx failed:0
>>>>> signal:  -52 dBm
>>>>> signal avg:-52 dBm
>>>>> tx bitrate:2.0 MBit/s
>>>>>
>>>>> I've also attached packet captures using tcpdump on the AP.
>>>>
>>>> IP level capture is not interesting. More interesting is radio level
>>>> capture - should be made in monitore mode with radiotap enabled. And
>>>> probably more important usb traffic capture - usbmonitore module should
>>>> be enabled.
>>>>
>>>>> On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <linux@rempel-privat.de
>>>>> <mailto:linux@rempel-privat.de>> wrote:
>>>>>
>>>>>     Am 12.05.2014 15:11, schrieb Peter Stuge:
>>>>>     > Oleksij Rempel wrote:
>>>>>     >> 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.
>>>>>     >
>>>>>     > True as that may be, if there is a bandwidth requirement for the
>>>>>     > interface to function correctly and the USB protocol being used does
>>>>>     > not guarantee that bandwidth (only control+interrupt transfers could
>>>>>     > do it in a meaningful way, and they are rather low bandwidth) then
>>>>>     > the USB stack would have to allow the driver to reserve bus time, and
>>>>>     > the driver would have to make a reservation to successfully handle
>>>>>     > worst-case load.
>>>>>     >
>>>>>     > That's not neccessarily a small change. :\
>>>>>
>>>>>     I tested ath9k-htc on many different usb host controllers (not usb 1.1),
>>>>>     and noticed that most USB 2.0 controllers need some *msecs* to transfer
>>>>>     one Interrupt package to the adapter or at least to get ACK signal. USB
>>>>>     3.0 was transferring same package in some *usecs*. The results should be
>>>>>     similar for both controller, but it is not the case. Even different USB
>>>>>     2.0 controller was performing differently.
>>>>>
>>>>>     This big difference is responsible for extremely long scan time on
>>>>>     ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this
>>>>>     devices, reducing bandwidth and/or increasing transfer time for
>>>>>     Interrupt traffic will be critical.
>>>>>
>>>>>     Best indicator for this issue would be, disabling LED subsystem to get
>>>>>     better stability. What, according to Aaron, is the case.
>>>>>
>>>>>     --
>>>>>     Regards,
>>>>>     Oleksij
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ath9k-devel mailing list
>>>>> ath9k-devel at lists.ath9k.org
>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Oleksij
>>>>
>>>
>
>
> --
> Regards,
> Oleksij
>

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

[Gui Iribarren]

On 06/06/14 08:06, Aaron Hamilton wrote:
> Just tried it with an rt73 module and the behavior is the same.
> Appears the outbound traffic is getting queued up, then flushed at the
> beacon interval.

Could it be that power saving features are playing a part here?

As much as i understand (really just a little bit), a station sleeps
during the beacon interval if there's no traffic queued up for them, and
wakes up just in time for the next beacon, to check the relevant bits
and decide to stay awake (if there's traffic) or to sleep again.
In addition, not all beacons need to carry those "there's traffic for
you" bits at all.

so maybe in your scenario, those indicator bits are getting sent every 4
beacons, and traffic for that station is getting queued up for ~400ms
(with BI=100ms) or ~20000ms (BI=5000ms)

> If I initiate pings from the client to the AP (while still pinging
> from AP to client), the client receives responses back consistently in
> 15ms. Also, the ping latency from the AP to the client starts dropping
> and continues down until it reaches 7ms or so.

in my hypothesis, if the client is generating the traffic, the previous
power saving scheme is not taken into account (the radio wakes up right
away and flushes the queue). In addition, it will listen to AP->client
packets, dropping the latency since it's not sleeping at all.

Just a wild guess (haven't followed the thread thoroughly, maybe
powersaving is disabled and my hypothesis is pointless :P)

gui

> 
> Looks like a transmit queue somewhere is not getting processed without
> either the beacon, or rx traffic?  I'll work on getting a cleaner
> capture with more info. In the mean time, is there a high level
> overview of the interaction between the USB, mac80211, and network
> systems somewhere? Or if someone knows the relevant code segments I
> should look at, then hopefully I could start narrowing things down
> further.
> 
> Thanks Oleksij and others for the assistance thus far. Feel like I'm
> much closer to putting this thing to rest.
> 
> On Fri, Jun 6, 2014 at 12:52 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 06.06.2014 04:12, schrieb Aaron Hamilton:
>>> I tried running ping tests again while capturing USB traffic, and in
>>> doing so I set the hostapd beacon interval to roughly 5 seconds. While
>>> doing this, I noticed the ping latency somehow correlates with the
>>> beacon interval. Here's an example:
>>>
>>> Ping from AP to client device with beacon interval ~5 seconds:
>>>
>>> # ping 192.168.2.194
>>> PING 192.168.2.194 (192.168.2.194): 56 data bytes
>>> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=21549.225 ms
>>> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=20535.767 ms
>>> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=19535.339 ms
>>> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=18528.473 ms
>>> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=17517.608 ms
>>> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=16510.559 ms
>>> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=15508.789 ms
>>> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=14502.075 ms
>>> 64 bytes from 192.168.2.194: seq=20 ttl=64 time=1377.839 ms
>>> 64 bytes from 192.168.2.194: seq=21 ttl=64 time=370.208 ms
>>> 64 bytes from 192.168.2.194: seq=22 ttl=64 time=189.728 ms
>>> ^C
>>> --- 192.168.2.194 ping statistics ---
>>> 52 packets transmitted, 33 packets received, 36% packet loss
>>> round-trip min/avg/max = 189.728/11757.569/21574.890 ms
>>> #
>>>
>>> Here are pings from the AP to the client with the beacon interval ~100ms:
>>> # ping 192.168.2.194
>>> PING 192.168.2.194 (192.168.2.194): 56 data bytes
>>> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=347.351 ms
>>> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=366.669 ms
>>> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=380.005 ms
>>> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=393.005 ms
>>> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=221.405 ms
>>> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=429.749 ms
>>> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=453.522 ms
>>> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=264.465 ms
>>> 64 bytes from 192.168.2.194: seq=8 ttl=64 time=72.845 ms
>>> ^C
>>> --- 192.168.2.194 ping statistics ---
>>> 22 packets transmitted, 21 packets received, 4% packet loss
>>> round-trip min/avg/max = 72.845/252.105/453.522 ms
>>> #
>>>
>>> When I ping from the client to the AP, the pings are consistently 10
>>> to 15ms. Any idea why latency would be low in one direction, but not
>>> the other?
>>
>> In this case latency = packet loss.
>>
>> May be TTL time of AP is less then on Station? This is why all request
>> initiated from AP haw big packed loss. I mean dropped because of TTL.
>>
>>> And why it would correlate with the beacon interval?
>>
>> I have no idea.
>>
>>> If it helps, I've attached the USB capture from the first ping test.
>>
>> I was not able to identify ping packets from usb traffic. Please use
>> "pint -p aa IPADDR", it will provide easy searchable patter. To make
>> live easier, please provide captures of USB, network and WIFI (in
>> monitore mode) captures which was made at same time. Makes sure that the
>> time on all machines is synced. With this caps we should be able to
>> compare packages to see where are most packed dropped.
>>
>> I noticed one issue in your usblog.pcap. There is a flood of incoming
>> usb packets. I forgot that WiFi interface is set to monitore mode to
>> provide AP functionality. It means, every thing what happens on that
>> channel is send over USB. In this case, USB1.1 with other concurrent
>> devices.
>>
>>> On Wed, Jun 4, 2014 at 11:06 AM, Aaron Hamilton
>>> <aaron@logicdatasystems.net> wrote:
>>>>
>>>> I'll see if I can do some monitoring on the USB port. One thing I noticed: If pinging from just the AP to the client device, the latency is high. But as soon as pings are made from the client device to the AP, the latency drops.
>>>>
>>>> In case this is a kernel configuration issue, can someone point me to an ARM kernel config they've used successfully with the ath9k_htc?
>>>>
>>>> On Thu, May 29, 2014 at 9:21 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>>
>>>>> Am 28.05.2014 07:36, schrieb Aaron Hamilton:
>>>>>> If one device has 7ms pings while the other consistently has 200 to
>>>>>> 1500ms pings, then wouldn't this rule out an interrupt issue? I'd assume
>>>>>> if the latency was caused by delays in interrupt processing, that both
>>>>>> devices would have similar latency problems?
>>>>>>
>>>>>> The only difference I can see between the PC (no latency) and the
>>>>>> embedded device (high latency) is that the PC is also sending other
>>>>>> traffic over the interface while the embedded device is simply
>>>>>> responding to pings. If it helps, this is a station dump for the two
>>>>>> devices:
>>>>>>
>>>>>> Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC
>>>>>> inactive time:35 ms
>>>>>> rx bytes:345250
>>>>>> rx packets:2488
>>>>>> tx bytes:4568941
>>>>>> tx packets:3258
>>>>>> tx retries:0
>>>>>> tx failed:0
>>>>>> signal:  -55 dBm
>>>>>> signal avg:-54 dBm
>>>>>> tx bitrate:2.0 MBit/s
>>>>>> Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device
>>>>>> inactive time:20136 ms
>>>>>> rx bytes:40968
>>>>>> rx packets:364
>>>>>> tx bytes:18713
>>>>>> tx packets:127
>>>>>> tx retries:0
>>>>>> tx failed:0
>>>>>> signal:  -52 dBm
>>>>>> signal avg:-52 dBm
>>>>>> tx bitrate:2.0 MBit/s
>>>>>>
>>>>>> I've also attached packet captures using tcpdump on the AP.
>>>>>
>>>>> IP level capture is not interesting. More interesting is radio level
>>>>> capture - should be made in monitore mode with radiotap enabled. And
>>>>> probably more important usb traffic capture - usbmonitore module should
>>>>> be enabled.
>>>>>
>>>>>> On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <linux@rempel-privat.de
>>>>>> <mailto:linux@rempel-privat.de>> wrote:
>>>>>>
>>>>>>     Am 12.05.2014 15:11, schrieb Peter Stuge:
>>>>>>     > Oleksij Rempel wrote:
>>>>>>     >> 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.
>>>>>>     >
>>>>>>     > True as that may be, if there is a bandwidth requirement for the
>>>>>>     > interface to function correctly and the USB protocol being used does
>>>>>>     > not guarantee that bandwidth (only control+interrupt transfers could
>>>>>>     > do it in a meaningful way, and they are rather low bandwidth) then
>>>>>>     > the USB stack would have to allow the driver to reserve bus time, and
>>>>>>     > the driver would have to make a reservation to successfully handle
>>>>>>     > worst-case load.
>>>>>>     >
>>>>>>     > That's not neccessarily a small change. :\
>>>>>>
>>>>>>     I tested ath9k-htc on many different usb host controllers (not usb 1.1),
>>>>>>     and noticed that most USB 2.0 controllers need some *msecs* to transfer
>>>>>>     one Interrupt package to the adapter or at least to get ACK signal. USB
>>>>>>     3.0 was transferring same package in some *usecs*. The results should be
>>>>>>     similar for both controller, but it is not the case. Even different USB
>>>>>>     2.0 controller was performing differently.
>>>>>>
>>>>>>     This big difference is responsible for extremely long scan time on
>>>>>>     ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this
>>>>>>     devices, reducing bandwidth and/or increasing transfer time for
>>>>>>     Interrupt traffic will be critical.
>>>>>>
>>>>>>     Best indicator for this issue would be, disabling LED subsystem to get
>>>>>>     better stability. What, according to Aaron, is the case.
>>>>>>
>>>>>>     --
>>>>>>     Regards,
>>>>>>     Oleksij
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ath9k-devel mailing list
>>>>>> ath9k-devel at lists.ath9k.org
>>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Oleksij
>>>>>
>>>>
>>
>>
>> --
>> Regards,
>> Oleksij
>>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 

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

[Gui Iribarren]

On 06/06/14 08:06, Aaron Hamilton wrote:
> Just tried it with an rt73 module and the behavior is the same.
> Appears the outbound traffic is getting queued up, then flushed at the
> beacon interval.

Could it be that power saving features are playing a part here?

As much as i understand (really just a little bit), a station sleeps
during the beacon interval if there's no traffic queued up for them, and
wakes up just in time for the next beacon, to check the relevant bits
and decide to stay awake (if there's traffic) or to sleep again.
In addition, not all beacons need to carry those "there's traffic for
you" bits at all.

so maybe in your scenario, those indicator bits are getting sent every 4
beacons, and traffic for that station is getting queued up for ~400ms
(with BI=100ms) or ~20000ms (BI=5000ms)

> If I initiate pings from the client to the AP (while still pinging
> from AP to client), the client receives responses back consistently in
> 15ms. Also, the ping latency from the AP to the client starts dropping
> and continues down until it reaches 7ms or so.

in my hypothesis, if the client is generating the traffic, the previous
power saving scheme is not taken into account (the radio wakes up right
away and flushes the queue). In addition, it will listen to AP->client
packets, dropping the latency since it's not sleeping at all.

Just a wild guess (haven't followed the thread thoroughly, maybe
powersaving is disabled and my hypothesis is pointless :P)

gui

> 
> Looks like a transmit queue somewhere is not getting processed without
> either the beacon, or rx traffic?  I'll work on getting a cleaner
> capture with more info. In the mean time, is there a high level
> overview of the interaction between the USB, mac80211, and network
> systems somewhere? Or if someone knows the relevant code segments I
> should look at, then hopefully I could start narrowing things down
> further.
> 
> Thanks Oleksij and others for the assistance thus far. Feel like I'm
> much closer to putting this thing to rest.
> 
> On Fri, Jun 6, 2014 at 12:52 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 06.06.2014 04:12, schrieb Aaron Hamilton:
>>> I tried running ping tests again while capturing USB traffic, and in
>>> doing so I set the hostapd beacon interval to roughly 5 seconds. While
>>> doing this, I noticed the ping latency somehow correlates with the
>>> beacon interval. Here's an example:
>>>
>>> Ping from AP to client device with beacon interval ~5 seconds:
>>>
>>> # ping 192.168.2.194
>>> PING 192.168.2.194 (192.168.2.194): 56 data bytes
>>> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=21549.225 ms
>>> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=20535.767 ms
>>> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=19535.339 ms
>>> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=18528.473 ms
>>> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=17517.608 ms
>>> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=16510.559 ms
>>> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=15508.789 ms
>>> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=14502.075 ms
>>> 64 bytes from 192.168.2.194: seq=20 ttl=64 time=1377.839 ms
>>> 64 bytes from 192.168.2.194: seq=21 ttl=64 time=370.208 ms
>>> 64 bytes from 192.168.2.194: seq=22 ttl=64 time=189.728 ms
>>> ^C
>>> --- 192.168.2.194 ping statistics ---
>>> 52 packets transmitted, 33 packets received, 36% packet loss
>>> round-trip min/avg/max = 189.728/11757.569/21574.890 ms
>>> #
>>>
>>> Here are pings from the AP to the client with the beacon interval ~100ms:
>>> # ping 192.168.2.194
>>> PING 192.168.2.194 (192.168.2.194): 56 data bytes
>>> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=347.351 ms
>>> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=366.669 ms
>>> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=380.005 ms
>>> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=393.005 ms
>>> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=221.405 ms
>>> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=429.749 ms
>>> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=453.522 ms
>>> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=264.465 ms
>>> 64 bytes from 192.168.2.194: seq=8 ttl=64 time=72.845 ms
>>> ^C
>>> --- 192.168.2.194 ping statistics ---
>>> 22 packets transmitted, 21 packets received, 4% packet loss
>>> round-trip min/avg/max = 72.845/252.105/453.522 ms
>>> #
>>>
>>> When I ping from the client to the AP, the pings are consistently 10
>>> to 15ms. Any idea why latency would be low in one direction, but not
>>> the other?
>>
>> In this case latency = packet loss.
>>
>> May be TTL time of AP is less then on Station? This is why all request
>> initiated from AP haw big packed loss. I mean dropped because of TTL.
>>
>>> And why it would correlate with the beacon interval?
>>
>> I have no idea.
>>
>>> If it helps, I've attached the USB capture from the first ping test.
>>
>> I was not able to identify ping packets from usb traffic. Please use
>> "pint -p aa IPADDR", it will provide easy searchable patter. To make
>> live easier, please provide captures of USB, network and WIFI (in
>> monitore mode) captures which was made at same time. Makes sure that the
>> time on all machines is synced. With this caps we should be able to
>> compare packages to see where are most packed dropped.
>>
>> I noticed one issue in your usblog.pcap. There is a flood of incoming
>> usb packets. I forgot that WiFi interface is set to monitore mode to
>> provide AP functionality. It means, every thing what happens on that
>> channel is send over USB. In this case, USB1.1 with other concurrent
>> devices.
>>
>>> On Wed, Jun 4, 2014 at 11:06 AM, Aaron Hamilton
>>> <aaron@logicdatasystems.net> wrote:
>>>>
>>>> I'll see if I can do some monitoring on the USB port. One thing I noticed: If pinging from just the AP to the client device, the latency is high. But as soon as pings are made from the client device to the AP, the latency drops.
>>>>
>>>> In case this is a kernel configuration issue, can someone point me to an ARM kernel config they've used successfully with the ath9k_htc?
>>>>
>>>> On Thu, May 29, 2014 at 9:21 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>>
>>>>> Am 28.05.2014 07:36, schrieb Aaron Hamilton:
>>>>>> If one device has 7ms pings while the other consistently has 200 to
>>>>>> 1500ms pings, then wouldn't this rule out an interrupt issue? I'd assume
>>>>>> if the latency was caused by delays in interrupt processing, that both
>>>>>> devices would have similar latency problems?
>>>>>>
>>>>>> The only difference I can see between the PC (no latency) and the
>>>>>> embedded device (high latency) is that the PC is also sending other
>>>>>> traffic over the interface while the embedded device is simply
>>>>>> responding to pings. If it helps, this is a station dump for the two
>>>>>> devices:
>>>>>>
>>>>>> Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC
>>>>>> inactive time:35 ms
>>>>>> rx bytes:345250
>>>>>> rx packets:2488
>>>>>> tx bytes:4568941
>>>>>> tx packets:3258
>>>>>> tx retries:0
>>>>>> tx failed:0
>>>>>> signal:  -55 dBm
>>>>>> signal avg:-54 dBm
>>>>>> tx bitrate:2.0 MBit/s
>>>>>> Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device
>>>>>> inactive time:20136 ms
>>>>>> rx bytes:40968
>>>>>> rx packets:364
>>>>>> tx bytes:18713
>>>>>> tx packets:127
>>>>>> tx retries:0
>>>>>> tx failed:0
>>>>>> signal:  -52 dBm
>>>>>> signal avg:-52 dBm
>>>>>> tx bitrate:2.0 MBit/s
>>>>>>
>>>>>> I've also attached packet captures using tcpdump on the AP.
>>>>>
>>>>> IP level capture is not interesting. More interesting is radio level
>>>>> capture - should be made in monitore mode with radiotap enabled. And
>>>>> probably more important usb traffic capture - usbmonitore module should
>>>>> be enabled.
>>>>>
>>>>>> On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <linux@rempel-privat.de
>>>>>> <mailto:linux@rempel-privat.de>> wrote:
>>>>>>
>>>>>>     Am 12.05.2014 15:11, schrieb Peter Stuge:
>>>>>>     > Oleksij Rempel wrote:
>>>>>>     >> 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.
>>>>>>     >
>>>>>>     > True as that may be, if there is a bandwidth requirement for the
>>>>>>     > interface to function correctly and the USB protocol being used does
>>>>>>     > not guarantee that bandwidth (only control+interrupt transfers could
>>>>>>     > do it in a meaningful way, and they are rather low bandwidth) then
>>>>>>     > the USB stack would have to allow the driver to reserve bus time, and
>>>>>>     > the driver would have to make a reservation to successfully handle
>>>>>>     > worst-case load.
>>>>>>     >
>>>>>>     > That's not neccessarily a small change. :\
>>>>>>
>>>>>>     I tested ath9k-htc on many different usb host controllers (not usb 1.1),
>>>>>>     and noticed that most USB 2.0 controllers need some *msecs* to transfer
>>>>>>     one Interrupt package to the adapter or at least to get ACK signal. USB
>>>>>>     3.0 was transferring same package in some *usecs*. The results should be
>>>>>>     similar for both controller, but it is not the case. Even different USB
>>>>>>     2.0 controller was performing differently.
>>>>>>
>>>>>>     This big difference is responsible for extremely long scan time on
>>>>>>     ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this
>>>>>>     devices, reducing bandwidth and/or increasing transfer time for
>>>>>>     Interrupt traffic will be critical.
>>>>>>
>>>>>>     Best indicator for this issue would be, disabling LED subsystem to get
>>>>>>     better stability. What, according to Aaron, is the case.
>>>>>>
>>>>>>     --
>>>>>>     Regards,
>>>>>>     Oleksij
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ath9k-devel mailing list
>>>>>> ath9k-devel at lists.ath9k.org
>>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Oleksij
>>>>>
>>>>
>>
>>
>> --
>> Regards,
>> Oleksij
>>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>