| Age | Commit message (Collapse) | Author |
|---|
|
Spotted by waddlesplash from haiku-os.org
|
|
ok kettenis@, jca@
|
|
VHT MCS and 80MHz channels can now be used.
Other 11ac features such as larger aggregates are left for later work.
Tested:
3160: stsp
7260: florian, jmatthew
7265: rfreeman, mlarkin, landry, Peter J. Philip
8260: bket
8265: jturner, Marcus MERIGHI, stsp
9260: florian, matthieu, stsp
9650: kmos, sthen
ok sthen@
|
|
feedback and ok tb@ jmc@ ok ratchov@
|
|
This device is part of the 9560 chip family. With a small device-specific
quirk we can make iwm(4) attach and provide a working wifi interface.
Problem reported and fix tested by Joao Victor.
|
|
Required to prevent breakage of roaming with new Intel firmware on 9k devices.
Tested:
8265: Aaron Poffenberger, stsp
9260: florian
9560: sthen
|
|
watchdog will trigger a device timeout if a particular Tx queue gets stuck
while other Tx queues keep working.
The Linux driver is using a similar workaround for "stuck queues".
I have only observed this problem on iwx(4) hardware but it won't hurt
to add this workaround to iwm(4) as well.
|
|
According to 11n MCS index tables our maximum data rate is now
300 Mbit/s at MCS 15, excluding protocol overhead. I have measured
up to 200Mbit/s of effective throughput on clean 5GHz channels.
The driver enables use of 40MHz channels automatically as long as the
access point announces support for such channels in its beacons.
In case 40MHz transmissions fail we ask firmware to retry with a
20MHz transmission.
There is no integration with ifconfig yet, so use of 40MHz is not yet
displayed there. In the meantime, tcpdump(8) can be used to check if
the current access point supports 40MHz:
tcpdump -n -i iwm0 -v -y IEEE802_11_RADIO -s 4096 type mgt and subtype beacon
Channel width is displayed in the HT operation information element, where
a 40MHz channels looks like this: htop=<40MHz chan X:Y ...>
Tested:
7260: florian, bcallah
7265: landry
8260: bket
8265: stsp, abieber, Matthias Schmidt, Josh Rickmar, empee on mastodon
9560: stsp
|
|
ic_bss->ni_bssid has already been overwritten once we enter
iwm_newstate() to perform the state transitions necessary for
roaming to our new access point (RUN->AUTH->ASSOC->RUN).
We do however use the BSSID in commands sent to firmware.
Cache our BSSID in struct iwm_node such that firmware commands
keep using the old BSSID while we are still tearing things down.
Switch to the new BSSID only once we start back up in iwm_auth().
This should be consistent from the firmware's point of view.
ok mpi@
|
|
the size of the response we receive for MCC_UPDATE commands (even
though we aren't doing anything with this response yet).
With the correct expected response length this time. The driver needs
to expect the maximum response size, not sizeof() the response struct.
The actual response size depends on the number of channels stored
in the "world" regulatory profile of the device.
ok sthen@
|
|
This seems to cause "could not init LAR" errors on some devices.
Reported by dv@ (8265) and sthen@ (9560)
|
|
the size of the response we receive for MCC_UPDATE commands (even
though we aren't doing anything with this response yet).
|
|
|
|
It seems Intel saw a risk of eventually running out of firmware capability
support and API support flags, so yet another such mechanism was added.
If you want to know which variant of a command needs to be used there are
now at least three places to check for related information.
|
|
|
|
This updates firmware for 3165, 3168, 7265, 8260, 8265, 9260, 9560 devices.
Other devices did not receive firmware updates from Intel.
New firmware images should contain revelant fixes for fragattacks:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html
Running fw_update(1) may be required before rebooting into a new kernel.
sysupgrade(8) will take care of this.
When reporting issues (I am sure there will be new "fatal firmware errors"
for some people) please enable 'ifconfig iwm0 debug', reproduce the error
once more, and include the full dmesg in your bug report.
Important changes required for new firmware:
- Support new variants of several existing firmware commands just
because Intel loves adding new features and changing the commands.
- Implement the 'clear persistence bit' workaround for 9k devices to
avoid potential issues during suspend/resume.
- Recognize Mobile Country Code update notifications for the regulatory
domain, like iwx(4) does.
- Handle PHY context updates more like the Linux iwlwifi driver does.
Some devices need an add/remove dance if the band has changed.
- For 9560, configure SoC latency parameters after booting firmware.
- Handle critical temperature notifications by shutting the device down.
- Use only antenna B for single-antenna Tx on 9k devices (matches what
Linux and FreeBSD do; Likely only matters if Bluetooth is active, but
who knows, Git logs and comments are the only documentation we have).
Other small fixes:
- Fix various scan command parameters. Some fixes were taken from iwx(4).
- Don't send probe requests when scanning passive channels. Experimentation
has shown that this will make 9k devices crash after associating to an AP.
This same fix does not seem to work on iwx(4) devices, where active scan
is disabled for the same reason, and it is not yet clear why.
- Fix firmware reloading after parsing the firmware image has failed.
- Flushing Tx rings will fail if the AP disappears. Don't make any noise
about that in dmesg, instead gracefully reset the device and continue.
Tested:
7260: florian
3168: kevlo
7265: stsp, mlarkin
8260: bket
8265: stsp, benno
9560: stsp, steven
|
|
before stopping a Tx block ack session. This aligns us more closely
with how the Linux iwlwifi driver is doing things.
Also, reset the device if an errors occurs in the block ack session task.
Fixes auto-recovery after such errors.
Prompted by firmware error reports from kettenis@ and Matthias Schmidt.
Doesn't fix the reported issues completely. I will keep investigating.
Tested:
7265: stsp
8265: Matthias Schmidt
9260: phessler, kettenis
|
|
Makes packets go swoosh swoosh swoosh. Welcome to actual 802.11n!
Tested:
7260: dv, florian
7265: trondd, dv, landry, stsp
8260: bket
8265: Matthias Schmidt, stsp
9260: kettenis
9560: phessler, stsp
|
|
- HT protection settings (this was already implemented)
- ERP (11g) protection setting
- short slottime setting
- short preamble setting
- EDCA (QoS) parameters
All of these parameters are communicated in beacons and hardware is
now kept up-to-date with them.
Prompted by a problem report from Christian Ehrhardt regarding ERP.
Tested:
iwn 6205: stsp, Josh Grosse
iwm 7265: trondd
iwm 8265: stsp, Matthias Schmidt
iwm 9260: phessler
iwx ax200: stsp, jmc, gnezdo
|
|
re-enable de-aggregation of A-MSDUs in net80211 for all drivers capable
of 11n mode. This can provide improved Rx performance if the access point
supports transmission of A-MSDUs nested in A-MDPUs.
iwm(9) 9k and iwx(4) devices de-aggregate A-MSDUs in hardware.
Neither our drivers nor the net80211 stack were prepared to handle this.
Add two Rx-info flags which drivers can use to avoid having subframes which
arrived in the same A-MSDU rejected as duplicates in the net80211 input layer:
IEEE80211_RXI_HWDEC_SAME_PN allows the same CCMP packet number for a series
of subsequent frames. IEEE80211_RXI_SAME_SEQ allows the same 802.11 frame
header sequence number for a series of subsequent of frames.
Handle A-MPDU reordering on iwm 9k and iwx devices, based on code from iwlwifi.
Rx block ack window information is provided by firmware. So far this info was
ignored by drivers and reordering of A-MPDU subframes happened twice: Once in
firmware, and again in net80211.
Tested:
iwm 7260: bcallah, dv
iwm 7265: mpi, trondd, Matthias Schmidt
iwm 8260: bket, Marcus MERIGHI
iwm 8265: stsp, tracey, Uwe Werler
iwm 9260: phessler, matthieu
iwm 9560: stsp, Uwe Werler
iwx ax200: jmc, stsp
iwx ax201: stsp
|
|
Tested by:
iwm 7260: florian
iwm 7265: TronDD, Aaron Miller, stsp
iwm 8260: bket
iwm 8265: matthieu, tracey, naddy, Dave Voutila, jcs, Mathieu Kerjouan,
Matthias Schmidt, stsp
iwm 9260: matthieu, phessler, Darren VanBuren
iwm 9560: Uwe Werler
|
|
Pointed by and ok jsg@
|
|
Its value is conflicting with an effort to standardize TX flags fields of
the radiotap header from Mathy Vanhoef.
This flag used to indicate the presence of a specific hardware queue used
by WME but is unchecked.
ok sthen@, kn@
|
|
During a transmit burst, e.g. while tcpbench is running, iwm and iwx will
queue up to 224 frames on the Tx ring.
Rate control will make decisions a lot more often than just every 224 frames.
Which means that results were reported and evaluated even if they did not
correspond to the most recently chosen rate, spoiling the data available
to the rate control algorithm.
Prevent this problem by only reporting frames which match the currently
chosen Tx rate.
ok mpi@
|
|
This fallback was added in r1.235 because we disabled firmware-based
Tx retries in that commit. Firmware-based Tx retries were re-enabled
in r1.291 so manual fallback to CCK rates is no longer required since
the firmware will do this for us if needed (at a cost of a single retry).
|
|
There is no need to schedule a task to send this command and wait for
a response. Linux iwlwifi also sends this command async.
tested by myself and benno
|
|
No functional change.
|
|
- use a distinct station ID for monitor STA
- set station type to "general purpose" instead of "link"
- use "any address" (zero) as station address instead of broadcast address
- use the inject monitor Tx queue, and do not enable regular Tx queues
- accept multicast frames
With this I can reliably switch back and forth between BSS and monitor modes.
Tested on 7265 and 8265.
ok mpi@
|
|
iwm(4) releases resources whenever hardware signals Tx completion for a
frame at Tx queue index 'N'. It has been observed that we sometimes get
an interrupt for frame 'N - 2' followed by an interrupt for frame 'N',
with no interrupt being received for frame 'N - 1'.
Whenever this occurred a later decision to roam to another AP would fail
since AP node references for frames affected by missing interrupts were
never released. Another side-effect was an mbuf leak.
The problem was first observed at 36c3 and debugged there with bluhm@.
ok tobhe@
|
|
Firmware-based Tx retries were disabled when it was found that MiRA
makes better choices while probing with a constant Tx retry rate.
Before that change, high Tx rates looked better than they actually
were. The change resulted in less retries and thus higher throughput
because a lower, but actually working, initial Tx rate eventually
became the preferred choice.
However, disallowing retries at lower rates also resulted in increased
amounts of observable packet loss, especially while the connection to
the AP was still fresh and bad Tx rates had not been discovered yet.
To get the best of both worlds, use a constant Tx rate for retries while
MiRA is probing and otherwise allow firmware fallback to lower rates.
tested by Tracey Emery, pamela, jasper, and myself, on 7265/8265/9260
|
|
interrupt vectors and mapping events (RX on queues, commands,
mgmt frames) to those vectors. For now we keep the existing
behaviour, establish a single vector and map all events to it.
Makes my Intel NUC 8i5BEH 9560 work
Tested by jcs@ on a 9560 (w/ MSI-X)
Tested by deraadt@ on a 9260 (w/ MSI-X)
Tested by phessler@ on a 8260 (w/o MSI-X)
ok stsp@
|
|
Joint work with patrick@
Parts lifted from FreeBSD's r354492, r354502, r354508, r354516, r354508.
Firmware is available with fw_update(1) thanks to sthen@
7265 device tested by myself (still works)
8260 device tested by phessler@ (still works)
9260 devices tested by Travis Cole and myself
9560 devices tested by jcs@, mlarkin@, kevlo@, guenther@
Some 9560 devices have known issues. Those are being worked on.
ok patrick@
|
|
Based on FreeBSD r345002 and Linux 44fd09dad5d2b78efbabbbbf623774e561e36cca.
Tested for regressions by phessler@ (8260), kevlo@ (3165), and myself (7265)
ok kevlo@
|
|
Tested by phessler@, Tracey Emery, and myself on 8260 and 8265.
|
|
ok patrick@
|
|
Patch by Imre Vadasz
Tested for regressions by phessler and Krystian Lewandowski
No very obvious mistakes found by kettenis@
ok patrick@
|
|
Patch by Imre Vadasz.
Cross-check and pcireg.h tweak by kettenis@
ok patrick@
|
|
Aware Regulatory (LAR) mode and LAR is disabled according to NVM.
Patch by Imre Vadasz.
ok patrick@
|
|
ok patrick@
|
|
Required for new firmware images because the command queue index has changed.
The driver remains compatible with our current firmware images for now.
Tested by benno, jan, kevlo, florian, jmatthew, Tracey Emery
ok jmatthew
|
|
Ask firmware to retry at a constant Tx rate instead of successively lower
rates. This provides better feedback to Tx rate scaling algorithms in our
kernel and thus increases Tx throughput, especially on clean channels.
Make the driver fall back to CCK rates on 2 GHz channels if 11n MCS
don't work. Previously, we were relying on firmware to do this for us.
Tested on 7260, 7265, 8260, 8265 by me, jcs@, tb@, solene@, Matthias Schmidt.
|
|
The iwm(4) driver will now roam between access points which share an SSID.
Use 'ifconfig iwm0 debug' and 'tail -f /var/log/messages' to watch it do so.
Tested by several people in various iterations.
As usual, let me know if you run into issues.
ok phessler deraadt
|
|
instead of stashing responses in one single buffer in the softc.
Allows getting rid of a tsleep() which protected the single buffer.
Tested by myself and Carlos Cardenas on 7260, 7265, and 8260.
hurray ok deraadt@
|
|
When bringing the interface down, the driver now waits for any running
tasks to complete before shutting down the hardware.
Based on suggestions by dlg@ and mpi@
Tested by myself, Manuel Giraud, anton@, and jcs@
|
|
a process context. In interrupt context, schedule the init task
instead of calling iwm_stop() directly.
ok procter@
|
|
it is still scheduled before tearing down firmware state in iwm_unauth().
This change does not address any particular known issue, but matches what
Linux does. If it causes any problems, let me know.
ok tb@
|
|
call ieee80211_end_scan() directly from interrupt context.
This extra task was already part of the original driver code from 2015 (but
with a workq instead of a task). Back then, the driver had to run two separate
scan commands in succession, for 2 GHz and then 5 GHz. Which is why a task
was used, since sending another command requires a sleepable context.
Nowadays, with our current firmware, a single scan command is sufficient
so there is no code path which needs to sleep when the scan ends.
ok mpi@
|
|
|
|
Instead, maintain firmware state in accordance to the current net80211
state by adding/updating/removing MAC config, PHY->MAC binding, and the
station in the firmare station table (we only add the AP to this table).
By eliminating the iwm_stop() call from iwm_newstate_task(), this change
prepares future work on fixing races between ioctls and tasks scheduled
by this driver.
There's a known new occasional fatal firmware error which results in
the message "iwm0: could not remove MAC context (error 35)"
I expect to fix this soon.
tested by tb@ on 7265, by jcs@ on 8265, and by myself on 7260/7265/8260
ok mpi@ tb@
|
|
The IFF_RUNNING flag in struct ifnet serves the same purpose.
ok mpi@ kettenis@ deraadt@
|
