| Age | Commit message (Collapse) | Author |
|---|
|
ok mglocker@
|
|
|
|
ok mpi@
|
|
Monitor mode was broken by a recent firmware update. Two tweaks make
it work again:
1) The firmware does not like us sending the power-mode command while
in monitor mode and will panic, so simply don't do that.
2) We no longer add two queues while in monitor mode, just one queue
for frame injection. This queue's index will be 1, not 2. Make the
driver expect the correct index to prevent an error when monitor mode
is entered.
tested by jmc@ and myself on iwx ax200
|
|
no functional change, found by smatch warnings
ok miod@ bluhm@
|
|
The Tx rate index stored in ni->ni_txrate is not intended for use
with management frames, yet iwx_tx_fill_cmd() was using it anyway.
Use the minimum basic rate selected within iwx_tx_fill_cmd() instead.
|
|
IFM_AUTO is a media sub-type, not a media mode.
Should fix issues where only a subset of channels were scanned.
Tested:
iwm 8260: millert@
iwm 8265: mglocker@
iwm 9560: gnezdo@
iwx ax200: jmc@
iwx ax210: spiros thanasoulas
iwx ax211: kn@
|
|
Some non-160MHz So+Hr devices were misdetected, causing iwx(4) to select
the wrong firmware image for them.
Patch by Miguel Landaeta
|
|
Current firmware supplies a flush-command response which makes it
unnecessary to poll for empty queues after sending the flush command.
Based on a patch by Mikhail Pchelin
|
|
The previous code did not update the per-band-data length field,
resulting in firmware skipping the VHT information element in the
probe-request frame template.
Patch by Mikhail Pchelin
|
|
Linux only acts on these requests in 11ax mode on 160MHz channels so
we can simply ignore this request for now. Prevents a warning from
being printed when we receive such a request:
iwx0: unhandled firmware response 0x5f6/0x20000008 rx ring 64[3]
Observed on AX210 hardware by bluhm@
|
|
The driver was asking firmware to send probe requests during background
scans without having any SSID selected, which doesn't make sense.
With that fixed I see faster background scans that no longer display
every AP in range in debug logs, while relevant APs always show up.
This is a possible fix for fatal firmware error 0x20002806 which is
known to be related to bad scan commands and appeared with our upgrade
to the -77 firmware API. Not yet confirmed because it is difficult to
trigger this error on purpose.
Apparently this change also repairs stability issues on AX210.
I have never seen such issues first-hand and have no clue how they
might relate to this change. One plausible theory is that our bogus
bgscan command would trigger bad side-effects in firmware.
Tested:
ax200: jmc@, stsp@
ax210: Laurence Tratt, sf@
|
|
The corresponding task_add and task_del calls were operating on different
queues by mistake. Background scan tasks should now get cancelled properly
during driver state transitions.
ok mvs@
|
|
ok stsp@
|
|
from reyk@
|
|
ok stsp
|
|
Fixes firmware error iwx0: 0x20101A28 | ADVANCED_SYSASSERT which would
occur while tearing down the state of our association to the AP.
The problem occurred when we were trying to reconfigure the PHY context
in a way that is incompatible with the TLC configuration. Since we will
always call iwx_deauth() next, which removes the AP station and related
data such as TLC from firmware before updating the PHY context yet again
we can simply skip the redundant PHY context update in iwx_run_stop() to
prevent this firmware error.
A reliable way to reproduce the problem is an attempt to connect to an
11ac access point on a 5GHz channel while the wrong WPA key is set which
happened to me because mpi@ uses a French WPA passphrase.
Problem confirmed fixed by me with this simple reproducer.
Helpful hints provided by Johannes Berg at Linux/Intel, thanks!
|
|
These callbacks were not reachable by mistake. This change is a first step
towards preventing iwx SYSASSERT 0x20101A28 as seen by beck@ and Mikhail
when an 11ac AP switches channel width. The callbacks may still not trigger
after this change. Possibly because APs use channel switch announcements (CSA)
which we currently ignore. We only check the 11n HTOP IE for channel info.
We may eventually need to add CSA support in order to detect channel
width changes in 11ac mode.
No regressions seen by jmc@ on iwx, nor by florian@, millert@ on iwm
|
|
than assuming that it always matches our currently configured channel.
Should prevent problems on 40/80Mhz channels if there is a mismatch.
|
|
|
|
Fixes a firmware panic I encountered while working on firmware upgrades.
|
|
Undocumented and ignored by the Linux driver, too.
Apparently only used by the Windows driver.
Confirmed by Johannes Berg.
|
|
We used to provide beacon-related information only once our station was
associated. New firmware wants to see this information earlier, when are
about to send an AUTH frame. Otherwise SYSASSERT 0x2000011A is raised.
Problem diagnosed with help from Johannes Berg, thanks!
|
|
Firmware expects time in TU units.
Use 900 TU for the session protection timeout, like the linux driver does.
verified with Johannes Berg from Linux/Intel, thanks for the support!
|
|
Required for adding/removing Tx queues on new firmware versions.
Semantics have changed yet again. Good old iwm(4) required manual
removal of related Tx queues when a station is removed from firmware.
At some point iwx(4) firmware removed this requirement and demanded
that queue removal would be done implicitly by firmware instead.
And now the firmware engineers at Intel have again changed their
minds about this, and explicit queue removal is required again.
It is sad that we are being driven through such a marathon of changes
just in order to pick up some firmware security fixes...
|
|
This command is required to set up Rx aggregation on new firmware.
|
|
|
|
MAC context command fields which firmware has been ignoring since the iwm
hardware generation have been repurposed for information related to 11ax.
Just set these fields to zero. Firmware -71 and up will panic otherwise.
|
|
New firmware wants to be told about MIMO antenna configuration via
a separate command, rather than via the good old PHY context command.
|
|
As of this commit iwx will ignore 'ifconfig media' commands where the
user-specified Tx rate resolves to something other than 'autoselect'.
The existing support for forcing a Tx rate was already only partially
working in 11n and 11ac modes. I doubt anyone had a serious use case for
this. If you really need to force a specific Tx rate for data frames
sent by iwx then hack the driver instead of using 'ifconfig media'.
The firmware interface was designed for Tx rate selection in firmware.
Maintaining support for overriding the Tx rate with ifconfig in face of
complicated firmware interface changes such as this rate_n_flags change
is just not worth it. While trying to keep forced Tx rates working on top
of the new rate_n_flags format I accidentally broke the Tx rate used for
managment frames during regular operation, which caused much frustration.
|
|
also add some missing bits found in the Linux driver while here
|
|
|
|
|
|
|
|
The driver will resume in the ACPI thread and run code to wake the device.
If a firmware error occurs then the init task will be scheduled and could
then run in parallel to the wakeup code. This would lead to panics as the
init task ran while we were not yet done with device initialization.
To prevent this problem we now grab the rwlock during wakeup, the same
lock which is used to prevent races between the init task and ioctls.
Problem found by mvs@, who also suggested the fix implemented here and
tested the changes.
ok mvs@
|
|
In if_iwx.c r1.63 / CVS commit ID QzTzJtyPl10L63Yi, I fixed a problem with
connecting to WPA1/TKIP networks. This change introduced a deference of
the 'ni' pointer passed to ic_set_key(). This pointer will be passed in
as NULL in certain situations, such as when WEP is used. Add the missing
NULL check.
reported by and fix tested by matthieu@
|
|
Stop session protection before tearing down firmware state after failure
to authenticate. Firmware will panic if we remove the MAC/PHY binding
while session protection is active.
test + ok kevlo@
|
|
Found by hshoexer and gerhard@, and reported to me by Christian Ehrhardt.
ok gerhard@
|
|
Marking a TID in the bitmask needs |=, not the = operator, duh.
As a result our ba_task only stopped one session even though multiple
sessions were supposed to be stopped. Now driver and firmware had
become out of sync in their tracking of Rx BA session state, and
firmware crashed with sysassert 0x00004472 when the driver later
attempted to start an already active Rx BA session again.
Problem reported by Anton Kasimov.
Thanks to Johannes Berg from Intel who looked up the meaning
of sysassert code 0x00004472 for me.
|
|
This should help with diagnosing device matching bugs. The matching
logic has become increasingly complex. Knowing which firmware file
was selected is useful information which cannot be inferred from the
PCI device ID alone anymore.
|
|
Firmware for these devices was added in iwx-firmware-20220110p0.
On Linux these devices may show up as "AX201", even though they belong
to the AX210 hardware family. Intel's driver can be confusing at times.
Tested by Guilherme M. Schroeder, who previously had a non-working device.
|
|
Firmware can panic if rate flags ask for HT frames in VHT mode.
Version -67 seems to be ignoring what we set here and works either way.
But -66 and below were unhappy on my AX210 device.
Found while investing a bug report by Guilherme M. Schroeder
Fix tested on AX210 and AX200.
|
|
The driver will now actually match on all those new devices, as intended.
Reported by Guilherme M. Schroeder
|
|
wrong MAC address issue spotted by jsg@ and kevlo@
ok kevlo@
|
|
Firmware is available in fw_update(8) as of iwx-firmware-20220110.
Tested for regressions on AX200/AX201 by jmc, kettenis, and myself.
Tested on AX210 by abieber (framework laptop) and myself, both using
a device which loads ty-ao-gf-a0 firmware.
AX210/AX211 devices which load the following firmware files should
work but could not yet be tested due to lack of hardware:
iwx-so-a0-gf-a0-67, iwx-so-a0-gf4-a0-67, iwx-so-a0-jf-b0-64
|
|
There are a few chips which cannot be recognized by PCI ID alone.
Reading device registers is also required to identify such devices.
iwx(4) should now detect AX201 devices requiring the following firmware
images:
iwx-Qu-b0-hr-b0-63
iwx-Qu-b0-jf-b0-63
iwx-Qu-c0-jf-b0-63
iwx-QuZ-a0-hr-b0-67
iwx-QuZ-a0-jf-b0-63
These are already installed in /etc/firmware but have so far been unused.
This is obviously going to cover a range of devices which have not actually
been tested yet. If you have such a device please test and report back.
Tested on previously working AX200/AX201 devices by jmc@ and myself.
Sven Wolf has successfully tested a newly supported device.
Based on an initial patch by Iraklis Karagkiozoglou, thanks!
|
|
|
|
the channel on which a frame was received.
ieee80211_inputm() was expecting that ic->ic_bss->ni_chan would correspond
to the channel which is currently being scanned. This dates back to older
devices which are manually tuned to the next channel by the driver during
SCAN->SCAN state transitions.
However, this approach is very awkward for drivers which scan across a
whole range of channels in firmware. Such drivers had an ugly workaround
in place which tweaked ni_chan for each received frame.
Introduce a channel number field in the Rx info struct which drivers
can use to indicate the channel on which a frame was received.
If this field is set, net80211 will use it instead of using the current
channel of ic_bss. Use this new mechanism in all affected drivers.
Tested by jmc@, sthen@, and myself on iwm(4) and iwx(4).
Changes to iwn(4) and bwfm(4) are the same mechanical changes to get rid
of the ni_chan tweak, and are therefore expected to work.
ok sthen@ dlg@
|
|
VHT capabilities were written into the "common" secion of the firmware
probe request frame template. This section is used on 2GHz and 5GHz bands.
Announcing VHT capabilities on 2GHz makes no sense.
Move them into the 5GHz-only section.
ok sthen@
|
|
ok kettenis@, jca@
|
