Commit Graph

238 Commits

Author SHA1 Message Date
Adrian Chadd
ba2c1fbc03 Revert the wifi ifnet changes until things are more baked and tested.
* 286410
* 286413
* 286416

The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.
2015-08-08 01:10:17 +00:00
Gleb Smirnoff
79d2c5e857 Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
  the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
  driver about any changes: number of wlan(4) interfaces, number of them
  in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
  driver experiences errors and can not attribute them to any specific
  interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
  now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:

https://wiki.freebsd.org/projects/ifnet/net80211

Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.

Differential Revision:	D2655, D2740
Sponsored by:	Nginx, Inc.
Sponsored by:	Netflix
2015-08-07 11:43:14 +00:00
Adrian Chadd
54991f37c9 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.
2015-07-07 03:51:29 +00:00
Adrian Chadd
3233d0c654 First cut at attempting to buffer frames until we see a beacon.
The iwn(4) firmware forgets most of its channel state after an RXON
command.  This means that any beacons its seen on passive 5GHz channels
are forgotten upon an association/authorisation request.
This unfortuantely means that 5GHz association almost always fails -
the assoc and/or auth frames are dropped with a status of "passive
channel, haven't seen a beacon yet." (0x90.)

So:

* add an xmit queue, global, to buffer frames
* modify the xmit path to use the mbuf tag from net80211
  to specify raw frame details
* buffer xmit frames from both raw and non-raw paths
* if a beacon is seen in the RX path, schedule a taskqueue to
  send said frames and un-buffer things.
* flush frames during state change back to INIT, or NIC
  down/up/detach.

This isn't the final shape I'd like this to be in but it certainly
is better than 5GHz "not working at all".

Tested:

* Intel 5100, STA mode (before spilling coffee)
* Intel 5300, STA mode (after spilling coffee)

Story:

* This has been bugging me at work for months, which I just
  worked around by throwing an ath(4) into my Lenovo T400 cardbus
  slot.

* Our ops director discovered indeed FreeBSD runs well on the
  Lenovo T420p, except for that pesky 5GHz thing.  So now developers
  also can have a T420p running FreeBSD to do work with.
  Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked."

* .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4)
  NIC to put in a laptop - and I snapped.

Thus, the reason this is actually work related.

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.
2015-06-19 01:44:17 +00:00
Adrian Chadd
5d97054765 Disable bgscan for now - it interferes with 11n activity and general
stability.

I'll re-enable it once the scan overhaul is done - the NIC itself
can do bgscan, but not how we're doing it.

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.
2015-06-04 05:37:07 +00:00
Gleb Smirnoff
272f6ade9b Change three methods in struct ieee80211com, namely ic_updateslot,
ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com,
not to the ifnet.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 19:53:29 +00:00
Gleb Smirnoff
9dbbcd5d9a Use ic_printf() instead of if_printf(). 2015-05-25 15:12:23 +00:00
Gleb Smirnoff
e6feb66faf Store softc in ic_softc and access it without using struct ifnet.
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 15:09:17 +00:00
Gleb Smirnoff
c8550c0278 Make net80211 drivers supply their device name to the net80211 layer, so
that the latter doesn't need to go through struct ifnet to get their name.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 13:51:13 +00:00
Adrian Chadd
64b9bdcf18 Various iwn(4) fixes.
* simplify channel logic for determining RF gain setting in scan setup
* don't set TX timer on error
* free node references for unsent frames on device stop
* set maxfrags to IWN_MAX_SCATTER-1 (first segment is used by TX command)
* add missing IWN_UNLOCK() from interrupt path when the hardware
  disappears.
* pass control frames to host
* nitems() instead of local macro

Tested:

* Intel 5100, STA mode

PR:		kern/196264
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2015-05-16 05:59:25 +00:00
Eitan Adler
f05e369aa2 iwn, wlan: fix typos
Fxi tow typos

Obtained from:	DragonFlyBSD
MFC after:	3 days
2015-04-10 20:55:17 +00:00
Adrian Chadd
bbd01a4100 Remove a private copy of ieee80211_add_ssid().
PR:		kern/196116
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2014-12-19 01:41:51 +00:00
Gleb Smirnoff
c8dfaf382f Mechanically convert to if_inc_counter(). 2014-09-19 03:51:26 +00:00
Adrian Chadd
9dd099b274 Implement htprotmode handling.
This is separate to 11g protection - the default is to RTS protect
11n frames, including A-MPDU frames.

Tested:

* Intel 5100, STA mode
2014-09-08 07:16:00 +00:00
Adrian Chadd
339503ab41 (more) correctly account TX completion status for A-MPDU session frames.
The rules turn out to be:

* for non-aggregation session TX queues - it's either sent or not sent.
* for aggregation session TX queues - if nframes=1, then the status reflects
  the completed transmission.
* however, for nframes > 1, then this is just a status reflecting what
  the initial transmission did.  The compressed BA (immediate or delayed)
  may not have yet been received, so the actual frame status is in the
  compressed BA updates.

Whilst here, I fiddled with debugging and formatting a bit.

There's also RTS attempts (what the atheros chips call "short retries")
which weren't being logged and they aren't yet being used in the rate
control statistics updates.  For now, at least log them.

TODO:

* This still isn't 100% correct! So I have to tinker with this some more.
  (The failures aren't always failures..)
* Extend the rate control API in net80211 so it can take both short and
  long retry counts.

Tested:

* Intel 5100, STA mode
2014-09-08 03:16:28 +00:00
Adrian Chadd
f7efe7e999 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
2014-09-08 03:12:42 +00:00
Adrian Chadd
18aabe98d0 Inform the rate control code if a single frame AMPDU transmission succeeds
but has some retries.

Without this, single frame transmission in AMPDU will always look like
it succeeded fine, and thus AMRR will think it's totally fine to just
keep upping the rate upwards.

Now, this is still not quite right!  For multi-frame aggregates the
completion happens in two parts - the TX done and the BA received.
The driver is currently double accounting those a little - there's no
way to say to the rate control code "I completed X frames, Y worked fine,
there were Z retries." And it's a bit odd with iwn, as the firmware
retransmits frames for us so we don't get to see how many retransmits
happened; only that it took longer than normal.  I may have to extend
the rate control API to properly track that.

So this may keep the rate lower than it should be, but that's better
than keeping it higher than it should be.

Tested:

* 5100, STA mode
2014-08-28 07:44:59 +00:00
Adrian Chadd
bc0203e201 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.
2014-08-28 03:18:27 +00:00
Adrian Chadd
8f1d4b2dd6 Do the iwn(4) panic reinitialisation under IWN_LOCK().
I've checked each of the functions being called and there's either a
_locked version or it's supposed to be called with IWN_LOCK() held.
2014-08-03 03:51:33 +00:00
Adrian Chadd
43f2450f5d Shadow RAM support is apparently not at all working on the Intel 5300 Wifi.
Tested:

* Intel 5300 3x3 wifi
* Intel 5100
2014-06-14 06:54:03 +00:00
John Baldwin
0f698bd800 - Don't check the dma map address for a static DMA mapping against NULL
to determine if the mapping is valid.
- Don't explicitly destroy the dmap map for static DMA mappings.

Reviewed by:	adrian
2014-06-13 19:40:02 +00:00
Gavin Atkinson
9194f39024 Remove debugging printf that crept in in r266770.
Submitted by:	adrian, nwhitehorn
MFC after:	2 weeks
2014-05-27 23:05:12 +00:00
Gavin Atkinson
a94ec03f8f Add support for the Intel Centrino Wireless-N 105 chipset.
MFC after:	2 weeks
Relnotes:	yes
2014-05-27 19:39:57 +00:00
Edward Tomasz Napierala
8acd0be199 Make iwn(4) able to get itself back into working condition after
"fatal firmware error" happens.  Previously it was neccessary to reset
it manually, using "/etc/rc.d/netif restart".

Approved by:	adrian@
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
2014-05-22 15:29:25 +00:00
Edward Tomasz Napierala
43c2aa0f86 Erm, revert r266544; wrong tree. 2014-05-22 15:00:32 +00:00
Edward Tomasz Napierala
983aa498d5 Make iwn(4) able to get itself back into working condition after
"fatal firmware error" happens.  Previously it was neccessary to reset
it manually, using "/etc/rc.d/netif restart".

Approved by:	adrian@
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
2014-05-22 14:56:34 +00:00
Adrian Chadd
fa5ff59a78 Fix the required calibration flags for the Centrino 1000 NIC. 2014-05-10 05:56:10 +00:00
Christian Brueffer
48a098e360 Add a missing comma between error message definitions.
CID:		1199266
Found with:	Coverity Prevent(tm)
MFC after:	1 week
2014-04-13 18:51:39 +00:00
Adrian Chadd
26bb40d804 Handle the newer-style bluetooth message format from the (at least)
Centrino 2230 firmware.

This fixes the general statistics block to be actually valid.

I've verified this by contrasting the output of iwnstats before and
after the change.  The general block is now correct.

Tested:

* Intel 5100 (old format stats message)
* Intel 2230 (new format stats message)
2014-03-04 08:01:56 +00:00
Adrian Chadd
0840bbcdf3 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
2014-03-01 02:57:22 +00:00
Adrian Chadd
49f79cfd5f Track and expose the latest statistics from the firmware.
Tested:

* Intel Centrino 6205
2014-02-24 02:37:04 +00:00
Adrian Chadd
892ebbbd84 Reserve a bit for statistics debugging. I'll hopefully use it soon. 2014-02-24 02:13:20 +00:00
Adrian Chadd
2e9afe9597 Fix a typo. 2014-02-23 23:13:53 +00:00
Adrian Chadd
d31cb7480b Fix indentation. 2014-02-23 21:43:15 +00:00
Gavin Atkinson
e4b141d4eb Add support for the Intel Centrino Wireless-N 135 chipset.
MFC after:	2 weeks
2014-01-08 13:59:33 +00:00
Kevin Lo
5945b5f5ab Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.
The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.

Reviewed by:	adrian, rpaulo
2014-01-08 08:06:56 +00:00
Adrian Chadd
25a9c4c83a Move the retune notification print to a debug print.
Yes, I still have to do the retune.  But I'm giving in to many people
pestering me (very gently!) about this.

Tested:

* Intel Centrino 6205
2014-01-05 00:46:31 +00:00
Marius Strobl
e0c758686c - Probe with BUS_PROBE_DEFAULT instead of 0.
- Remove clearing PCIM_CMD_INTxDIS; pci(4) will do that as appropriate since
  r189367.

MFC after:	1 week
2013-12-30 16:46:50 +00:00
Marius Strobl
7b23a8b2c0 - There's no need to keep track of resource IDs.
- Simplify MSI allocation and release. For a single one, we don't need to
  fiddle with the MSI count and pci_release_msi(9) is smart enough to just
  do nothing in case of INTx.
- Don't allocate MSI as RF_SHAREABLE.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.

MFC after:	1 week
2013-12-29 19:32:27 +00:00
Adrian Chadd
13b535ff9c Fix the Intel 6150 support.
This chip doesn't require the temperature sensor offset, either v1 or
v2.  Doing so causes the initial calibration test to fail.

Tested:

* Intel Centrino 6150
2013-12-28 05:50:53 +00:00
Adrian Chadd
929f6e3c8b Add some initial support for the Intel 6235.
Tested:

* Intel 5100
* Intel 6235

Obtained from:	mav, others
2013-12-09 03:40:02 +00:00
Adrian Chadd
a22cfd04e7 Refactor out the scan id and scan vap as part of the scan work.
Make the scan state optional - we'll obviously need a vap, but we now
won't require the scan state.  the only thing the scan state is needed
for is to check for the list of SSIDs to scan - which we can now
just plain ignore by passing in NULL as the scan state pointer.

Tested:

* Intel 5100 (STA)
2013-12-07 08:32:15 +00:00
Adrian Chadd
6c214017d0 Add a channel parameter to iwn_scan().
This is in preparation for being able to use iwn_scan() to do an off
channel scan to reset the RF tuning.

It should be a no-op.

Tested:

* Intel 5100 (STA)
2013-12-07 08:25:24 +00:00
Adrian Chadd
b860b2a9aa Refactor out the scan channel to be assigned early on in iwn_scan()
rather than it all being a mess of 'c' and 'ic->ic_curchan'.

Tested:

* Intel 5100 (STA)
2013-12-07 08:20:24 +00:00
Adrian Chadd
92d7ab9562 Begin fleshing out some code to handle tracking PLCP error rates
in preparation for the scan based retune logic.

The linux iwlwifi driver does a rescan (onto a non-active channel)
to force an RF retune when the PLCP error rates exceed a certain threshold.

* Add code to track HT PLCP rate errors;
* Separate out the PLCP error count fetch and update so the delta
  can be used when checking for PLCP error rates;
* Implement the PLCP error logic from iwlwifi;
* For now, just print out whenever the error rate exceeds the
  threshold.

The actual scan based retune will take a bit more effort; the scan
command code right now assumes that a scan state is passed in.
This does need to change to be more flexible (both for this and
in preparation for scanning multiple channels at once.)

Tested:

* 5100 (STA mode)
* 2200 (STA mode)
* 2230 (STA mode)
2013-12-07 08:03:10 +00:00
Adrian Chadd
90a4274834 Add some PLCP thresholds from Linux iwlwifi driver in preparation for
working on some RF tuning issues.

The linux iwlwifi driver has these thresholds which they use to see
if there are PLCP errors over a certain interval.  If they hit this,
they trigger a single-channel (different from active channels!)
scan to retune the RF front-end.
2013-12-07 06:45:09 +00:00
Adrian Chadd
352c016bc1 * Sort the copyright lines by date
* Ok ok, I've touched this enough to claim part of it.
2013-12-02 05:45:11 +00:00
Adrian Chadd
fee842aa2a 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
2013-12-02 03:59:45 +00:00
Adrian Chadd
d27bb17b9c Log the rx ring offset as part of the debug message. 2013-12-02 03:49:33 +00:00
Adrian Chadd
30ca148cf7 Oops - fix bad indent. Sorry! 2013-12-02 03:43:37 +00:00