sys: Remove $FreeBSD$: one-line .c comment pattern

Remove /^/[*/]\s*\$FreeBSD\$.*\n/

iwnstats: fix build with clang and allow install under /usr/local/sbin

iwnstats was not compiling because of some issues raised by the clang
compiler due to -Werror. As a tool it is not connected to

iwnstats: fix build with clang and allow install under /usr/local/sbin

iwnstats was not compiling because of some issues raised by the clang
compiler due to -Werror. As a tool it is not connected to world build.

Add missing field "barker_mrc" initialization in struct
iwn_sensitivity_limits for -Wmissing-field-initializers, remove unused
pointer *is on iwn_stats_*_print functions and unused variables for
-Wunused-parameter and -Wunused-variable.

The value for field "barker_mrc" of struct iwn2030_sensitivity_limits
was obtained from linux 3.2 wireless/iwlwifi driver code (iwl-2000.c:115
.barker_corr_th_min_mrc = 390).

Also set BINDIR in Makefile to make it possible to install under
/usr/local/sbin/iwnstats as it require super user.

Reviewed by: adrian
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29800

show more ...

iwn(4): (partially) rewrite A-MPDU Tx path

Generic Tx stats fixes:
- do not try to parse "aggregation status" for single frames; send them
to iwn_tx_done() instead;
- try to attach mbuf / node refer

iwn(4): (partially) rewrite A-MPDU Tx path

Generic Tx stats fixes:
- do not try to parse "aggregation status" for single frames; send them
to iwn_tx_done() instead;
- try to attach mbuf / node reference pair to reported BA events;
allows to fix reported status for ieee80211_tx_complete() and ifnet counters
(previously all A-MPDU frames were counted as failed - see PR 210211);
requires few more firmware bug workarounds;
- preserve short / long retry counters for wlan_amrr(4)
(disabled for now - causes significant performance degradation).
- Add new IWN_DEBUG_AMPDU debug category.
- Add one more check into iwn_tx_data() to prevent aggregation ring
overflow.
- Workaround 'seqno % 256' != 'current Tx slot' case (until D9195 is not
in the tree).
- Improve watchdog timer updates (previously watchdog check was omitted
when at least one frame was transmitted).
- Stop Tx when memory leak in currently used ring was detected (unlikely
to happen).
- Few other minor fixes.

Was previously tested with:
- Intel 6205, STA mode (Tx aggregation behaves much better now).
- Intel 4965AGN, STA mode (still unstable).

PR: 192641, 210211
Reviewed by: adrian, dhw
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D10728

show more ...

iwn: do not try to update node configuration when the node does not exist.

Firmware will just respond with status '0x8' (node does not exist) or
will hang -> cause 'device timeout's (sometimes).

iwn: add promiscuous mode support.

Tested with Intel 6205, STA / MONITOR modes.

Merge ^/head r314420 through r314481.

iwn: fix data rate parsing for Rx radiotap header.

Tested with Intel 6205, MONITOR mode + RTL8188EU, STA mode.

Merge from head

Catch up with head, primarily for the 1.14.4.0 firmware.

Merge ^/head r285153 through r285283.

Attempt to make 5GHz HT/40 work on the 6xxx series NICs.

The 6205 (Taylor Peak) in the Lenovo X230 works fine in 5GHz 11a and 11n HT20,
but not 11n HT40. The NIC goes RX deaf the moment HT40 is con

Attempt to make 5GHz HT/40 work on the 6xxx series NICs.

The 6205 (Taylor Peak) in the Lenovo X230 works fine in 5GHz 11a and 11n HT20,
but not 11n HT40. The NIC goes RX deaf the moment HT40 is configured.
It's so RX deaf that it doesn't even hear beacons and the firmware sends
"BEACON MISS" events. That's pretty deaf.

I tried configuring up the HT40 flags in monitor mode and it worked - so
I assumed that doing the transition from 20 -> 40MHz channel configuration
when going auth->assoc (ie, after the NIC has been partially configured)
is a problem.

So for now, let's just always set them if they're available.

Tested:

* Intel 5300, STA mode, 5GHz HT/40 AP; 2GHz HT/20 AP
* Intel 6205, STA mode, 5GHz HT/40, HT20, 11a AP; 2GHz HT/20 AP

This was pointed out to me by coworkers trying to use FreeBSD-HEAD
in the office on their Thinkpad T420p laptops.

TODO:

* I don't like how the HT40 flags are configured - the whole interop/
protection config should be re-checked. Notably, I think curhtprotmode
is 0 in a lot of cases, which means "no interoperability" and i think
that's busted.

Sponsored by: Norse Corp, Inc.

show more ...

Merge from head@274682

Sync to HEAD@r272516.

IFC @r271694

Bring over some more status codes from the Linux iwlwifi driver.

The (eventual) intention is to create MIB counters for transmitted
frame completion to count how many packets with each status are
tr

Bring over some more status codes from the Linux iwlwifi driver.

The (eventual) intention is to create MIB counters for transmitted
frame completion to count how many packets with each status are
transmitted.

Note the difference between A-MPDU and non A-MPDU status.

Obtained from: Linux iwlwifi/dvm driver

show more ...

Sync to HEAD@r271160.

Fix antenna configuration, microcode version checks and rate selection
in preparation for the 5300 3x3 NIC.

During this particular adventure, I did indeed discover that a whole
swath of things made

Fix antenna configuration, microcode version checks and rate selection
in preparation for the 5300 3x3 NIC.

During this particular adventure, I did indeed discover that a whole
swath of things made little to no sense.

Those included, and are fixed here:

* A lot of the antenna configuration bits assume the NIC has two receive
chains. That's blatantly untrue for NICs that don't.
* There was some disconnect between the antenna configuration when
forming a PLCP rate DWORD (which includes the transmit antenna
configuration), separate to the link quality antenna configuration.

So now there's helper functions to return which antenna configurations
to use and those are used wherever an antenna config is required.

* The 5300 does up to three stream TX/RX (so MCS0->23), however
the link quality table has only 16 slots. This means all of the
rate entries are .. well, dual-stream rates. If this is the case,
the "last MIMO" parameter can't be 16 or it panics the firmware.
Set it to 15.

* .. and since yes it has 16 slots, it only would try retransmitting
from MCS8->MCS23, which can be quite .. terrible. Hard-code the last
two retry slots to be the lowest configured rate.

* I noticed some transmit configuration command stuff is different
based on firmware API version, so I lifted that code from Linux.

* Add / augment some more logging to make it easier to capture this
stuff.

Now, 3x3 is still terrible because the link quality configuration is
plainly not good enough. I'll have to think about that.
However, the original goal of this - 3x3 operation on the Intel
5300 NIC - actually worked.

There are also rate control bugs in the way this driver handles
notifying the net80211 rate control code when AMPDU is enabled.
It always steps the rate up to the maximum rate possible - and
this eventually ends in much sadness. I'll fix that later.

As a side note - 2GHz HT40 now works on all the NICs I have tested.

As a second side note - this exposed some bad 3x3 behaviour in
the ath(4) rate control code where it starts off at a 3-stream rate
and doesn't downgrade quickly enough. This makes the initial
dhcp exchange take a long time. I'll fix the ath(4) rate code
to start at a low fixed 1x1 MCS rate and step up if everything
works out.

Tested:

* Intel 2200
* Intel 2230
* Intel 5300
* Intel 5100
* Intel 6205
* Intel 100

TODO:

* Test the other NICs more thoroughly!

Thank you to Michael Kosarev <russiane39@gmail.com> for donating the
Intel 5300 NIC and pestering me about it since last year to try and
make it all work.

show more ...

MFC @ r266724

An SVM update will follow this.

Merge head

IFC @264767

Add a missing comma between error message definitions.

CID: 1199266
Found with: Coverity Prevent(tm)
MFC after: 1 week

Merge head up to r263906.

Add the bluetooth information structs to the firmware RX statistics message.

It turns out that there's a variant format of the RX statisitcs notification
from the intel firmware. It's even more wha

Add the bluetooth information structs to the firmware RX statistics message.

It turns out that there's a variant format of the RX statisitcs notification
from the intel firmware. It's even more whacked - the non-BT variant has
bluetooth fields; apparently some later NICs return even _more_ bluetooth
related fields.

I'll commit the statistics structure changes here - it's a no-op for the
driver. I'll later teach the driver code to populate a statistics structure
from the received message after reformatting things correctly.

I don't _think_ it's going to fix anything related to sensitivity programming
as the CCK/OFDM (non-11n) fields are in the same place for both formats.
But the HT structure and the general statistics aren't in the same place.

I'll go find some NIC(s) that spit out the other format and when I find one,
I'll go and update the driver to handle things correctly.

Tested:

* Intel 5100 (which returns the legacy, non-BT format)

Obtained from: Linux iwlwifi

show more ...

Merge from head up to r262415.

Fix a typo.