| Age | Commit message (Collapse) | Author |
|---|
|
ok stsp@
|
|
Input and ok jmc@, jsg@
|
|
|
|
|
|
This case will only occur if the IV has been stripped by hardware and
the driver has not cleared the protected bit in the frame header as it
should. Incrementing this counter will make the problem more obvious
when looking at netstat -W output.
No functional change for people who do not work on wifi drivers.
|
|
ok mpi@
|
|
Frames injected from user space carry the DLT_IEEE802_11_RADIO
mbuf tag, and are handled as a special case. Do not fall back
to regular encapsulation while we are in monitor mode and the
frame injected by userspace is found to be invalid.
This fixes an issue when iwx(4) runs in monitor mode with addresses
configured on the interface and leaving 11n/11ac mode directly for
monitor mode. In this case, traffic generated by userspace or the
kernel (such as ICMPv6) would trigger Tx attempts, which in turn
would trigger an attempt to set up a block ACK agreement and then
cause a firmware panic.
This points at a related issue where interface configuration state
is not properly cleaned up while switching into monitor mode.
The 11n/11ac interface config should ideally be cleared completely,
preventing block ack from being initiated.
But preventing the stack from trying to send frames down the regular
Tx path in monitor mode is a good idea in general because drivers may
not handle this very well for various reasons, block ack being just one.
tested by jmc@ and myself on iwx ax200
|
|
ok bluhm@ jca@
|
|
no functional change, found by smatch warnings
ok miod@ bluhm@
|
|
This prevents potential firmware errors in Intel wifi drivers when APs
send an ADDBA request before the driver's state machine has settled
into RUN state.
The driver's addba task would race the driver's newstate task, and the
hardware would see an incorrect sequence of commands.
Ignoring an early ADDBA request is harmless. The AP will retry later.
Reported by zxystd from the OpenIntelWireless project, thanks!
ok phessler@
|
|
ok claudio@
|
|
found by "'(selbs->ni_macaddr)' too small (6 vs 32)" smatch error
ok stsp@ jca@ phessler@
|
|
Just like the 5 GHz channels, 2.4 GHz channels are spaced 5 MHz apart.
40 MHz wide channels hence span channels [N, N + 4] not [N, N + 1].
Adjust our secondary channel range checks accordingly.
|
|
Wide channel configurations not listed in operating class tables of
the 802.11ac spec can trigger regulatory assertion failures in iwm(4)
firmware, and potentially other device firmware.
Ignore non-standard channels configs such that we downgrade to 40MHz
or even 20MHz to make such APs usable, albeit at lower speed.
Found by dlg@ with a mikrotik AP advertising channel configs that do
not appear as such in the spec:
80 MHz: |104|108|112|116|
40 MHz: |primary: 112|secondary above: 116|
Either of these triggered iwm0: 0x000014FD | ADVANCED_SYSASSERT
Fix tested by myself on iwx(4) AX200 and dlg@ on iwm(4) 7260.
Johannes Berg helped with deciphering the error code, thanks!
|
|
feedback and ok jmc@ miod, ok millert@
|
|
Looks like this was removed in rev 1.85 without comment (which may have
been unintentional).
ok stsp@
|
|
Prevents iwm firmware panics and makes association work with 11ac APs
which transmit beacons on channels other than their primary channel.
We would use the wrong channel in such cases, and iwm would request
a bogus channel configuration, which made the firmware unhappy.
Tested by myself on iwm 8265 and florian on iwm 9260.
This issue did likely affect iwx devices, too.
ok mpi@
|
|
New warning -Warray-parameter is a bit overzealous.
ok millert@ tb@
|
|
Actually set rn->best_nss after deciding on a new best rate.
We are now switching between SISO and MIMO rates as intended.
When switching between ratesets, avoid switching directly to the highest
rate in the new rateset, which might be MCS 9 and not work at all from a
distance. Instead, use the most recently determined best rate in the set.
The bit which corresponds to the current best MS will not be set in the
rn->probed_rates[] array while we are probing an MCS other than the best.
Checking for this bit was simply wrong and prevented us from probing the
next rateset unless we managed to successfully probe up all the way
to the highest MCS in the current set.
Also fix errors in debug output.
Tested by bket, florian, Uwe Werler, and myself.
ok bket@
|
|
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@
|
|
found by landry@
|
|
This check was wrong for drivers which report RSSI as a percentage,
such as iwm(4) and iwx(4). Such drivers will now prefer 5GHz with
50% or greater RSSI, as was intended.
ok phessler@
|
|
ok phessler@
|
|
|
|
Based on our existing RA module for 11n.
The main difference is in dealing with 11ac-specific ratesets.
Tx rate selection heuristics remain identical.
Only supports 80MHz channels, for now. 160MHz is left for future work.
ok sthen@
|
|
Add VHT capability and operation IE definitions to ieee80211.h.
Introduce channel flags to identify 80MHz and 160MHz capable channels.
Parse VHT IEs in beacons, announce the driver's VHT capabilities in
probe requests and assoc requests, and hop into 11ac mode after
association to the AP if possible.
Enable VHT by default if the driver announces support for it.
ok claudio@
|
|
|
|
ioctls should use dedicated names for their structs, but SIOCG80211ALLCHANS
duplicated struct ieee80211_channel. We cannot make changes to the kernel's
version of ieee80211_channel while an ioctl is squatting on the struct name.
Helpful guidance from deraadt@
Tested in a ports bulk build by sthen@, and tested by Mikhail.
ok sthen@
|
|
apostrophe.
|
|
Ensure that we supply the access point's DTIM period to firmware after
an active scan, as soon as the next beacon arrives. This prevents the
problems which prompted us to keep active scans disabled in our drivers.
Problem debugged and patch by zxystd from the OpenIntelWireless project.
I made some tweaks regarding TIM parsing, which were reviewed by zxystd.
Johannes Berg from Intel has confirmed to me via IRC that firmware
will misbehave if running with a zero DTIM period.
Tested:
8265: jca, stsp
9260: kettenis (possible fallout observed here; will keep an eye on it)
9650: stsp
ax200: zxystd, kevlo, stsp
ax201: stsp
ok kevlo@ kettenis@
|
|
The original purpose of ieee80211_find_node_for_beacon() was to avoid
storing duplicate nodes with the same source MAC address in a hash table.
Later on, our node table data structure was changed from a hash table
to an RB tree. The RB tree can only store a single node per MAC address.
However, find_node_for_beacon() was kept regardless, now documented to
serve a different purpose.
Its new purpose is to tell apart different nodes which happen to use
the same MAC address and hence cannot both be stored in the RB tree.
The idea is to filter such duplicate nodes out during a scan. But colliding
nodes are told apart by RSSI and channel, and either may change over time.
So this does not really prevent duplicate MAC addresses from causing issues.
The code which decides which node is "better" can erroneously match an
AP against itself, in case the AP uses a hidden SSID. This caused
workarounds for hidden SSID to pile up over time.
Just a bit further down, the code looks up the same node again and
performs all of the intended node state updates. Simply skipping the
ieee80211_find_node_for_beacon() check makes such state updates work.
ok tobhe@
|
|
everyone else seems to use ETHERTYPE_EAPOL, and as a bonus it also
appears to be more correct.
ok deraadt@ stsp@
|
|
when a power-saving client decides to leave our hostap interface.
Prevents a "key unset for sw crypto" panic as we try to send a frame
to a node which is in COLLECT state with its WPA keys already cleared.
We were already clearing the queue which buffers power-saved frames for
the client node. This queue is stored within the node structure itself.
However, the interface has another global queue for frames which need to
be transmitted by the driver to a set of nodes during the next DTIM.
We missed removing frames for a departing node from this global queue.
While here, add missing node refcount adjustments as frames get purged.
Problem reported by Mikolaj Kucharski, who tested this fix for more
than a week with athn(4), with no further panics observed.
|
|
Sending routing messages requires a socket lock which may sleep.
ieee80211_set_link_state() is called from interrupts and timeouts where
sleeping is not allowed. mvs@ pointed out that if_link_state_change()
is already using a task for this reason.
Should fix a witness-related panic reported by cheloha@
ok mvs@ tobhe@ florian@
|
|
allows the driver to take control of the roaming teardown sequence.
This handler allows drivers to ensure that race conditions between
firmware state and net80211 state are avoided, and will be used by
the iwm(4) and iwx(4) drivers soon.
Split the existing roaming teardown sequence into two steps, one step
for tearing down Tx block ack sessions which sends a DELBA frame, and a
second step for flushing Tx rings followed by sending a DEAUTH frame.
We used to queue both frames, expecting to switch APs once both were sent.
Now we effectively expect everything to be sent before we queue a final
DEAUTH frame, and wait for just this frame to be sent before switching.
This already made issues on iwm/iwx less frequent but by itself this was
not enough to close all races for those drivers. It should however help
when adding background scan support to a non-firmware device driver.
Tested, with driver patches:
iwm 8265: Aaron Poffenberger, stsp
iwm 9260: florian
iwm 9560: sthen
iwx ax200: jmc, stsp
|
|
Noticed while testing iwm/iwx roaming patches, where my AP would request
a new Rx BA session when we had already decided to roam away. There is no
need to set up a new Rx BA session with our old AP which we would have to
immediately tear down again anyway.
|
|
These files were unhooked from the build in April 2021.
|
|
'nwid'/'nwkey', the keys will be set at random times when 'join'/'nwkey' is
used. So also stop trying to set IEEE80211_CIPHER_NONE keys on that path.
James Hastings confirms this fixes his '(null node)' panics on run(4). Thanks!
ok stsp@
|
|
and notify drivers when the channel width has changed.
|
|
For the moment we use either the 40MHz rate set or the 20 MHz one,
depending on whether our peer supports 40MHz channels.
If this turns out to be suboptimal we could probe the 40MHz and 20MHz
rate sets separately to detect which one works better.
The same applies to use of the short guard interval (SGI), which is
either always on or off at the moment. Again, probing for this could
be added later if needed.
|
|
Sending frames from ieee80211_node_join_bss() won't work as expected.
I missed that IEEE80211_SEND_MGMT() calls if_start() immediately after
queueing the management frame. This means the probe request is being
sent in a state where, while ic_bss represents our new AP, the driver
did not yet have a chance to move the device over to our new AP.
The auth request for the new AP is sent from ieee80211_newstate() which
runs after the driver has reconfigured the device. If want to send a
probe request to the new AP then we would need to send it at that point,
before the auth frame gets sent.
|
|
Tested by fkr on iwx ax200/ax201 and myself on iwm 8265.
Also tested by florian and bket as part of a larger diff.
ok mpi@
|
|
My assumption that frames which are buffered on the power save
queue were already encrypted was wrong. And the issue which this
change intended to fix is still present (reported by Mikolaj Kucharski).
|
|
sessions entirely in firmware. This will be used by iwx(4).
|
|
action frame subtypes we care about (i.e. those related to 11n block ack).
ok mpi@
|
|
block ack window when a new Tx block ack agreement is established.
In the future this change will allow the iwx(4) driver to initialize this
sequence number such that it corresponds to what the firmware expects.
Note that ba->ba_winstart is set to ni->ni_qos_txseqs[tid] when a new Tx agg
agreement is initiated in ieee80211_node_addba_request(). Unless the driver
resets ba->ba_winstart before ieee80211_addba_resp_accept() runs, which is
what iwx(4) will do, the assignment added with this patch is a no-op.
|
|
Fragmented frames were never of any practical use to us anyway, given that
our net80211 stack does not (yet?) re-assemble them.
Counter-measure against attacks where an arbitrary packet is injected in a
fragment with attacker-controlled content (via an AP which supports fragments).
See https://papers.mathyvanhoef.com/usenix2021.pdf
Section 6.8 "Treating fragments as full frames"
ok mpi@
|
|
|
|
This mitigates an attack where a single 802.11 frame is interpreted as an
A-MSDU because of a forged AMSDU-present bit in the 802.11 QoS frame header.
See https://papers.mathyvanhoef.com/usenix2021.pdf section 3.2.
MAC address validation is added as an additional measure to prevent hostap
clients from sending A-MSDU subframes with a spoofed source address.
An earlier version of this patch was reviewed by Mathy Vanhoef, who spotted
a bug in my original attempt at preventing spoofed addresses.
ok mpi@
|
|
about the offending key. This will hopefully help with debugging.
|
