Re: 11n support for athn(4)

[Stuart Henderson]

On 2017/03/07 10:40, Stefan Sperling wrote:
> On Tue, Mar 07, 2017 at 07:12:43AM +0200, Timo Myyrä wrote:
> > Can OpenBSD AP work on both frequencies at the same time or is that 
> > something
> > not yet supported?
> 
> No, that won't work. The hardware can do 'multi-BSS' which we don't
> yet support but I believe that just means running separate SSIDs in
> parallel on the same channel.

That's correct. The hardware can also do client + hostap simultaenously,
but again only on the same channel.

APs which support simultaneous dual-band have two radios.

Re: 11n support for athn(4)

[Stefan Sperling]

On Tue, Mar 07, 2017 at 07:12:43AM +0200, Timo Myyrä wrote:
> I didn't think it would improve things yet but I had the antenna so I'd figure
> I'd stick it in the AP while I'm tweaking it anyway.
> 
> Speaking of 5Ghz, my AP uses athn chipset AR9280 which seems to support 2.4Ghz
> and 5Ghz. Can I use 5Ghz with my AP to see which devices would break after 
> such
> transition. I guess I would need to get 5Ghz antenna and just stick that to my
> AP?

Don't worry about antennas.
Just pick any channel >= 36 in the list shown by 'ifconfig athn0 chan'.
You can run a scan to see which of these channels are already occupied.

On my 9280 I have 24 5GHz channels to choose from.
Some 5GHz client devices may be limited to a subset of these, but all
devices should support channels 36-48.

See 
https://en.wikipedia.org/wiki/List_of_WLAN_channels#5.C2.A0GHz_.28802.11a.2Fh.2Fj.2Fn.2Fac.29.5B18.5D
for regulatory aspects. Channels marked "DFS" should be avoided because
OpenBSD has no support for DFS yet. There is nothing technical preventing
their use, it may just not be perfectly legal to operate such an AP.
The driver sticks to TX power limits configured in hardware so indoor
use of DFS channels should be reasonably safe if it can't be avoided.
My impression is that, in practice, these rules are taken very seriously
only when running long-haul wifi links across public space.

> Can OpenBSD AP work on both frequencies at the same time or is that something
> not yet supported?

No, that won't work. The hardware can do 'multi-BSS' which we don't
yet support but I believe that just means running separate SSIDs in
parallel on the same channel.

I have two firewalls in a carp setup and run a 5GHz AP on one and a 2GHz
on the other.

Re: 11n support for athn(4)

[Timo Myyrä]

Stefan Sperling  writes:

> On Mon, Mar 06, 2017 at 07:36:21AM +0200, Timo Myyrä wrote:
>
>> Did some tcpbench testing and got following results:
>> Each test run with: tcpbench -s || tcpbench -t 15  commands.
>> Host AP: apu 2b4 with athn, client = thinkpad t430s with iwn (OpenBSD)
>> 
>> channel 9 running old snapshot etc:
>> 11n client -> server ~4, server -> ~0,
>> 11g client -> server ~16, server -> client ~0-6mbs
>> ---
>> updated to new snapshot: OpenBSD 6.0-current (GENERIC.MP) #206: Sat Mar  4 
>> 09:22:00 MST 2017
>> = added another antenna, moved the ap to better spot, switched old ap off, 
>> changed channel to 11
>> 11n client -> server: ~6mbps, server -> client ~0.2mbps
>> 11g client -> server: ~7mbps, server -> client ~3mbps
>> 
>> ---
>> switch to channel 3:
>> 11n client -> server: ~7mbps, server -> client: ~0-5mbps
>> 11g client -> server: 16mbps, server -> client: ~5mbps
>> 
>> ---
>> applied dyn rts patch:
>> 11n client -> server: 4-7mbps, server -> client 0.2-5.5mbps
>> 11g client -> server: ~4mbps, server -> client: ~5.5mbps
>
> What made 11n go down from 16 to 4?
> 11g is not affected by this patch so something else affected 11g.
> Could it be other networks on overlapping channels?

Yeah, I have around ten wireless networks around. Some seem to be mobile AP
which come and go. 

>  
> To tell whether the patch has any effect in your case I would like to
> know which HT protection setting your AP is using.
>
> Find a snapshot dated a bit after 2017/03/04 10:51:20 MST, or make sure 
> tcpdump
> sources are -current and rebuild and install tcpdump. Associate to the AP,
> and run: tcpdump -n -i iwn0 -y IEEE802_11_RADIO -s 4096 -v -l | grep beacon
> and in htop=<...> look for 'htprot'. If it shows 'htprot none' then dynamic
> RTS is used in 11n mode (i.e. my patch will switch RTS on/off as needed).
> Otherwise, you have some pre-11n devices in your environment so RTS must
> always be enabled and my patch makes no difference.

06:59:51.809091 802.11 flags=0<>: beacon, 
caps=2061, ssid (wifee), rates 1M* 
2M* 5M* 11M* 6M 9M 12M 18M, ds (chan 6), tim 0x0001, xrates 24M 36M 48M 
54M, rsn 0x010fac04010fac04010fac02, htcaps=<20MHz,A-MSDU 
3839,A-MPDU max 8191,RxMCS 0x>, htop=<20MHz chan 6,STA 
chanw 20MHz,htprot non-HT-mixed,basic MCS set 0x>, vendor 
0x0050f202010103a427a442435e0062322f00, 

So I guess its pre-11n devices somewhere ruining my day. 

>
> Note that the iwn(4) driver does not yet support MIMO in 11n mode.
> Once it does, 11n should become faster than 11g. I have seen an iwm(4) client
> which supports MIMO max out at 21 Mbps tcpbench towards my athn(4) AP, on a
> 5GHz channel with 'htprot none'.
> Unfortunately, tcpbench in the other direction (athn -> iwm) peaks at 10 Mbps.
> There is plenty of room for improvement.
>

I didn't think it would improve things yet but I had the antenna so I'd figure
I'd stick it in the AP while I'm tweaking it anyway.

Speaking of 5Ghz, my AP uses athn chipset AR9280 which seems to support 2.4Ghz
and 5Ghz. Can I use 5Ghz with my AP to see which devices would break after such
transition. I guess I would need to get 5Ghz antenna and just stick that to my
AP?
Can OpenBSD AP work on both frequencies at the same time or is that something
not yet supported?

>> At least what pops up in the measurements is that 11g gives more stable
>> behaviour. 11n speed seems to vary a lot in that 15s test compared to 11g.
>
> This could be explained by differences in rate scaling algorithms.
> In -current 11g uses AMRR, and 11n mode uses MiRa which jumps around more.
> In 6.0 everything used AMRR so a comparing how a 6.0 iwn client performs
> in 11n mode would be useful (you could e.g. install 6.0 to a USB stick
> and boot from it for running a speed test).

I have only very limited observations, like typing commands via ssh has usually
lag with 11n and works pretty smoothly on 11g.

timo

Re: 11n support for athn(4)

[Stefan Sperling]

On Mon, Mar 06, 2017 at 07:36:21AM +0200, Timo Myyrä wrote:
> Did some tcpbench testing and got following results:
> Each test run with: tcpbench -s || tcpbench -t 15  commands.
> Host AP: apu 2b4 with athn, client = thinkpad t430s with iwn (OpenBSD)
> 
> channel 9 running old snapshot etc:
> 11n client -> server ~4, server -> ~0,
> 11g client -> server ~16, server -> client ~0-6mbs
> ---
> updated to new snapshot: OpenBSD 6.0-current (GENERIC.MP) #206: Sat Mar  4 
> 09:22:00 MST 2017
> = added another antenna, moved the ap to better spot, switched old ap off, 
> changed channel to 11
> 11n client -> server: ~6mbps, server -> client ~0.2mbps
> 11g client -> server: ~7mbps, server -> client ~3mbps
> 
> ---
> switch to channel 3:
> 11n client -> server: ~7mbps, server -> client: ~0-5mbps
> 11g client -> server: 16mbps, server -> client: ~5mbps
> 
> ---
> applied dyn rts patch:
> 11n client -> server: 4-7mbps, server -> client 0.2-5.5mbps
> 11g client -> server: ~4mbps, server -> client: ~5.5mbps

What made 11n go down from 16 to 4?
11g is not affected by this patch so something else affected 11g.
Could it be other networks on overlapping channels?
 
To tell whether the patch has any effect in your case I would like to
know which HT protection setting your AP is using.

Find a snapshot dated a bit after 2017/03/04 10:51:20 MST, or make sure tcpdump
sources are -current and rebuild and install tcpdump. Associate to the AP,
and run: tcpdump -n -i iwn0 -y IEEE802_11_RADIO -s 4096 -v -l | grep beacon
and in htop=<...> look for 'htprot'. If it shows 'htprot none' then dynamic
RTS is used in 11n mode (i.e. my patch will switch RTS on/off as needed).
Otherwise, you have some pre-11n devices in your environment so RTS must
always be enabled and my patch makes no difference.

Note that the iwn(4) driver does not yet support MIMO in 11n mode.
Once it does, 11n should become faster than 11g. I have seen an iwm(4) client
which supports MIMO max out at 21 Mbps tcpbench towards my athn(4) AP, on a
5GHz channel with 'htprot none'.
Unfortunately, tcpbench in the other direction (athn -> iwm) peaks at 10 Mbps.
There is plenty of room for improvement.

> At least what pops up in the measurements is that 11g gives more stable
> behaviour. 11n speed seems to vary a lot in that 15s test compared to 11g.

This could be explained by differences in rate scaling algorithms.
In -current 11g uses AMRR, and 11n mode uses MiRa which jumps around more.
In 6.0 everything used AMRR so a comparing how a 6.0 iwn client performs
in 11n mode would be useful (you could e.g. install 6.0 to a USB stick
and boot from it for running a speed test).

Re: 11n support for athn(4)

[Timo Myyrä]

Stefan Sperling  writes:

> On Tue, Jan 31, 2017 at 07:10:04AM +0200, Timo Myyrä wrote:
>> 11g: Client->AP: ~15Mbps, AP->Client: ~5Mbps
>> 11n: Client->AP: ~3Mbps, AP->Client: ~5Mbps
>
> I just committed a change which makes RTS optional in 11n mode.
> The AP starts out with RTS enabled. Every 30 seconds the AP checks for
> the presence of non-11n devices and enables/disables RTS accordingly.
>
> Can you update to -current and measure again?
> I would like to know if 11g and 11n performance still differs.

Hi,

Did some tcpbench testing and got following results:
Each test run with: tcpbench -s || tcpbench -t 15  commands.
Host AP: apu 2b4 with athn, client = thinkpad t430s with iwn (OpenBSD)

channel 9 running old snapshot etc:
11n client -> server ~4, server -> ~0,
11g client -> server ~16, server -> client ~0-6mbs
---
updated to new snapshot: OpenBSD 6.0-current (GENERIC.MP) #206: Sat Mar  4 
09:22:00 MST 2017
= added another antenna, moved the ap to better spot, switched old ap off, 
changed channel to 11
11n client -> server: ~6mbps, server -> client ~0.2mbps
11g client -> server: ~7mbps, server -> client ~3mbps

---
switch to channel 3:
11n client -> server: ~7mbps, server -> client: ~0-5mbps
11g client -> server: 16mbps, server -> client: ~5mbps

---
applied dyn rts patch:
11n client -> server: 4-7mbps, server -> client 0.2-5.5mbps
11g client -> server: ~4mbps, server -> client: ~5.5mbps

At least what pops up in the measurements is that 11g gives more stable
behaviour. 11n speed seems to vary a lot in that 15s test compared to 11g.

Timo

Re: 11n support for athn(4)

[Stefan Sperling]

On Tue, Jan 31, 2017 at 07:10:04AM +0200, Timo Myyrä wrote:
> 11g: Client->AP: ~15Mbps, AP->Client: ~5Mbps
> 11n: Client->AP: ~3Mbps, AP->Client: ~5Mbps

I just committed a change which makes RTS optional in 11n mode.
The AP starts out with RTS enabled. Every 30 seconds the AP checks for
the presence of non-11n devices and enables/disables RTS accordingly.

Can you update to -current and measure again?
I would like to know if 11g and 11n performance still differs.

Re: mira sfer overflow panic (was: Re: 11n support for athn(4))

[Theo Buehler]

On Sat, Feb 11, 2017 at 10:31:39AM +, Peter Kay wrote:
> 
> 
> On Thu, Jan 26, 2017 at 10:38:44AM +0100, Stefan Sperling wrote:
> > On Thu, Jan 26, 2017 at 06:36:06AM +, Peter Kay wrote:
> > > sfer overflow
> > 
> > Interesting. This is the first time I've ever seen this panic trigger.
> > 
> > Can you apply this patch and try to trigger it again?
> I've been running with MIRADEBUG since Feb 1st, just now had a different panic
> 
> Bogus long slot station count 0
> 
> Ieee80211_node_leave _11g+0xd0
> 
> Will post details later when I've had chance to ocr the screencaps

Thanks, I think you can spare yourself the trouble of ocr'ing the
screencaps. On February 2nd stsp committed a fix for the refcounting
bugs that led to this panic:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_node.c?rev=1.113=text/x-cvsweb-markup

Re: mira sfer overflow panic (was: Re: 11n support for athn(4))

[Peter Kay]

On Thu, Jan 26, 2017 at 10:38:44AM +0100, Stefan Sperling wrote:
> On Thu, Jan 26, 2017 at 06:36:06AM +, Peter Kay wrote:
> > sfer overflow
> 
> Interesting. This is the first time I've ever seen this panic trigger.
> 
> Can you apply this patch and try to trigger it again?
I've been running with MIRADEBUG since Feb 1st, just now had a different panic

Bogus long slot station count 0

Ieee80211_node_leave _11g+0xd0

Will post details later when I've had chance to ocr the screencaps

Re: 11n support for athn(4)

[Peter Faiman]

> On Jan 18, 2017, at 2:02 AM, Stefan Sperling  wrote:
> 
> On Wed, Jan 18, 2017 at 09:19:28AM +0100, Uwe Werler wrote:
>> On 16. Jan 17:46:48, Uwe Werler wrote:
>>> 
>>> Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get 
>>> ~16 MBit.
>>> 
>>> 
>>> zarathustra:~# tcpbench apu01
>>>  elapsed_ms  bytes mbps   bwidth
>>>1004 7482725.962  100.00%
>>> Conn:   1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962
>>>2007 8396646.697  100.00%
>>> Conn:   1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697
>>>3010 8182446.533  100.00%
>>> Conn:   1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533
>>>4013 9096367.255  100.00%
>>> Conn:   1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255
>>>5014 8568006.848  100.00%
>>> Conn:   1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848
>>>6015 8682246.946  100.00%
>>> Conn:   1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946
>>>7021 8725086.945  100.00%
>>> Conn:   1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945
>>>8023 8353806.670  100.00%
>>> Conn:   1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670
>>>9025 8482326.779  100.00%
>>> Conn:   1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779
>>>   10028 8439486.731  100.00%
>>> Conn:   1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731
>>>   11036 8310966.596  100.00%
>>> Conn:   1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596
>>> 
>>> I'm now ready to test furhter.
>>> 
>> 
>> I tested yesterday with my Android phone (Galaxy S7) and got only ~4 MBit.
> 
> Thank you for providing these numbers.
> 
> I would like to note though that there are many factors determining the
> effective throughput of wifi, ranging from wifi hardware, across OS and
> driver code, to specific AP/client behaviour and environmental RF conditions.
> 
> So when you report a number, you help with establishing a picture of the
> overall range of throughput people are seeing. But a number does not tell
> anybody anything about why throughput is lower than expected in your case.
> So this number cannot be used to actually improve the driver.
> It is just a data point.
> 
> What would help a small bit is a direct comparison with Linux running on the
> same access point hardware in the exact same environment. That would indicate
> which performance levels could be reached in your environment if OpenBSD was
> optimally tuned. I assume Linux has reached optimal performance levels on
> this several years old hardware by now.
> 
> In my testing I have noticed that Intel clients send data much faster than
> athn APs/clients do. The AP is able to receive higher data rates than it
> is sending. I don't know why that is happening and under which conditions
> this is to be expected. But it points to a problem with the athn driver.
> Perhaps the hardware is not tuned towards the specific way in which our
> driver makes use of it.
> 
> For now, I am happy if your AP works without crashing.
> As mentioned in the driver's man page, our 11n support is still incomplete
> and a whole lot remains to be done.
> 

Thanks for all your work on 11n!

I just got my system set up with a wle200nx in hostap mode, with the OpenBSD 
snapshots from today. It’s working great so far, I’m able to consistently get 
13-16 megabits up and down with this config, enough to watch Netflix with no 
issues! Has anyone seen better than 16 megabit?

It’s proven robust so far, and I get much better signal all over my apartment 
whereas my old WRT610N had some trouble. I will compare with Linux as soon as I 
can, but realistically it’s working so well I don’t have a lot of motivation to 
change it. I can also report that I was changing modes and channels over ssh to 
test out different things, and didn’t have any crashes or issues.

WRT the receive vs send data rates, I observed that as well before I landed on 
this config. For me, 2.4 ghz 11n channels were getting 3-4 mbits to the AP, and 
11+ mbits down. I kind of assumed that, like many wireless chips, the receive 
is just better on this chip.

Ah, and all my testing was done with a late 2013 MacBook pro, and an iPhone 
6s+. As far as my environment, my MacBook detects ~37 networks around me, 
mostly on 2.4 ghz channels, about 1/3 on 5 ghz. I’m using chan 165 since none 
of the other APs seemed to pick it (they are maxing out at 161), so it seemed 
like a sensible choice for a static config.

If there is any other useful information I could report, I’d be happy to!

athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16
athn0: 

Re: 11n support for athn(4)

[Timo Myyrä]

Stefan Sperling  writes:

> On Sun, Jan 29, 2017 at 07:49:56AM +0200, Timo Myyrä wrote:
>> Hmm, I've been running the 11n for a while and it seems to be a lot slower 
>> than
>> 11g for me. Just did quick benchmark using tcpbench between OpenBSD hostAP 
>> (athn) and
>> laptop (iwn). It looks when my athn is in 11n mode I get around ~3 Mbps:
>
> Which direction did you measure? Client->AP or AP->Client?
> Have you measured both directions? I expect client->AP to be faster if a
> non-OpenBSD client is used. Such clients will likely use Tx aggregation.
> But OpenBSD does not (yet).
>

Initially I just measured Client->AP. I did another measurement yesterday
looking at traffic in both ways and got pretty poor results. The AP->Client when
in 11n mode had throughput between 0-2 Mbps. I did test it during evening so
there might have been a bit more interference but still, that wasn't very
promising result.

But good news is that I noticed your commits to athn and did a new benchmarks
with those changes:
11g: Client->AP: ~15Mbps, AP->Client: ~5Mbps
11n: Client->AP: ~3Mbps, AP->Client: ~5Mbps

So it seems to improved the AP->Client traffic somewhat or its just that I get
full bandwidth to myself in the mornings. 


>> Quickly looking it seems the 11g is 3x faster than 11n which seems a bit odd.
>> I'd assume they should be roughly the same.
>> 
>> Any idea what could explain the difference?
>
> It might be due to RTS/CTS.
> https://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS
>
> Without TX aggregation, RTS/CTS causes up to 77% overhead on a 20MHz
> channel and a 1500 byte MTU. See Figure 10 in
> http://www.nle.com/literature/Airmagnet_impact_of_legacy_devices_on_80211n.pdf
> Perhaps this overhead is making the difference?
>

Perhaps, I need to take a moment to digest the document.

> You could take a look at what is happening at the wifi frame layer and
> compare 11n and 11g. To do so, get an iwn(4) device and put it in monitor
> mode on the same channel, and use tcpdump's -y IEEE802_11_RADIO option.
> This will show control frames such as rts/cts (but only with iwn(4)
> because most other drivers unfortunately filter these frames).
>
> You'll see RTS/CTS being exchanged for every frame with an OpenBSD 11n hostap.
> This is because OpenBSD 11n hostap forces "HT protection" on. This forces
> clients (and the AP) to reserve the medium with an RTS frame before sending
> a data frame to avoid collisions from legacy 11a/b/g clients. This is the
> simplest way of being standard compliant in any environment.
>
> HT protection could be switched off if only 11n clients exist on the channel
> (not just on the same AP), and with good commercial APs you'll see this
> behaviour. But OpenBSD's wifi stack does not yet monitor the channel in
> a way that allows a decision to be made about turning HT protection off.
>
> In any case, this will likely get better once OpenBSD supports Tx aggregation.
> Then it will send multiple frames after reserving the medium with RTS/CTS
> and the overhead is reduced.

Ok, good to know. if I find a good moment I'll try to mess around with tcpdump a
bit to see if anything pops up.

>
>> There are 8 other wireless networks in range but all of those are on 
>> different channels.
>
> Are they on overlapping channels? See here for a good illustration:
> https://en.wikipedia.org/wiki/IEEE_802.11#/media/File:2.4_GHz_Wi-Fi_channels_(802.11b,g_WLAN).svg
>

Seems they are overlapping a bit. Will try to find clearer channel for my wifi.

> If no other networks overlap, or all other networks use 11n only, then
> you don't need HT protection. The crude patch below should disable it
> and might make 11n and 11g perform equally in your environment.
> Obviously this patch is not a real fix and I don't intend to commit it.
>
> Index: ieee80211_node.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
> retrieving revision 1.112
> diff -u -p -r1.112 ieee80211_node.c
> --- ieee80211_node.c  16 Jan 2017 09:35:43 -  1.112
> +++ ieee80211_node.c  29 Jan 2017 08:37:47 -
> @@ -364,8 +364,12 @@ ieee80211_create_ibss(struct ieee80211co
>* beacons from other networks) which proves that only HT
>* STAs are on the air.
>*/
> +#if 0
>   ni->ni_htop1 = IEEE80211_HTPROT_NONMEMBER;
>   ic->ic_protmode = IEEE80211_PROT_RTSCTS;
> +#else
> + ni->ni_htop1 = IEEE80211_HTPROT_NONE;
> +#endif
>  
>   /* Configure QoS EDCA parameters. */
>   for (aci = 0; aci < EDCA_NUM_AC; aci++) {
> @@ -1476,9 +1480,11 @@ ieee80211_node_join_ht(struct ieee80211c
>   /* Update HT protection setting. */
>   if ((ni->ni_flags & IEEE80211_NODE_HT) == 0) {
>   ic->ic_nonhtsta++;
> +#if 0
>   ic->ic_bss->ni_htop1 = IEEE80211_HTPROT_NONHT_MIXED;
>   if (ic->ic_update_htprot)
>   

Re: 11n support for athn(4)

[Stefan Sperling]

On Sun, Jan 29, 2017 at 07:49:56AM +0200, Timo Myyrä wrote:
> Hmm, I've been running the 11n for a while and it seems to be a lot slower 
> than
> 11g for me. Just did quick benchmark using tcpbench between OpenBSD hostAP 
> (athn) and
> laptop (iwn). It looks when my athn is in 11n mode I get around ~3 Mbps:

Which direction did you measure? Client->AP or AP->Client?
Have you measured both directions? I expect client->AP to be faster if a
non-OpenBSD client is used. Such clients will likely use Tx aggregation.
But OpenBSD does not (yet).

> Quickly looking it seems the 11g is 3x faster than 11n which seems a bit odd.
> I'd assume they should be roughly the same.
> 
> Any idea what could explain the difference?

It might be due to RTS/CTS.
https://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS

Without TX aggregation, RTS/CTS causes up to 77% overhead on a 20MHz
channel and a 1500 byte MTU. See Figure 10 in
http://www.nle.com/literature/Airmagnet_impact_of_legacy_devices_on_80211n.pdf
Perhaps this overhead is making the difference?

You could take a look at what is happening at the wifi frame layer and
compare 11n and 11g. To do so, get an iwn(4) device and put it in monitor
mode on the same channel, and use tcpdump's -y IEEE802_11_RADIO option.
This will show control frames such as rts/cts (but only with iwn(4)
because most other drivers unfortunately filter these frames).

You'll see RTS/CTS being exchanged for every frame with an OpenBSD 11n hostap.
This is because OpenBSD 11n hostap forces "HT protection" on. This forces
clients (and the AP) to reserve the medium with an RTS frame before sending
a data frame to avoid collisions from legacy 11a/b/g clients. This is the
simplest way of being standard compliant in any environment.

HT protection could be switched off if only 11n clients exist on the channel
(not just on the same AP), and with good commercial APs you'll see this
behaviour. But OpenBSD's wifi stack does not yet monitor the channel in
a way that allows a decision to be made about turning HT protection off.

In any case, this will likely get better once OpenBSD supports Tx aggregation.
Then it will send multiple frames after reserving the medium with RTS/CTS
and the overhead is reduced.

> There are 8 other wireless networks in range but all of those are on 
> different channels.

Are they on overlapping channels? See here for a good illustration:
https://en.wikipedia.org/wiki/IEEE_802.11#/media/File:2.4_GHz_Wi-Fi_channels_(802.11b,g_WLAN).svg

If no other networks overlap, or all other networks use 11n only, then
you don't need HT protection. The crude patch below should disable it
and might make 11n and 11g perform equally in your environment.
Obviously this patch is not a real fix and I don't intend to commit it.

Index: ieee80211_node.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.112
diff -u -p -r1.112 ieee80211_node.c
--- ieee80211_node.c16 Jan 2017 09:35:43 -  1.112
+++ ieee80211_node.c29 Jan 2017 08:37:47 -
@@ -364,8 +364,12 @@ ieee80211_create_ibss(struct ieee80211co
 * beacons from other networks) which proves that only HT
 * STAs are on the air.
 */
+#if 0
ni->ni_htop1 = IEEE80211_HTPROT_NONMEMBER;
ic->ic_protmode = IEEE80211_PROT_RTSCTS;
+#else
+   ni->ni_htop1 = IEEE80211_HTPROT_NONE;
+#endif
 
/* Configure QoS EDCA parameters. */
for (aci = 0; aci < EDCA_NUM_AC; aci++) {
@@ -1476,9 +1480,11 @@ ieee80211_node_join_ht(struct ieee80211c
/* Update HT protection setting. */
if ((ni->ni_flags & IEEE80211_NODE_HT) == 0) {
ic->ic_nonhtsta++;
+#if 0
ic->ic_bss->ni_htop1 = IEEE80211_HTPROT_NONHT_MIXED;
if (ic->ic_update_htprot)
ic->ic_update_htprot(ic, ic->ic_bss);
+#endif
}
 }
 
@@ -1776,9 +1782,11 @@ ieee80211_node_leave(struct ieee80211com
panic("bogus non-HT station count %d", ic->ic_nonhtsta);
if (--ic->ic_nonhtsta == 0) {
/* All associated stations now support HT. */
+#if 0
ic->ic_bss->ni_htop1 = IEEE80211_HTPROT_NONMEMBER;
if (ic->ic_update_htprot)
ic->ic_update_htprot(ic, ic->ic_bss);
+#endif
}
}
 

Re: 11n support for athn(4)

[Timo Myyrä]

Stefan Sperling  writes:

> This diff adds 11n support to the athn(4) driver.
> Requires -current net80211 code from today.
>
> Tested in hostap mode and client mode with:
> athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
> athn0: AR9280 rev 2 (2T2R), ROM rev 22, adddress xx:xx:xx:xx:xx:xx
>
> And in client mode with:
> athn0 at uhub1 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 
> 2.00/1.08 addr 2
> athn0: AR9271 rev 1 (1T1R), ROM rev 13, address xx:xx:xx:xx:xx:xx
>
> Hostap performance is not perfect yet but should be no worse than
> 11a/b/g modes in the same environment.
>
> For Linux clients a fix for WME params is needed which I also posted to tech@.
>
> This diff does not modify the known-broken and disabled ar9003 code,
> apart from making sure it still builds.
>
> I'm looking for both tests and OKs.
>
> Index: dev/cardbus/if_athn_cardbus.c
> ===
> RCS file: /cvs/src/sys/dev/cardbus/if_athn_cardbus.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 if_athn_cardbus.c
> --- dev/cardbus/if_athn_cardbus.c 24 Nov 2015 17:11:39 -  1.14
> +++ dev/cardbus/if_athn_cardbus.c 8 Jan 2017 09:31:28 -
> @@ -43,6 +43,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> Index: dev/ic/ar5008.c
> ===
> RCS file: /cvs/src/sys/dev/ic/ar5008.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 ar5008.c
> --- dev/ic/ar5008.c   29 Nov 2016 10:22:30 -  1.37
> +++ dev/ic/ar5008.c   9 Jan 2017 10:14:41 -
> @@ -51,6 +51,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -217,7 +218,7 @@ ar5008_attach(struct athn_softc *sc)
>   sc->flags |= ATHN_FLAG_11A;
>   if (base->opCapFlags & AR_OPFLAGS_11G)
>   sc->flags |= ATHN_FLAG_11G;
> - if (base->opCapFlags & AR_OPFLAGS_11N)
> + if ((base->opCapFlags & AR_OPFLAGS_11N_DISABLED) == 0)
>   sc->flags |= ATHN_FLAG_11N;
>  
>   IEEE80211_ADDR_COPY(ic->ic_myaddr, base->macAddr);
> @@ -952,9 +953,11 @@ ar5008_tx_process(struct athn_softc *sc,
>   struct ifnet *ifp = >ic_if;
>   struct athn_txq *txq = >txq[qid];
>   struct athn_node *an;
> + struct ieee80211_node *ni;
>   struct athn_tx_buf *bf;
>   struct ar_tx_desc *ds;
>   uint8_t failcnt;
> + int txfail;
>  
>   bf = SIMPLEQ_FIRST(>head);
>   if (bf == NULL)
> @@ -970,13 +973,16 @@ ar5008_tx_process(struct athn_softc *sc,
>  
>   sc->sc_tx_timer = 0;
>  
> - if (ds->ds_status1 & AR_TXS1_EXCESSIVE_RETRIES)
> + txfail = (ds->ds_status1 & AR_TXS1_EXCESSIVE_RETRIES);
> + if (txfail)
>   ifp->if_oerrors++;
>  
>   if (ds->ds_status1 & AR_TXS1_UNDERRUN)
>   athn_inc_tx_trigger_level(sc);
>  
>   an = (struct athn_node *)bf->bf_ni;
> + ni = (struct ieee80211_node *)bf->bf_ni;
> +
>   /*
>* NB: the data fail count contains the number of un-acked tries
>* for the final series used.  We must add the number of tries for
> @@ -987,10 +993,27 @@ ar5008_tx_process(struct athn_softc *sc,
>   failcnt += MS(ds->ds_status9, AR_TXS9_FINAL_IDX) * 2;
>  
>   /* Update rate control statistics. */
> - an->amn.amn_txcnt++;
> - if (failcnt > 0)
> - an->amn.amn_retrycnt++;
> -
> + if (ni->ni_flags & IEEE80211_NODE_HT) {
> + an->mn.frames++;
> + an->mn.ampdu_size = bf->bf_m->m_pkthdr.len + IEEE80211_CRC_LEN;
> + an->mn.agglen = 1; /* XXX We do not yet support Tx agg. */
> + if (failcnt > 0)
> + an->mn.retries++;
> + if (txfail)
> + an->mn.txfail++;
> + if ((ic->ic_opmode == IEEE80211_M_STA &&
> + ic->ic_state == IEEE80211_S_RUN)
> +#ifndef IEEE80211_STA_ONLY
> + || (ic->ic_opmode == IEEE80211_M_HOSTAP &&
> + ni->ni_state == IEEE80211_STA_ASSOC)
> +#endif
> + )
> + ieee80211_mira_choose(>mn, ic, ni);
> + } else {
> + an->amn.amn_txcnt++;
> + if (failcnt > 0)
> + an->amn.amn_retrycnt++;
> + }
>   DPRINTFN(5, ("Tx done qid=%d status1=%d fail count=%d\n",
>   qid, ds->ds_status1, failcnt));
>  
> @@ -1110,7 +1133,7 @@ ar5008_swba_intr(struct athn_softc *sc)
>   ds->ds_ctl2 = SM(AR_TXC2_XMIT_DATA_TRIES0, 1);
>  
>   /* Write Tx rate. */
> - ridx = (ic->ic_curmode == IEEE80211_MODE_11A) ?
> + ridx = IEEE80211_IS_CHAN_5GHZ(ni->ni_chan) ?
>   ATHN_RIDX_OFDM6 : ATHN_RIDX_CCK1;
>   hwrate = athn_rates[ridx].hwrate;
>   ds->ds_ctl3 = SM(AR_TXC3_XMIT_RATE0, hwrate);
> @@ -1315,15 +1338,25 @@ ar5008_tx(struct athn_softc *sc, struct 
>   IEEE80211_FC0_TYPE_DATA) {
>   /* Use lowest rate for all tries. */
> 

Re: mira sfer overflow panic (was: Re: 11n support for athn(4))

[Stefan Sperling]

On Thu, Jan 26, 2017 at 10:38:44AM +0100, Stefan Sperling wrote:
> On Thu, Jan 26, 2017 at 06:36:06AM +, Peter Kay wrote:
> > sfer overflow
> 
> Interesting. This is the first time I've ever seen this panic trigger.
> 
> Can you apply this patch and try to trigger it again?

Peter, you can throw the diff below away and update your src tree.

I have just committed a better diff. These errors are recoverable so
there is no real reason to panic when they occur. To see the problem
with this new code, you'll need to run 'ifconfig athn0 debug'. This
will log what used to be the panic message to dmesg, including the
MAC address of the client which triggered it.

To also get the driver stats we need to debug the problem, please compile
a kernel with 'option MIRA_DEBUG' (or add a line '#define MIRA_DEBUG'
at the top of ieee80211_mira.c before compiling the kernel).
This will print the stats as well so we can see why sfer is overflowing.
MIRA_DEBUG will also cause some other noise (e.g. when mira selects a
new rate). You can ignore that.

> Index: ieee80211_mira.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_mira.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 ieee80211_mira.c
> --- ieee80211_mira.c  12 Jan 2017 18:06:57 -  1.8
> +++ ieee80211_mira.c  26 Jan 2017 09:37:27 -
> @@ -427,8 +427,15 @@ ieee80211_mira_update_stats(struct ieee8
>  
>   /* Compute Sub-Frame Error Rate (see section 2.2 in MiRA paper). */
>   sfer = (mn->frames * mn->retries + mn->txfail);
> - if ((sfer >> MIRA_FP_SHIFT) != 0)
> + if ((sfer >> MIRA_FP_SHIFT) != 0) {
> + printf("%s: driver stats:\n", __func__);
> + printf("mn->frames = %u\n", mn->frames);
> + printf("mn->retries = %u\n", mn->retries);
> + printf("mn->txfail = %u\n", mn->txfail);
> + printf("mn->ampdu_size = %u\n", mn->ampdu_size);
> + printf("mn->agglen = %u\n", mn->agglen);
>   panic("sfer overflow"); /* bug in wifi driver */
> + }
>   sfer <<= MIRA_FP_SHIFT; /* convert to fixed-point */
>   sfer /= ((mn->retries + 1) * mn->frames);
>   if (sfer > MIRA_FP_1)
> 

mira sfer overflow panic (was: Re: 11n support for athn(4))

[Stefan Sperling]

On Thu, Jan 26, 2017 at 06:36:06AM +, Peter Kay wrote:
> sfer overflow

Interesting. This is the first time I've ever seen this panic trigger.

Can you apply this patch and try to trigger it again?

Index: ieee80211_mira.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_mira.c,v
retrieving revision 1.8
diff -u -p -r1.8 ieee80211_mira.c
--- ieee80211_mira.c12 Jan 2017 18:06:57 -  1.8
+++ ieee80211_mira.c26 Jan 2017 09:37:27 -
@@ -427,8 +427,15 @@ ieee80211_mira_update_stats(struct ieee8
 
/* Compute Sub-Frame Error Rate (see section 2.2 in MiRA paper). */
sfer = (mn->frames * mn->retries + mn->txfail);
-   if ((sfer >> MIRA_FP_SHIFT) != 0)
+   if ((sfer >> MIRA_FP_SHIFT) != 0) {
+   printf("%s: driver stats:\n", __func__);
+   printf("mn->frames = %u\n", mn->frames);
+   printf("mn->retries = %u\n", mn->retries);
+   printf("mn->txfail = %u\n", mn->txfail);
+   printf("mn->ampdu_size = %u\n", mn->ampdu_size);
+   printf("mn->agglen = %u\n", mn->agglen);
panic("sfer overflow"); /* bug in wifi driver */
+   }
sfer <<= MIRA_FP_SHIFT; /* convert to fixed-point */
sfer /= ((mn->retries + 1) * mn->frames);
if (sfer > MIRA_FP_1)

Re: 11n support for athn(4)

[Peter Kay]

On 17 January 2017 at 12:25, Stefan Sperling  wrote:
> On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote:
>> Without more details, all I can do is guess.
>> I made one guess already (antennas) and sadly I guessed wrong.
>
> Another thing where your setup differs from mine is that you are
> using a device with 3 antennas, whereas my devices only have 2.
>
> I have already ordered a 3 antenna device two days ago so I should
> have one to test with soon. Perhaps I will see a problem then.
>
> Is anyone else reading this list using a 3 antenna device?
> Please let us know whether it works.
I'd actually recompiled the kernel using January 16th sources and it
was working fine, until tonight. Brought up the glass console to see a
panic

The following was photographed, then OCRd. I've given it a quick look
to check it seems ok, but not a fine toothcomb.

sfer overflow

ddb> trace Debugger(d09e973d,13734d68,d09cf94e,f3734db8,b200) at
Debugger+0x7 panic(d09cf9de,f3734d8c,d03c88c9,d1605008,13734df8) at
panic.0x71
ieee80211_mira_update_stats(d169ab58,d1364030,4169a000,d03b9634,d0c6c980)
at ieee80211 mira_update_siats+0x3bf
 ieee80211_mira_choose(d169ab58,d1364030,d169a000,0,d13be040) at
ieee80.2.11_mira_choose+0x4e
ar5008_tx_process (d1364009 ,0 , f3734edc,760f4a ,8354c175) at
arS008_tx_process+0x1f2
 ar5008_tx intr (d1364000,c0,f3734f0c, d03ba33f ,f3734ef4) at ar5008tx_intr+0x7c
ar5008_intr (d1364000 , d135d380) at ar5008_intr+021b
 Xintrlegacy3() at Xintr_legacy3+0x81
--- interrupt ---
 cpu_idle_cycle(d0c6c960) at cpu_idlecycle+0xf

I also have the ps lists, but I ran out of time to OCR them. Let me
know if needed and I can forward the photos

Re: 11n support for athn(4)

[Stefan Sperling]

On Wed, Jan 18, 2017 at 09:19:28AM +0100, Uwe Werler wrote:
> On 16. Jan 17:46:48, Uwe Werler wrote:
> > 
> > Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get 
> > ~16 MBit.
> > 
> > 
> > zarathustra:~# tcpbench apu01
> >   elapsed_ms  bytes mbps   bwidth
> > 1004 7482725.962  100.00%
> > Conn:   1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962
> > 2007 8396646.697  100.00%
> > Conn:   1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697
> > 3010 8182446.533  100.00%
> > Conn:   1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533
> > 4013 9096367.255  100.00%
> > Conn:   1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255
> > 5014 8568006.848  100.00%
> > Conn:   1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848
> > 6015 8682246.946  100.00%
> > Conn:   1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946
> > 7021 8725086.945  100.00%
> > Conn:   1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945
> > 8023 8353806.670  100.00%
> > Conn:   1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670
> > 9025 8482326.779  100.00%
> > Conn:   1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779
> >10028 8439486.731  100.00%
> > Conn:   1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731
> >11036 8310966.596  100.00%
> > Conn:   1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596
> > 
> > I'm now ready to test furhter.
> > 
> 
> I tested yesterday with my Android phone (Galaxy S7) and got only ~4 MBit.

Thank you for providing these numbers.

I would like to note though that there are many factors determining the
effective throughput of wifi, ranging from wifi hardware, across OS and
driver code, to specific AP/client behaviour and environmental RF conditions.

So when you report a number, you help with establishing a picture of the
overall range of throughput people are seeing. But a number does not tell
anybody anything about why throughput is lower than expected in your case.
So this number cannot be used to actually improve the driver.
It is just a data point.

What would help a small bit is a direct comparison with Linux running on the
same access point hardware in the exact same environment. That would indicate
which performance levels could be reached in your environment if OpenBSD was
optimally tuned. I assume Linux has reached optimal performance levels on
this several years old hardware by now.

In my testing I have noticed that Intel clients send data much faster than
athn APs/clients do. The AP is able to receive higher data rates than it
is sending. I don't know why that is happening and under which conditions
this is to be expected. But it points to a problem with the athn driver.
Perhaps the hardware is not tuned towards the specific way in which our
driver makes use of it.

For now, I am happy if your AP works without crashing.
As mentioned in the driver's man page, our 11n support is still incomplete
and a whole lot remains to be done.

Re: 11n support for athn(4)

[Uwe Werler]

On 16. Jan 17:46:48, Uwe Werler wrote:
> 
> Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get 
> ~16 MBit.
> 
> 
> zarathustra:~# tcpbench apu01
>   elapsed_ms  bytes mbps   bwidth
> 1004 7482725.962  100.00%
> Conn:   1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962
> 2007 8396646.697  100.00%
> Conn:   1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697
> 3010 8182446.533  100.00%
> Conn:   1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533
> 4013 9096367.255  100.00%
> Conn:   1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255
> 5014 8568006.848  100.00%
> Conn:   1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848
> 6015 8682246.946  100.00%
> Conn:   1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946
> 7021 8725086.945  100.00%
> Conn:   1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945
> 8023 8353806.670  100.00%
> Conn:   1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670
> 9025 8482326.779  100.00%
> Conn:   1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779
>10028 8439486.731  100.00%
> Conn:   1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731
>11036 8310966.596  100.00%
> Conn:   1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596
> 
> I'm now ready to test furhter.
> 

I tested yesterday with my Android phone (Galaxy S7) and got only ~4 MBit.

Re: 11n support for athn(4)

[Peter Kay]

  Original Message  
From: s...@stsp.name
Sent: 17 January 2017 12:25 p.m.
To: syllops...@syllopsium.co.uk; tech@openbsd.org
Subject: Re: 11n support for athn(4)

On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote:
>> Without more details, all I can do is guess.
>> I made one guess already (antennas) and sadly I >guessed wrong.

>Another thing where your setup differs from mine is >that you are
>using a device with 3 antennas, whereas my devices >only have 2.

>I have already ordered a 3 antenna device two days >ago so I should
>have one to test with soon. Perhaps I will see a >problem then.

>Is anyone else reading this list using a 3 antenna >device?
>Please let us know whether it works.
Assuming my firewall hangs again tonight, I'll revert to 11g and see if the 
issue persists. Would ssh access help to diagnose the problem? I can put other 
hardware in to do firewall duties and swap my current box out

Re: 11n support for athn(4)

[Stefan Sperling]

On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote:
> Without more details, all I can do is guess.
> I made one guess already (antennas) and sadly I guessed wrong.

Another thing where your setup differs from mine is that you are
using a device with 3 antennas, whereas my devices only have 2.

I have already ordered a 3 antenna device two days ago so I should
have one to test with soon. Perhaps I will see a problem then.

Is anyone else reading this list using a 3 antenna device?
Please let us know whether it works.

Re: 11n support for athn(4)

[Stefan Sperling]

On Tue, Jan 17, 2017 at 10:19:39AM +, Peter Kay wrote:
> From: s...@stsp.name
> Sent: 17 January 2017 10:00 a.m.
> To: syllops...@syllopsium.co.uk
> Cc: tech@openbsd.org
> Subject: Re: 11n support for athn(4)
> 
> On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote:
> >> 
> >> Three, yes, but note that unless the antennas have been unreasonably
> >> disturbed during the snapshot upgrade nothing has changed. Also, it
> >> takes a day or so for the access point to start failing, so I'm
> >> suspecting a software issue.
> 
> >Fair enough. But I can't see anything in your reports >that would guide me
> >where to look for bugs in the code. Let me know if >you find out more.
> 
> What diagnostics are available to narrow down the cause of this issue?

The best you could give me is a way to reproduce your problem independently
in my own environment. Right now, I cannot reproduce it. My athn APs (and
those of several other people) seem to be working just fine.

Without more details, all I can do is guess.
I made one guess already (antennas) and sadly I guessed wrong.

If you are unable to narrow down the problem without a lot of handholding,
please ask an expert you know for additional help, or just use 11g mode.
I don't have enough time right now to guide you through all the details.

If there is a real problem, someone else will eventually also run into it.
Then we might learn more.

Re: 11n support for athn(4)

[Peter Kay]

  Original Message  
From: s...@stsp.name
Sent: 17 January 2017 10:00 a.m.
To: syllops...@syllopsium.co.uk
Cc: tech@openbsd.org
Subject: Re: 11n support for athn(4)

On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote:
>> 
>> Three, yes, but note that unless the antennas have been unreasonably
>> disturbed during the snapshot upgrade nothing has changed. Also, it
>> takes a day or so for the access point to start failing, so I'm
>> suspecting a software issue.

>Fair enough. But I can't see anything in your reports >that would guide me
>where to look for bugs in the code. Let me know if >you find out more.

What diagnostics are available to narrow down the cause of this issue?

Re: 11n support for athn(4)

[Stefan Sperling]

On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote:
> On 16 January 2017 at 23:30, Stefan Sperling  wrote:
> > Do you have 2 antennas properly connected to the athn card?
> 
> Three, yes, but note that unless the antennas have been unreasonably
> disturbed during the snapshot upgrade nothing has changed. Also, it
> takes a day or so for the access point to start failing, so I'm
> suspecting a software issue.

Fair enough. But I can't see anything in your reports that would guide me
where to look for bugs in the code. Let me know if you find out more.

Re: 11n support for athn(4)

[Peter Kay]

On 16 January 2017 at 23:30, Stefan Sperling  wrote:
> On Mon, Jan 16, 2017 at 07:18:04PM +, Peter Kay wrote:
>> I'm still having issues with this.
>>
>> When the access p64 bytes from 192.168.1.251: icmp_seq=678 ttl=255 
>> time=4.502 ms
oint wedges, it seems to affect my Android phone more
>> than the iwn laptop. ifconfig athn0 down up does resolve the problem
>> in the short term.
>
> Do you have 2 antennas properly connected to the athn card?

Three, yes, but note that unless the antennas have been unreasonably
disturbed during the snapshot upgrade nothing has changed. Also, it
takes a day or so for the access point to start failing, so I'm
suspecting a software issue.

Re: 11n support for athn(4)

[Stefan Sperling]

On Mon, Jan 16, 2017 at 07:18:04PM +, Peter Kay wrote:
> I'm still having issues with this.
> 
> When the access point wedges, it seems to affect my Android phone more
> than the iwn laptop. ifconfig athn0 down up does resolve the problem
> in the short term.

Do you have 2 antennas properly connected to the athn card?

Re: 11n support for athn(4)

[Peter Kay]

I'm still having issues with this.

When the access point wedges, it seems to affect my Android phone more
than the iwn laptop. ifconfig athn0 down up does resolve the problem
in the short term.

I see the changes have already been committed, so it's no longer
necessary to patch recent snapshots (running 14th, #133).

ifconfig athn0 media produces

athn0: flags=8843 mtu 1500
lladdr x:x:x:x
description: 802.11b/g wireless
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (autoselect mode 11n hostap)
status: active
ieee80211: nwid myAP chan 9 bssid x:x:x:x wpakey 0xdeadbeef
wpaprotos wpa2 wpaakms psk paciphers ccmp wpagroupcipher ccmp
supported media:
media autoselect
media autoselect mediaopt hostap
media autoselect mediaopt monitor
media autoselect mode 11b
media autoselect mode 11b mediaopt hostap
media autoselect mode 11b mediaopt monitor
media autoselect mode 11g
media autoselect mode 11g mediaopt hostap
media autoselect mode 11g mediaopt monitor
media autoselect mode 11n
media autoselect mode 11n mediaopt hostap
media autoselect mode 11n mediaopt monitor
inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255

I can possibly try switching developer options on one of the Android
phones I have lying around.


On 14 January 2017 at 12:53, Stefan Sperling  wrote:
> On Sat, Jan 14, 2017 at 12:42:09PM +, Peter Kay wrote:
>> On 14 January 2017 at 12:02, Stefan Sperling  wrote:
>> > On Sat, Jan 14, 2017 at 11:31:00AM +, Peter Kay wrote:
>> >> On 14 January 2017 at 11:23, Stefan Sperling  wrote:
>>
>> > If one of your clients says it cannot authenticate, then this client may be
>> > trying to use TKIP/WPA1. You can enable wpa1 explicitly for such clients:
>> >   ifconfig athn0 wpaprotos wpa1,wpa2
>> > But understand that you'll be running broken WEP-grade crypto if you do 
>> > this.
>> I'll upgrade to the latest snapshot. It's not a TKIP/WPA1 issue as a
>> reboot fixes it.
>
> A reboot is very drastic and won't help with narrowing down the
> cause of your issue.
>
> Can you find a better way to unwedge the AP when it runs into problems?
> Does 'ifconfig iwn0 scan' on the client help?
> Does 'ifconfig athn0 down up' on the AP help?

Re: 11n support for athn(4)

[Uwe Werler]

Hello Stefan,

many many thanks for this work!

I tested today with the latest snapshot from yesterday and a custom compiled 
kernel
from today's sources. AP is my APU1D4 and Client is my ThinkPad T530 with iwn:

AP:

athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 19
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:17:40:ba

athn0: flags=8947 mtu 1500
lladdr 04:f0:21:17:40:ba
index 4 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (autoselect hostap)
status: active
ieee80211: nwid TEST chan 1 bssid 04:f0:21:17:40:ba wpakey XXX 
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp

athn0: sending auth to 6c:88:14:36:27:b0 on channel 1 mode auto
athn0: station 6c:88:14:36:27:b0 newly authenticated (open)
athn0: sending assoc_resp to 6c:88:14:36:27:b0 on channel 1 mode auto
athn0: sending msg 1/4 of the 4-way handshake to 6c:88:14:36:27:b0
athn0: received auth from 6c:88:14:36:27:b0 rssi 34 mode auto
athn0: received assoc_req from 6c:88:14:36:27:b0 rssi 33 mode auto
athn0: sending msg 1/4 of the 4-way handshake to 6c:88:14:36:27:b0
athn0: received msg 2/4 of the 4-way handshake from 6c:88:14:36:27:b0
athn0: sending msg 3/4 of the 4-way handshake to 6c:88:14:36:27:b0
athn0: received msg 4/4 of the 4-way handshake from 6c:88:14:36:27:b0

Client:

iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
MIMO 2T2R, MoW, address 6c:88:14:36:27:b0

iwn0: end active scan
iwn0: sending auth to 04:f0:21:17:40:ba on channel 1 mode 11g
iwn0: sending assoc_req to 04:f0:21:17:40:ba on channel 1 mode 11g
iwn0: received auth from 04:f0:21:17:40:ba rssi -20 mode 11g
iwn0: associated with 04:f0:21:17:40:ba ssid "TEST" channel 1 start MCS 0 short 
preamble long slot time HT enabled
iwn0: received assoc_resp from 04:f0:21:17:40:ba rssi -21 mode 11g
iwn0: received msg 1/4 of the 4-way handshake from 04:f0:21:17:40:ba
iwn0: sending msg 2/4 of the 4-way handshake to 04:f0:21:17:40:ba
iwn0: received msg 3/4 of the 4-way handshake from 04:f0:21:17:40:ba
iwn0: sending msg 4/4 of the 4-way handshake to 04:f0:21:17:40:ba

iwn0: flags=208847 mtu 1500
lladdr 6c:88:14:36:27:b0
index 2 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect mode 11n (HT-MCS2 mode 11n)
status: active
ieee80211: nwid TEST chan 1 bssid 04:f0:21:17:40:ba -20dBm wpakey XXX 
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp

Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get ~16 
MBit.


zarathustra:~# tcpbench apu01
  elapsed_ms  bytes mbps   bwidth
1004 7482725.962  100.00%
Conn:   1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962
2007 8396646.697  100.00%
Conn:   1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697
3010 8182446.533  100.00%
Conn:   1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533
4013 9096367.255  100.00%
Conn:   1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255
5014 8568006.848  100.00%
Conn:   1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848
6015 8682246.946  100.00%
Conn:   1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946
7021 8725086.945  100.00%
Conn:   1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945
8023 8353806.670  100.00%
Conn:   1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670
9025 8482326.779  100.00%
Conn:   1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779
   10028 8439486.731  100.00%
Conn:   1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731
   11036 8310966.596  100.00%
Conn:   1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596

I'm now ready to test furhter.

Many thanks again!


Regards Uwe



Am 09.01.2017 13:54:55, schrieb Stefan Sperling:
> This diff adds 11n support to the athn(4) driver.
> Requires -current net80211 code from today.
> 
> Tested in hostap mode and client mode with:
> athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
> athn0: AR9280 rev 2 (2T2R), ROM rev 22, adddress xx:xx:xx:xx:xx:xx
> 
> And in client mode with:
> athn0 at uhub1 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 
> 2.00/1.08 addr 2
> athn0: AR9271 rev 1 (1T1R), ROM rev 13, address xx:xx:xx:xx:xx:xx
> 
> Hostap performance is not perfect yet but should be no worse than
> 11a/b/g modes in the same environment.
> 
> For Linux clients a fix for WME params is needed which I also posted to tech@.
> 
> This diff does not modify the known-broken and disabled ar9003 code,
> apart from making sure it still builds.
> 
> I'm looking 

Re: 11n support for athn(4)

[Stefan Sperling]

On Sun, Jan 15, 2017 at 10:31:29PM +, Olivier Cherrier wrote:
> On Mon, Jan 09, 2017 at 01:54:55PM +0100, s...@stsp.name wrote:
> > Date: Mon, 9 Jan 2017 13:54:55 +0100
> > From: Stefan Sperling 
> > To: tech@openbsd.org
> > Subject: 11n support for athn(4)
> 
>   Hi Stefan,
> 
> Thank you for this extended work !
> 
> I just tested today the latest snapshot on my Alix GW.
> After some time, I got this uvm_fault :

> ieee80211_input_ba(d13a2030,d5778a00,d129,0,f3636eb0) at 
> ieee80211_input_ba
> +0x1b9
> ieee80211_input(d13a2030,d5778a00,d129,f3636eb0,1) at 
> ieee80211_input+0x5b0
> 
> ar5008_rx_intr(d13a2000,c0,d0bdb7cc,d57672d0,f3636f08) at ar5008_rx_intr+0x2f2
> ar5008_intr(d13a2000,d12b85c0) at ar5008_intr+0x235
> Xintr_legacy9() at Xintr_legacy9+0x85

Please try this diff:

Index: ieee80211_node.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.111
diff -u -p -r1.111 ieee80211_node.c
--- ieee80211_node.c9 Jan 2017 20:18:59 -   1.111
+++ ieee80211_node.c15 Jan 2017 11:26:42 -
@@ -1638,6 +1638,7 @@ ieee80211_node_leave_ht(struct ieee80211
int i;
 
/* free all Block Ack records */
+   ieee80211_ba_del(ni);
for (tid = 0; tid < IEEE80211_NUM_TID; tid++) {
ba = >ni_rx_ba[tid];
if (ba->ba_buf != NULL) {

Re: 11n support for athn(4)

[Olivier Cherrier]

On Mon, Jan 09, 2017 at 01:54:55PM +0100, s...@stsp.name wrote:
> Date: Mon, 9 Jan 2017 13:54:55 +0100
> From: Stefan Sperling 
> To: tech@openbsd.org
> Subject: 11n support for athn(4)

Hi Stefan,

Thank you for this extended work !

I just tested today the latest snapshot on my Alix GW.
After some time, I got this uvm_fault :

Script started on Mon Dec 26 11:51:10 2016
11:52:05 oclocal@odile $ 
11:52:05 oclocal@odile $ doas cu -l /dev/cuaU0 -s 38400 
Connected to /dev/cuaU0 (speed 38400)

ddb> show panic
the kernel did not panic
ddb> ps
   PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
 19968  32902  32902  0  30x100081  netio tcpdump
 32902   5116  32902 76  30x100093  bpf   tcpdump
  5116  18692   5116  0  30x10008b  pause ksh
 49320  80074  49320  0  30x100083  kqreadtmux
 68772  54609  54609  0  30x100081  netio tcpdump
 54609  10608  54609 76  30x100093  bpf   tcpdump
 10608  18692  10608  0  30x10008b  pause ksh
 18692  1  18692  0  30x100080  kqreadtmux
 61250  80815  61250  0  30x100083  kqreadtmux
 80815   5768  80815  0  30x10008b  pause ksh
  5768  55189   5768   1000  30x10008b  pause ksh
 55189  26739  26739   1000  30x90  selectsshd
 26739  17529  26739  0  30x92  poll  sshd
 80074  22879  80074  0  30x10008b  pause ksh
 73882   9948  73882   1000  30x100083  ttyin ksh
  9948  84034  84034   1000  30x90  selectsshd
 84034  17529  84034  0  30x92  poll  sshd
 22879  53776  22879   1000  30x10008b  pause ksh
 53776  94675  94675   1000  30x90  selectsshd
 94675  17529  94675  0  30x92  poll  sshd
 32955  1  32955  0  30x100083  ttyin getty
--db_more-- 8336  84223  84223 74  30x100090  bpf   
pflogd
 84223  1  84223  0  30x80  netio pflogd
 61055  66055  66055 74  30x100090  bpf   pflogd
 66055  1  66055  0  30x80  netio pflogd
 50995  1  50995  0  30x100098  poll  cron
 45087  1  45087110  30x100090  poll  sndiod
  7545  1   7545 99  30x100090  poll  sndiod
 66227  1  66227109  30x90  kqreadftp-proxy
 21402  82173  82173 95  30x100092  kqreadsmtpd
 11513  82173  82173103  30x100092  kqreadsmtpd
 54208  82173  82173 95  30x100092  kqreadsmtpd
   965  82173  82173 95  30x100092  kqreadsmtpd
   679  82173  82173 95  30x100092  kqreadsmtpd
 80539  82173  82173 95  30x100092  kqreadsmtpd
 82173  1  82173  0  30x100080  kqreadsmtpd
 74992  1  74992 77  30x100090  poll  dhcpd
 17529  1  17529  0  30x80  selectsshd
 22010  1  22010  0  30x100080  poll  ntpd
 31230  58512  31230 83  30x100092  poll  ntpd
 58512  1  58512 83  30x100092  poll  ntpd
 89749  1  89749 53  30x90  kqreadunbound
 38285   2753  92830 97  30x100090  kqreadnsd
  2753  92830  92830 97  30x100090  poll  nsd
--db_more--92830  1  92830 97  30x100090  kqread
nsd
  7026  26000  26000 73  20x100090syslogd
 26000  1  26000  0  30x100082  netio syslogd
 74378  1  74378  0  30x80  mfsidlmount_mfs
 16009  0  0  0  3 0x14200  pgzerozerothread
 57007  0  0  0  3 0x14200  aiodoned  aiodoned
 67486  0  0  0  3 0x14200  syncerupdate
 65321  0  0  0  3 0x14200  cleaner   cleaner
 23106  0  0  0  3 0x14200  reaperreaper
 51825  0  0  0  3 0x14200  pgdaemon  pagedaemon
 66180  0  0  0  3 0x14200  bored crynlk
 23157  0  0  0  3 0x14200  bored crypto
 83928  0  0  0  3 0x14200  pftm  pfpurge
 63889  0  0  0  3 0x14200  usbtskusbtask
 16061  0  0  0  3 0x14200  usbatsk   usbatsk
 81215  0  0  0  3 0x14200  bored sensors
 56615  0  0  0  3 0x14200  bored softnet
 31641  0  0  0  3 0x14200  bored systqmp
 59547  0  0  0  3 0x14200  bored systq
 73733  0  0  0  3  0x40014200  bored softclock
*23402  0  0  0  7  0x40014200idle0
  3265  0  0  0  3 0x14200  kmalloc   kmthread
 1  0  1  0  30x82  wait  

Re: 11n support for athn(4)

[Tom Murphy]

Hi Stefan,

  Thanks very much for the 11n support in athn(4)! Here's mine:

athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:24:c8:4f

  I did some netperf tests between OpenBSD athn(4) in hostap mode (11n)
and a Linux wifi client (using an iwn(4) type chipset) and couldn't
get up to 4 MBps:

# netperf -4 -H 10.13.0.2 -t TCP_STREAM -C -c -l 60
MIGRATED TCP STREAM TEST from (null) (0.0.0.0) port 0 AF_INET to (null) () port 
0 AF_INET : demo
Recv   SendSend  Utilization   Service Demand
Socket Socket  Message  Elapsed  Send Recv SendRecv
Size   SizeSize Time Throughput  localremote   local   remote
bytes  bytes   bytessecs.10^6bits/s  % C  % ?  us/KB   us/KB

 87380  16384  1638460.18 3.92   7.94 3.61 331.990  
-151.019 
# netperf -4 -H 10.13.0.2 -t TCP_STREAM -C -c -l 60 
MIGRATED TCP STREAM TEST from (null) (0.0.0.0) port 0 AF_INET to (null) () port 
0 AF_INET : demo
Recv   SendSend  Utilization   Service Demand
Socket Socket  Message  Elapsed  Send Recv SendRecv
Size   SizeSize Time Throughput  localremote   local   remote
bytes  bytes   bytessecs.10^6bits/s  % C  % ?  us/KB   us/KB

 87380  16384  1638461.11 3.95   7.41 2.11 307.442  -87.524

Linux iwconfig client shows Bit rate of 1 MB/s which doesn't look right.

Any ideas?

Thanks,
Tom

Re: 11n support for athn(4)

[Stefan Sperling]

On Sat, Jan 14, 2017 at 12:42:09PM +, Peter Kay wrote:
> On 14 January 2017 at 12:02, Stefan Sperling  wrote:
> > On Sat, Jan 14, 2017 at 11:31:00AM +, Peter Kay wrote:
> >> On 14 January 2017 at 11:23, Stefan Sperling  wrote:
> 
> > If one of your clients says it cannot authenticate, then this client may be
> > trying to use TKIP/WPA1. You can enable wpa1 explicitly for such clients:
> >   ifconfig athn0 wpaprotos wpa1,wpa2
> > But understand that you'll be running broken WEP-grade crypto if you do 
> > this.
> I'll upgrade to the latest snapshot. It's not a TKIP/WPA1 issue as a
> reboot fixes it.

A reboot is very drastic and won't help with narrowing down the
cause of your issue.

Can you find a better way to unwedge the AP when it runs into problems?
Does 'ifconfig iwn0 scan' on the client help?
Does 'ifconfig athn0 down up' on the AP help?

Re: 11n support for athn(4)

[Stefan Sperling]

On Sat, Jan 14, 2017 at 11:31:00AM +, Peter Kay wrote:
> On 14 January 2017 at 11:23, Stefan Sperling  wrote:
> > On Sat, Jan 14, 2017 at 11:03:24AM +, Peter Kay wrote:
> >> On 12 January 2017 at 15:06, Stefan Sperling  wrote:
> 
> > So your first test might not have had 11n enabled since the first two
> > versions of my patch had a bug where 11n was left disabled on 2GHz only
> > devices. Please check with 'ifconfig media athn0' whether 11n mode is
> > actually supported.
> 'bad value' regardless of what interface I run this on?
> 
> > What does your /etc/hostname.athn0 file look like?
> > Please specify 'mode 11n' in your /etc/hostname.athn0, and also fix the
> > channel with a line such as 'chan 1'. There are known problems otherwise.
> > For reference, this is what I am using:
> >
> >   media autoselect mode 11n mediaopt hostap chan 10
> >   nwid stsp.name wpakey xxx
> >   up
> inet 1.1.1.1 255.255.255.0 1.1.1.255 description "802.11b/g wireless"
> media autoselect mode 11n mediaopt hostap chan 9 nwid "myap" wpakey
> "ultrasecurepassword" wpaprotos "wpa2"
> 
> I'll try applying the latest patch if it will make a difference,

Please upgrade to the latest snapshot instead. It should have all the changes.

> but the clients did think they had a carrier at greater than g speeds.

If you upgraded from 6.0 to -current to test the 11n patches, note
also that we recently disabled the TKIP pairwise cipher in -current:
https://marc.info/?l=openbsd-cvs=148224048415556=2

If one of your clients says it cannot authenticate, then this client may be
trying to use TKIP/WPA1. You can enable wpa1 explicitly for such clients:
  ifconfig athn0 wpaprotos wpa1,wpa2
But understand that you'll be running broken WEP-grade crypto if you do this.

Re: 11n support for athn(4)

[Peter Kay]

On 14 January 2017 at 11:23, Stefan Sperling  wrote:
> On Sat, Jan 14, 2017 at 11:03:24AM +, Peter Kay wrote:
>> On 12 January 2017 at 15:06, Stefan Sperling  wrote:

> So your first test might not have had 11n enabled since the first two
> versions of my patch had a bug where 11n was left disabled on 2GHz only
> devices. Please check with 'ifconfig media athn0' whether 11n mode is
> actually supported.
'bad value' regardless of what interface I run this on?

> What does your /etc/hostname.athn0 file look like?
> Please specify 'mode 11n' in your /etc/hostname.athn0, and also fix the
> channel with a line such as 'chan 1'. There are known problems otherwise.
> For reference, this is what I am using:
>
>   media autoselect mode 11n mediaopt hostap chan 10
>   nwid stsp.name wpakey xxx
>   up
inet 1.1.1.1 255.255.255.0 1.1.1.255 description "802.11b/g wireless"
media autoselect mode 11n mediaopt hostap chan 9 nwid "myap" wpakey
"ultrasecurepassword" wpaprotos "wpa2"

I'll try applying the latest patch if it will make a difference, but
the clients did think they had a carrier at greater than g speeds.

Re: 11n support for athn(4)

[Stefan Sperling]

On Sat, Jan 14, 2017 at 11:03:24AM +, Peter Kay wrote:
> On 12 January 2017 at 15:06, Stefan Sperling  wrote:
> > On Tue, Jan 10, 2017 at 12:27:47AM +0100, Stefan Sperling wrote:
> >> On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> >> > This diff adds 11n support to the athn(4) driver.
> >> > Requires -current net80211 code from today.
> >>
> I'm now getting some very odd issues that did not previously exist
> with my hostap before upgrading to the snapshot and applying the
> patch.

It seems you have a 2GHz only card according to
https://wikidevi.com/wiki/Atheros
and what you wrote earlier:

 "Hardware MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5 (PCI adapter)"

So your first test might not have had 11n enabled since the first two
versions of my patch had a bug where 11n was left disabled on 2GHz only
devices. Please check with 'ifconfig media athn0' whether 11n mode is
actually supported.

> Phone complains about an 'authentication problem', iwn laptop with
> issues about buffer space and then associates with a different ap.
> There's nothing in the logs and a reboot is required.
> 
> At first I thought it was a clock problem, because I found my firewall
> clock was somehow a month ahead, but after correcting that the second
> time it occurred the time was ok.
> 
> Going to have to revert to snapshot without the 11n patches and see if
> the issue persists. Unfortunately it takes a while to manifest itself.

What does your /etc/hostname.athn0 file look like?
Please specify 'mode 11n' in your /etc/hostname.athn0, and also fix the
channel with a line such as 'chan 1'. There are known problems otherwise.
For reference, this is what I am using:

  media autoselect mode 11n mediaopt hostap chan 10
  nwid stsp.name wpakey xxx
  up

(There is no line configuring an IP since my athn0 is part of a bridge.)

Apart from that there are known performance issues on 2GHz.
I have always had bad performance from athn(4) on 2GHz, even in 11g mode.
Currently my 2GHz AP effectively transmits no more than 500Kbit/s.
But is runs stable apart from that.

It is unclear where this problem is coming from. Until now I wasn't sure
whether this is problem is specific to my environment or not (there are
a lot of 2GHz networks around here). It does not seems to be the case
since by now several people have reported this problem.
It seems the driver works a lot better with 5 GHz devices and lacks
something specific to the 2GHz ones.

Re: 11n support for athn(4)

[Peter Kay]

On 12 January 2017 at 15:06, Stefan Sperling  wrote:
> On Tue, Jan 10, 2017 at 12:27:47AM +0100, Stefan Sperling wrote:
>> On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
>> > This diff adds 11n support to the athn(4) driver.
>> > Requires -current net80211 code from today.
>>
I'm now getting some very odd issues that did not previously exist
with my hostap before upgrading to the snapshot and applying the
patch.

Phone complains about an 'authentication problem', iwn laptop with
issues about buffer space and then associates with a different ap.
There's nothing in the logs and a reboot is required.

At first I thought it was a clock problem, because I found my firewall
clock was somehow a month ahead, but after correcting that the second
time it occurred the time was ok.

Going to have to revert to snapshot without the 11n patches and see if
the issue persists. Unfortunately it takes a while to manifest itself.

PK

Re: 11n support for athn(4)

[Stefan Sperling]

On Tue, Jan 10, 2017 at 12:27:47AM +0100, Stefan Sperling wrote:
> On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> > This diff adds 11n support to the athn(4) driver.
> > Requires -current net80211 code from today.
> 
> A better diff which fixes several bugs.

jmc@ found out I didn't enable 11n on 2GHz-only cards (such as AR9287).
This was a stupid logic error in the previous diff. This version is fixed.

Apart from that I have had no reports of problems. Can this go in?

Index: dev/cardbus/if_athn_cardbus.c
===
RCS file: /cvs/src/sys/dev/cardbus/if_athn_cardbus.c,v
retrieving revision 1.14
diff -u -p -r1.14 if_athn_cardbus.c
--- dev/cardbus/if_athn_cardbus.c   24 Nov 2015 17:11:39 -  1.14
+++ dev/cardbus/if_athn_cardbus.c   8 Jan 2017 09:31:28 -
@@ -43,6 +43,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
Index: dev/ic/ar5008.c
===
RCS file: /cvs/src/sys/dev/ic/ar5008.c,v
retrieving revision 1.37
diff -u -p -r1.37 ar5008.c
--- dev/ic/ar5008.c 29 Nov 2016 10:22:30 -  1.37
+++ dev/ic/ar5008.c 12 Jan 2017 06:10:49 -
@@ -51,6 +51,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -213,12 +214,24 @@ ar5008_attach(struct athn_softc *sc)
return (EINVAL);
}
 
-   if (base->opCapFlags & AR_OPFLAGS_11A)
+   if (base->opCapFlags & AR_OPFLAGS_11A) {
sc->flags |= ATHN_FLAG_11A;
-   if (base->opCapFlags & AR_OPFLAGS_11G)
+   if ((base->opCapFlags & AR_OPFLAGS_11N_5G20) == 0)
+   sc->flags |= ATHN_FLAG_11N;
+#ifdef notyet
+   if ((base->opCapFlags & AR_OPFLAGS_11N_5G40) == 0)
+   sc->flags |= ATHN_FLAG_11N;
+#endif
+   }
+   if (base->opCapFlags & AR_OPFLAGS_11G) {
sc->flags |= ATHN_FLAG_11G;
-   if (base->opCapFlags & AR_OPFLAGS_11N)
-   sc->flags |= ATHN_FLAG_11N;
+   if ((base->opCapFlags & AR_OPFLAGS_11N_2G20) == 0)
+   sc->flags |= ATHN_FLAG_11N;
+#ifdef notyet
+   if ((base->opCapFlags & AR_OPFLAGS_11N_2G40) == 0)
+   sc->flags |= ATHN_FLAG_11N;
+#endif
+   }
 
IEEE80211_ADDR_COPY(ic->ic_myaddr, base->macAddr);
 
@@ -952,9 +965,11 @@ ar5008_tx_process(struct athn_softc *sc,
struct ifnet *ifp = >ic_if;
struct athn_txq *txq = >txq[qid];
struct athn_node *an;
+   struct ieee80211_node *ni;
struct athn_tx_buf *bf;
struct ar_tx_desc *ds;
uint8_t failcnt;
+   int txfail;
 
bf = SIMPLEQ_FIRST(>head);
if (bf == NULL)
@@ -970,13 +985,16 @@ ar5008_tx_process(struct athn_softc *sc,
 
sc->sc_tx_timer = 0;
 
-   if (ds->ds_status1 & AR_TXS1_EXCESSIVE_RETRIES)
+   txfail = (ds->ds_status1 & AR_TXS1_EXCESSIVE_RETRIES);
+   if (txfail)
ifp->if_oerrors++;
 
if (ds->ds_status1 & AR_TXS1_UNDERRUN)
athn_inc_tx_trigger_level(sc);
 
an = (struct athn_node *)bf->bf_ni;
+   ni = (struct ieee80211_node *)bf->bf_ni;
+
/*
 * NB: the data fail count contains the number of un-acked tries
 * for the final series used.  We must add the number of tries for
@@ -987,10 +1005,26 @@ ar5008_tx_process(struct athn_softc *sc,
failcnt += MS(ds->ds_status9, AR_TXS9_FINAL_IDX) * 2;
 
/* Update rate control statistics. */
-   an->amn.amn_txcnt++;
-   if (failcnt > 0)
-   an->amn.amn_retrycnt++;
-
+   if (ni->ni_flags & IEEE80211_NODE_HT) {
+   an->mn.frames++;
+   an->mn.ampdu_size = bf->bf_m->m_pkthdr.len + IEEE80211_CRC_LEN;
+   an->mn.agglen = 1; /* XXX We do not yet support Tx agg. */
+   if (failcnt > 0)
+   an->mn.retries++;
+   if (txfail)
+   an->mn.txfail++;
+   if (ic->ic_state == IEEE80211_S_RUN) {
+#ifndef IEEE80211_STA_ONLY
+   if (ic->ic_opmode != IEEE80211_M_HOSTAP ||
+   ni->ni_state == IEEE80211_STA_ASSOC)
+#endif
+   ieee80211_mira_choose(>mn, ic, ni);
+   }
+   } else {
+   an->amn.amn_txcnt++;
+   if (failcnt > 0)
+   an->amn.amn_retrycnt++;
+   }
DPRINTFN(5, ("Tx done qid=%d status1=%d fail count=%d\n",
qid, ds->ds_status1, failcnt));
 
@@ -1110,7 +1144,7 @@ ar5008_swba_intr(struct athn_softc *sc)
ds->ds_ctl2 = SM(AR_TXC2_XMIT_DATA_TRIES0, 1);
 
/* Write Tx rate. */
-   ridx = (ic->ic_curmode == IEEE80211_MODE_11A) ?
+   ridx = IEEE80211_IS_CHAN_5GHZ(ni->ni_chan) ?
ATHN_RIDX_OFDM6 : ATHN_RIDX_CCK1;
hwrate = athn_rates[ridx].hwrate;
ds->ds_ctl3 = SM(AR_TXC3_XMIT_RATE0, 

Re: 11n support for athn(4)

[Stefan Sperling]

On Thu, Jan 12, 2017 at 06:19:06AM +, Peter Kay wrote:
> OK, got it working. Pulled the kernel sources direct from cvs without
> pre-loading and it compiled.

Thank you for testing!
 
> Haven't had time for a proper test, but there are a couple of points.
> 
> Hardware MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5 (PCI adapter)
> 
> Blackberry Priv - connects between 100 and 130M at 2.4GHz 802.11n ,
> throughput not tested yet

These data rates are all 'nominal'. The client uses 130Mbit/s only for
the very brief period of time when actual data is transmitted to the AP.
But a lot of time is spent on reserving the medium for beforehand, and
waiting for other clients and other APs to finish their transmissions.
So the actual throughput depends on environmental conditions such as how
loaded the wifi channel is.
 
> FreeBSD - iwn4965. Connects at 11ng, but if you start in 11g mode,
> change the hostap to 11n, then reassociate the client it uses 11b. May
> be a FreeBSD issue..?

I am not sure where the problem could be. The 4965 hardware does support 11g.

> Vista - same machine, connects at 130Mb.
> 
> Throughput testing, more machines later. Basic connectivity is working.

Re: 11n support for athn(4)

[Peter Kay]

OK, got it working. Pulled the kernel sources direct from cvs without
pre-loading and it compiled.

Haven't had time for a proper test, but there are a couple of points.

Hardware MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5 (PCI adapter)

Blackberry Priv - connects between 100 and 130M at 2.4GHz 802.11n ,
throughput not tested yet

FreeBSD - iwn4965. Connects at 11ng, but if you start in 11g mode,
change the hostap to 11n, then reassociate the client it uses 11b. May
be a FreeBSD issue..?

Vista - same machine, connects at 130Mb.

Throughput testing, more machines later. Basic connectivity is working.

On 11 January 2017 at 23:28, Peter Kay  wrote:
> On 11 January 2017 at 22:05, Stefan Sperling  wrote:
>
>>
>> You haven't updated all of src/sys.
>
> I'm obviously being really dumb, but what is wrong with
> cd /usr
> tar zxf sys.tar.gz (from 6.0)
> cvs -qd anon...@anoncvs.au.openbsd.org:/cvs update -dP sys
> cd sys
> patch -p0 < /path/to/wlan.diff
> cd arch/i386/conf
> config GENERIC
> cd ../compile/GENERIC
> make
>
> ? I see reference in current.html to
> make obj (this does not work (don't know how to make obj).
>
> Note : I am building this as root, because it's a VM (firewall is too
> slow to build) and building releases is all it is doing

Re: 11n support for athn(4)

[Peter Kay]

On 11 January 2017 at 22:05, Stefan Sperling  wrote:

>
> You haven't updated all of src/sys.

I'm obviously being really dumb, but what is wrong with
cd /usr
tar zxf sys.tar.gz (from 6.0)
cvs -qd anon...@anoncvs.au.openbsd.org:/cvs update -dP sys
cd sys
patch -p0 < /path/to/wlan.diff
cd arch/i386/conf
config GENERIC
cd ../compile/GENERIC
make

? I see reference in current.html to
make obj (this does not work (don't know how to make obj).

Note : I am building this as root, because it's a VM (firewall is too
slow to build) and building releases is all it is doing

Re: 11n support for athn(4)

[Stefan Sperling]

On Wed, Jan 11, 2017 at 10:00:50PM +, Peter Kay wrote:
> On 9 January 2017 at 23:27, Stefan Sperling  wrote:
> > On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> >> This diff adds 11n support to the athn(4) driver.
> >> Requires -current net80211 code from today.
> >
> > A better diff which fixes several bugs.
> >
> I'm getting
> 
> undefined reference to ieee80211_mira_node_init
> 
> ieee80211_mira_node_destroy and
> ieee80211_mira_choose
> 
> i386, GENERIC. My firewall is not multi core. Running current with
> updated patch.
> 
> PK
> 

You haven't updated all of src/sys.

Re: 11n support for athn(4)

[Peter Kay]

On 9 January 2017 at 23:27, Stefan Sperling  wrote:
> On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
>> This diff adds 11n support to the athn(4) driver.
>> Requires -current net80211 code from today.
>
> A better diff which fixes several bugs.
>
I'm getting

undefined reference to ieee80211_mira_node_init

ieee80211_mira_node_destroy and
ieee80211_mira_choose

i386, GENERIC. My firewall is not multi core. Running current with
updated patch.

PK

Re: 11n support for athn(4)

[Vadim Vygonets]

Quoth Vadim Vygonets on Tue, Jan 10, 2017:
> Quoth Stefan Sperling on Tue, Jan 10, 2017:
> > On Tue, Jan 10, 2017 at 07:14:40PM +0100, Vadim Vygonets wrote:
> > > And it seems to work, although my testing was by no means
> > > exhaustive.
> > 
> > Thank you for testing!
> > 
> > Are you testing athn in hostap or in client mode?
> 
> In client mode.  I can do hostap as well.

Tested hostap; it works.

The speed varies, but the drivers and/or wireless subsystem in
-current with your athn(4) patches are much more stable than in
6.0-stable.

> I'm testing against LEDE (a fork of OpenWRT, i.e. Linux) with
> some Atheros 9K card.  I can tell you the specifics tomorrow.

On OpenBSD side:
athn0 at pci0 dev 12 function 0 "Atheros AR9280" rev 0x01: irq 10
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx

On Linux side: Atheros AR9531 Rev:2 and Atheros AR9300 Rev:4.

Vadik.

-- 
You cannot achieve the impossible without attempting the absurd.

Re: 11n support for athn(4)

[Stefan Sperling]

On Tue, Jan 10, 2017 at 08:34:32PM -0500, Brandon Mercer wrote:
> I've thrown this on my apu2 and done some tests with my ipad, android
> phones and some openbsd laptops. Streamed 1080p from youtube works on
> one device but when I try with 2x it starts to buffer a bit. 
> 
> Tested on 2.4Ghz:
> athn0: flags=8843 mtu 1500
> index 4 priority 4 llprio 3
> groups: wlan
> media: IEEE802.11 autoselect hostap
> status: active
> ieee80211: nwid mynwid chan 7 bssid x wpakey 
> 0x5324766a441a60e61749083489bcea5df6e73deb1ddbcbe6b1054270787bb4fe wpaprotos 
> wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
> 
> OpenBSD shows: 
> media: IEEE802.11 autoselect (HT-MCS5 mode 11n)

You can see the Tx rate currently selected by the AP for each client
like this: ifconfig athn0 scan | grep assoc

In my case a 2GHz AP rarely selects more than MCS 3 since that rate
already triggers retries. If this is a common problem we could play
around a bit and allow a retry or two where the code currently has:
if (failcnt > 0)
an->mn.retries++;
That might make things faster, or it might not.

Perhaps it will get better with Tx aggregation (not yet supported).

It is also possible that some other parameters are set up improperly
by the driver. The performance mismatch between 2 and 5 GHz is quite
staggering.

Re: 11n support for athn(4)

[Brandon Mercer]

On Tue, Jan 10, 2017 at 11:08:40PM +0100, Vincent Gross wrote:
> On Tue, 10 Jan 2017 00:27:47 +0100
> Stefan Sperling  wrote:
> 
> > On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> > > This diff adds 11n support to the athn(4) driver.
> > > Requires -current net80211 code from today.  
> > 
> > A better diff which fixes several bugs.
> > 
> > Most notably this should fix a crash in hostap mode triggered by
> > clients joining and leaving in a loop. This is fixed by making sure
> > timeout handlers managed by mira aren't overwritten when a client
> > rejoins, and by cancelling these timeouts properly. I'd like to
> > rename some mira API functions for better clarity but that's left for
> > later.
> > 
> > This also restores USB device firmware rate scaling in client mode
> > which was disabled by commits I made in 2015. I found a missing
> > 'usc->nnodes--;' in the code from before those commits, and I hope
> > adding that is a proper fix for the problems we were hunting back
> > then.
> > 
> > Known issues (not blocking issues IMO):
> > 
> >  - The athn(4) driver selects low transmit rates relative to what
> > iwn(4) and iwm(4) clients select.
> > 
> >  - USB client in 11n mode only sends with legacy rates (up to
> > 54Mbit/s). Technically this is legal behaviour, and receiving MCS
> > sent by the AP works. Rate selection is done in firmware so this
> > isn't straightforward to debug.

I've thrown this on my apu2 and done some tests with my ipad, android
phones and some openbsd laptops. Streamed 1080p from youtube works on
one device but when I try with 2x it starts to buffer a bit. 

Tested on 2.4Ghz:
athn0: flags=8843 mtu 1500
index 4 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect hostap
status: active
ieee80211: nwid mynwid chan 7 bssid x wpakey 
0x5324766a441a60e61749083489bcea5df6e73deb1ddbcbe6b1054270787bb4fe wpaprotos 
wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255

OpenBSD shows: 
media: IEEE802.11 autoselect (HT-MCS5 mode 11n)

I'm seeing some decent throughput on DL: 
$ ftp
http://ftp5.usa.openbsd.org/pub/OpenBSD/snapshots/amd64/install60.fs 
Trying 129.21.208.172...
Requesting
http://ftp5.usa.openbsd.org/pub/OpenBSD/snapshots/amd64/install60.fs
100% |***|   280 MB
08:53
294092800 bytes received in 533.82 seconds (538.00 KB/s)

(That is about half what I see on my ubiquity) 

With 5Ghz I'm only able to test on my android/ipad, and I'm able to stream a 
couple 1080p videos at the same time without any issues:
athn0: flags=8843 mtu 1500
index 4 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect hostap (autoselect mode 11n hostap)
status: active
ieee80211: nwid mynwid chan 140 bssid x wpakey 
0x5324766a441a60e61749083489bcea5df6e73deb1ddbcbe6b1054270787bb4fe wpaprotos 
wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
enc0: flags=0<>
index 5 priority 0 llprio 3
groups: enc
status: active

I'll apply your other diffs and test more.
Cheers! 

Re: 11n support for athn(4)

[Vadim Vygonets]

Quoth Stefan Sperling on Tue, Jan 10, 2017:
> On Tue, Jan 10, 2017 at 07:14:40PM +0100, Vadim Vygonets wrote:
> > And it seems to work, although my testing was by no means
> > exhaustive.
> 
> Thank you for testing!
> 
> Are you testing athn in hostap or in client mode?

In client mode.  I can do hostap as well.  I have access to the
OpenBSD box with athn until Friday, and I'll be glad to run any
specific tests you want me to run.

> If hostap, which kinds of clients are you testing with?

I'm testing against LEDE (a fork of OpenWRT, i.e. Linux) with
some Atheros 9K card.  I can tell you the specifics tomorrow.

Vadik.

-- 
The best way to preserve a right is to exercise it, and the right to
smoke is a right worth dying for.

Re: 11n support for athn(4)

[Vadim Vygonets]

Quoth Vadim Vygonets on Tue, Jan 10, 2017:
> Quoth Stefan Sperling on Tue, Jan 10, 2017:
> > On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> > > This diff adds 11n support to the athn(4) driver.
> > > Requires -current net80211 code from today.
> > 
> > A better diff which fixes several bugs.
> 
> After applying the diff below, it compiled.

Please disregard the diff; my source update to -current wasn't
complete.

Vadik.

-- 
"Always apply the latest updates" and "If it ain't broke, don't
fix it" are the two rules of system administration.

Re: 11n support for athn(4)

[Vadim Vygonets]

Quoth Stefan Sperling on Tue, Jan 10, 2017:
> On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> > This diff adds 11n support to the athn(4) driver.
> > Requires -current net80211 code from today.
> 
> A better diff which fixes several bugs.

After applying the diff below, it compiled.

And it seems to work, although my testing was by no means
exhaustive.

Thank you,
Vadik.

Index: sys/conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.620
diff -u -p -u -r1.620 files
--- sys/conf/files  17 Jun 2016 19:20:19 -  1.620
+++ sys/conf/files  10 Jan 2017 17:57:50 -
@@ -800,6 +800,7 @@ file net80211/ieee80211_crypto_wep.cwla
 file net80211/ieee80211_input.cwlan
 file net80211/ieee80211_ioctl.cwlan
 file net80211/ieee80211_node.c wlan
+file net80211/ieee80211_mira.c wlan
 file net80211/ieee80211_output.c   wlan
 file net80211/ieee80211_pae_input.cwlan
 file net80211/ieee80211_pae_output.c   wlan

-- 
The good Christian should beware of mathematicians and all those who make
empty prophecies.  The danger already exists that mathematicians have made
a covenant with the devil to darken the spirit and confine man in the
bonds of Hell.  -- Saint Augustine

Re: 11n support for athn(4)

[Stefan Sperling]

On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> This diff adds 11n support to the athn(4) driver.
> Requires -current net80211 code from today.

A better diff which fixes several bugs.

Most notably this should fix a crash in hostap mode triggered by clients
joining and leaving in a loop. This is fixed by making sure timeout handlers
managed by mira aren't overwritten when a client rejoins, and by cancelling
these timeouts properly. I'd like to rename some mira API functions for
better clarity but that's left for later.

This also restores USB device firmware rate scaling in client mode which was
disabled by commits I made in 2015. I found a missing 'usc->nnodes--;' in
the code from before those commits, and I hope adding that is a proper
fix for the problems we were hunting back then.

Known issues (not blocking issues IMO):

 - The athn(4) driver selects low transmit rates relative to what iwn(4)
   and iwm(4) clients select.

 - USB client in 11n mode only sends with legacy rates (up to 54Mbit/s).
   Technically this is legal behaviour, and receiving MCS sent by the AP works.
   Rate selection is done in firmware so this isn't straightforward to debug.

Index: dev/cardbus/if_athn_cardbus.c
===
RCS file: /cvs/src/sys/dev/cardbus/if_athn_cardbus.c,v
retrieving revision 1.14
diff -u -p -r1.14 if_athn_cardbus.c
--- dev/cardbus/if_athn_cardbus.c   24 Nov 2015 17:11:39 -  1.14
+++ dev/cardbus/if_athn_cardbus.c   8 Jan 2017 09:31:28 -
@@ -43,6 +43,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
Index: dev/ic/ar5008.c
===
RCS file: /cvs/src/sys/dev/ic/ar5008.c,v
retrieving revision 1.37
diff -u -p -r1.37 ar5008.c
--- dev/ic/ar5008.c 29 Nov 2016 10:22:30 -  1.37
+++ dev/ic/ar5008.c 9 Jan 2017 22:30:38 -
@@ -51,6 +51,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -217,7 +218,7 @@ ar5008_attach(struct athn_softc *sc)
sc->flags |= ATHN_FLAG_11A;
if (base->opCapFlags & AR_OPFLAGS_11G)
sc->flags |= ATHN_FLAG_11G;
-   if (base->opCapFlags & AR_OPFLAGS_11N)
+   if ((base->opCapFlags & AR_OPFLAGS_11N_DISABLED) == 0)
sc->flags |= ATHN_FLAG_11N;
 
IEEE80211_ADDR_COPY(ic->ic_myaddr, base->macAddr);
@@ -952,9 +953,11 @@ ar5008_tx_process(struct athn_softc *sc,
struct ifnet *ifp = >ic_if;
struct athn_txq *txq = >txq[qid];
struct athn_node *an;
+   struct ieee80211_node *ni;
struct athn_tx_buf *bf;
struct ar_tx_desc *ds;
uint8_t failcnt;
+   int txfail;
 
bf = SIMPLEQ_FIRST(>head);
if (bf == NULL)
@@ -970,13 +973,16 @@ ar5008_tx_process(struct athn_softc *sc,
 
sc->sc_tx_timer = 0;
 
-   if (ds->ds_status1 & AR_TXS1_EXCESSIVE_RETRIES)
+   txfail = (ds->ds_status1 & AR_TXS1_EXCESSIVE_RETRIES);
+   if (txfail)
ifp->if_oerrors++;
 
if (ds->ds_status1 & AR_TXS1_UNDERRUN)
athn_inc_tx_trigger_level(sc);
 
an = (struct athn_node *)bf->bf_ni;
+   ni = (struct ieee80211_node *)bf->bf_ni;
+
/*
 * NB: the data fail count contains the number of un-acked tries
 * for the final series used.  We must add the number of tries for
@@ -987,10 +993,26 @@ ar5008_tx_process(struct athn_softc *sc,
failcnt += MS(ds->ds_status9, AR_TXS9_FINAL_IDX) * 2;
 
/* Update rate control statistics. */
-   an->amn.amn_txcnt++;
-   if (failcnt > 0)
-   an->amn.amn_retrycnt++;
-
+   if (ni->ni_flags & IEEE80211_NODE_HT) {
+   an->mn.frames++;
+   an->mn.ampdu_size = bf->bf_m->m_pkthdr.len + IEEE80211_CRC_LEN;
+   an->mn.agglen = 1; /* XXX We do not yet support Tx agg. */
+   if (failcnt > 0)
+   an->mn.retries++;
+   if (txfail)
+   an->mn.txfail++;
+   if (ic->ic_state == IEEE80211_S_RUN) {
+#ifndef IEEE80211_STA_ONLY
+   if (ic->ic_opmode != IEEE80211_M_HOSTAP ||
+   ni->ni_state == IEEE80211_STA_ASSOC)
+#endif
+   ieee80211_mira_choose(>mn, ic, ni);
+   }
+   } else {
+   an->amn.amn_txcnt++;
+   if (failcnt > 0)
+   an->amn.amn_retrycnt++;
+   }
DPRINTFN(5, ("Tx done qid=%d status1=%d fail count=%d\n",
qid, ds->ds_status1, failcnt));
 
@@ -1110,7 +1132,7 @@ ar5008_swba_intr(struct athn_softc *sc)
ds->ds_ctl2 = SM(AR_TXC2_XMIT_DATA_TRIES0, 1);
 
/* Write Tx rate. */
-   ridx = (ic->ic_curmode == IEEE80211_MODE_11A) ?
+   ridx = IEEE80211_IS_CHAN_5GHZ(ni->ni_chan) ?
ATHN_RIDX_OFDM6 : ATHN_RIDX_CCK1;
hwrate = athn_rates[ridx].hwrate;
ds->ds_ctl3 = 

Re: 11n support for athn(4)

[Stefan Sperling]

On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> For Linux clients a fix for WME params is needed which I also posted to tech@.

That fix is now committed.