| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Sending data frames to nodes in other states is wrong since the node's
data structure might not be set up properly in such states.
This could explain occasional "key unset for sw crypto" panics observed
with athn(4) hostap interfaces.
Problem reported and fix tested by Mikolaj Kucharski.
|
|
statistics have been gathered for a candidate Tx rate. The goal is
to avoid Tx rate choices that might turn out to be too optimistic.
In practice this only affects the case where we probe upwards. If the
current Tx rate starts seeing loss we will still scale down very quickly.
Based on a larger collection of patches by Christian Ehrhardt.
I have made stylistic tweaks for consistency.
Tested:
iwn 6205: stsp, Josh Grosse
iwm 7265: stsp
iwm 8265: Matthias Schmidt
iwm 9260: phessler
|
|
- 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
|
|
11ac/n/a/g/b as applicable. Fixes an issue where hostap would end up
running in the rather meaningless MODE_AUTO unless a mode was explicitly
configured with ifconfig.
Found while investigating issues reported by trondd testing my athn RA patch.
ok deraadt@
|
|
IEEE 802.11 sequence numbers wrap around at 0xfff, not 0xffff.
ok phessler@ kevlo@
|
|
value is only used after checking if it's valid or not.
CID 1502921
OK stsp@ phessler@
|
|
If ieee80211_input_ba_flush() was called when there was nothing to flush,
the (already pending) gap wait timeout was re-armed.
This is only correct if we flush at least one packet. Otherwise packets
that arrive at a constant rate of about 4-5 packets per second would
extend the gap-wait timeout until the block ack window fills up.
In extreme cases this can result in packets being queued for almost 20s.
Fix this by returning immediately from ieee80211_input_ba_flush() if
the first packet in the reordering buffer is missing.
This prevents the timeout from being re-armed.
Patch by Christian Ehrhardt. Tested by me on iwm(4) 7265.
|
|
ieee80211_input_ba_flush() for updating ba->ba_winend.
Required for an upcoming ieee80211_input_ba_flush() fix.
Patch by Christian Ehrhardt who found one instance of this problem in
ieee80211_input_ba_seq(). I spotted another in ieee80211_ba_move_window().
|
|
Written by Christian Ehrhardt and myself, based on ieee80211_mira.c
but with significant changes.
The main difference is that RA does not attempt to precisely measure
actual throughput but simply deducts a loss percentage from the
theoretical throughput which can be achieved by a given MCS.
Unlike MiRa, RA does not use timeouts to trigger probing.
Probing is triggered only by changes in measured throughput.
Unlike MiRA, RA doesn't care whether a frame was part of an A-MPDU.
RA simply collects statistics for individual subframes. This makes reporting
very easy for drivers and seems to work well enough in practice.
Another difference is that drivers can report multi-rate retries properly
via ieee80211_ra_add_stats_ht(mcs, total, fail) which can be called
several times before ieee80211_ra_choose() selects a new Tx rate.
There is no reason any issues could not be fixed in ieee8011_mira.c but
I felt it was a good moment to burn the house down and start over.
And since this code diverges from how MiRA is described in the research
paper applying the "MiRA" label becomes inappropriate.
|
|
ok gnezdo@ semarie@ mpi@
|
|
Patch by zxystd from the OpenIntelWireless project (drivers for macOS)
ok tobhe@
|
|
Bug was introduced by my previous commit to this file.
ok tobhe@
|
|
Ethernet header size. Avoids spurious "input packet decapsulations failed"
errors in 'netstat -W' with A-MSDU enabled (currently disabled in-tree).
Problem observed and fix verified on iwm(4) 8260 by me and 7260 by tobhe.
ok phessler@ tobhe@
|
