Re: 11n support for athn(4)
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)
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)
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)
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)
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)
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))
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&content-type=text/x-cvsweb-markup
Re: mira sfer overflow panic (was: Re: 11n support for athn(4))
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)
> 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: AR9280 rev 2 (2T2R), R
Re: 11n support for athn(4)
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)
> ic->ic_update_htprot(ic, ic->
Re: 11n support for athn(4)
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)
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->ic_if;
> struct athn_txq *txq = &sc->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(&txq->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(&an->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))
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))
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)
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)
On 18. Jan 11:02:01, 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. > Dear Stefan, thanks for Your effort and explanation. Ok, then I try to boot a Linux within the next days at this box - it's my apu1d4 used as my nas and home server running current. If I can help otherwise I'm ready! Thanks again for Your time, patience and work! Uwe PS: The AP runs now since two days without any issues. --
Re: 11n support for athn(4)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 for
Re: 11n support for athn(4)
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->ni_rx_ba[tid];
if (ba->ba_buf != NULL) {
Re: 11n support for athn(4)
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)
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)
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)
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.
Re: 11n support for athn(4)
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&m=148224048415556&w=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)
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)
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)
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)
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->ic_if;
struct athn_txq *txq = &sc->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(&txq->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(&an->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_XM
Re: 11n support for athn(4)
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)
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)
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)
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)
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)
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)
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)
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)
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 just rebuilt a bsd.mp with your diff on my home router, so far so good, works with my -current laptop iwn(4) card and the BCM4339 from my android phone. I REALLY wonder where can I find lots of heavy content on the internet to stress this diff ... or not. [snip]
Re: 11n support for athn(4)
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)
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? If hostap, which kinds of clients are you testing with?
Re: 11n support for athn(4)
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)
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)
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->ic_if;
struct athn_txq *txq = &sc->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(&txq->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(&an->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->
Re: 11n support for athn(4)
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.
11n support for athn(4)
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->ic_if;
struct athn_txq *txq = &sc->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(&txq->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(&an->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. */
ridx[0] = ridx[1] = ridx[2] = ridx[3] =
- (ic->ic_curmode == IEEE80211_MODE_11A) ?
- ATHN_RIDX_OFDM6 :
