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.

iwn: fix data rate parsing for Rx radiotap header.

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

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

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

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

Add a missing comma between error message definitions.

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

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

Fix a typo.

Fix indentation.

Add some initial support for the Intel 6235.

Tested:

* Intel 5100
* Intel 6235

Obtained from: mav, others

Overhaul the iwn(4) scan infrastructure to be slightly more "correct"
for these chipsets.

* Correctly set the active/passive flag in the scan request - this is
NOT a "is the channel active|passive

Overhaul the iwn(4) scan infrastructure to be slightly more "correct"
for these chipsets.

* Correctly set the active/passive flag in the scan request - this is
NOT a "is the channel active|passive"; it's to do with whether we
have an SSID to actively scan for or not. The firmware takes care
of the active/passive setup of the channel.

* Calculate the active/passive dwell time based on the beacon interval
and the channel mode, rather than using a hard coded value.

* For now, hardcode the scan service_time. It's defined as:

31:22 - number of beacon intervals to come back onto the home channel
for;
0:21 - time (microseconds) to come back onto the home channel for.

When doing an active scan when the NIC is active (whether we're associated
or not - it only matters if we've setup the NIC to a destination or not)
this determines how much time to stay on the home channel for when
scanning. We can tune this based on the amount of active traffic.

For now it's 4 beacon intervals and 100 microseconds.

* Fix the "good crc threshold" setting. It differs based on the NIC
firmware. Some older firmware required a workaround; the later
firmware instead treats the field as a flag.

* Enforce that we are not sending a scan command if one is already
pending. Any time this is done is a bug and it absolutely needs
to be fixed - so be very loud.

* Add the SCAN flag to a few debug messages that are scan related but
only occuring under STATE.

Now, this does get noisy when you're scanning in an actively busy 2GHz
network as the firmware (for reason I don't quite yet understand) seems
hell bent on staying on some passive channels longer than it should.
However, it should eventually recover and complete the scan.

This is a work in progress; please let me know if things get stuck or
if things improve!

Tested:

* intel centrino 2200
* intel centrino 2230
* intel 6200
* intel 5100
* intel 4965 (gets upset, but that's a known issue)

Obtained from: linux iwlwifi

show more ...

Fix undefined behavior: (1 << 31) is not defined as 1 is an int and this
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.

This fix is not ideal as it assumes a 32 bi

Fix undefined behavior: (1 << 31) is not defined as 1 is an int and this
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.

This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.

A similar change was made in OpenBSD.

Discussed with: -arch, rdivacky
Reviewed by: cperciva

show more ...

Add definitions for the microcode TLV flags entry (type 18.)

This isn't used anywhere just yet!

Obtained from: Linux iwlwifi

This is "scan_flags" from Linux.

Add some new driver definitions as part of the chip support updates:

This is a no-op for now!

* Add a new flag value for "there are no extra bits" for some random
field;

* Add a definition for t

Add some new driver definitions as part of the chip support updates:

This is a no-op for now!

* Add a new flag value for "there are no extra bits" for some random
field;

* Add a definition for the maximum number of calibration entries in
the calibration data cache in iwn_softc. It's not yet used.

* Add regulatory bands for the 2030 NIC.

Submitted by: Cedric Gross <cg@cgross.info>

show more ...

Remove trailing whitespace.

Submitted by: Cedric Gross <cg@cgross.info>

add 0x8b, lifted from Linux iwlegacy/commands.h

This is "STA invalid". I saw it during some 4965 testing (kern/183260)
and I still have no idea what is causing it.

Obtained from: Linux drivers/net/

add 0x8b, lifted from Linux iwlegacy/commands.h

This is "STA invalid". I saw it during some 4965 testing (kern/183260)
and I still have no idea what is causing it.

Obtained from: Linux drivers/net/wireless/iwlegacy

show more ...

Add #ifdef wrapper around definitions so they aren't included multiple
times.

Add in some definitions required for later iwn(4) device support.

This also clarifies a few existing fields.

Tested:

* Intel 5100

Submitted by: Cedric GROSS <cg@gross.info>

Break out the iwn(4) device IDs into if_iwn_devid.h, as well as add
IDs for new devices.

* Add new device IDs
* Extend the ID probe code to include the newer range of bits used
by later model devi

Break out the iwn(4) device IDs into if_iwn_devid.h, as well as add
IDs for new devices.

* Add new device IDs
* Extend the ID probe code to include the newer range of bits used
by later model devices

Tested:

* Intel 5100, STA mode

TODO:

* Test on Intel 4965, just to be sure

Submitted by: Cedric GROSS <cg@gross.info>

show more ...

iwn(4) debugging improvements.

* Add in some new register debugging under IWN_DEBUG_REGISTER
* Make IWN_DEBUG an option now for building. I'll chase this up
with a commit to 'options' soon.

Subm

iwn(4) debugging improvements.

* Add in some new register debugging under IWN_DEBUG_REGISTER
* Make IWN_DEBUG an option now for building. I'll chase this up
with a commit to 'options' soon.

Submitted by: Cedric GROSS <cg@cgross.info>

show more ...