| Age | Commit message (Collapse) | Author |
|---|
|
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@
|
|
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@
|
|
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@
|
|
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@
|
|
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@
|
|
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@
|
|
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.
|
|
and notify drivers when the channel width has changed.
|
|
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@
|
|
- 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
|
|
IEEE 802.11 sequence numbers wrap around at 0xfff, not 0xffff.
ok phessler@ kevlo@
|
|
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().
|
|
ok gnezdo@ semarie@ mpi@
|
|
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@
|
|
iwm(4) 9k and iwx(4) need more work before AMSDU can be enabled.
These devices decapsulate A-MSDU in hardware and required changes to
make this work with our drivers and stack seem to be non-trivial.
Problems reported by phessler@
ok phessler@
|
|
in the buffer until the next frame is received.
Found by and fix from Christian Ehrhardt
ok stsp@
|
|
the underlying problems have since been fixed. Using A-MSDUs results
in improved download speeds with APs that support them.
tested by robert@
|
|
buffer. Restart the gap timeout if the buffer is not empty
after we flush out some of the packets.
Found by and fix from Christian Ehrhardt
ok stsp@ phessler@
|
|
Some APs continue to send QOS packet for the same tid (with normal ack
policy). Make those packets go through BA reordering to advance the
sequence number counter in the BA agreement and prevent performance loss
due to a gap wait later on.
Found by and fix from Christian Erhardt
ok stsp@ phessler@
|
|
ok deraadt@
|
|
Make ieee80211_input_ba() skip one missing frame at the head of the Rx block
ack (BA) window once the rest of the window has filled up with pending frames.
This avoids having to wait for the BA window gap timeout handler to run in
order to make progress in such situations.
Simplify the BA gap timeout handler by deferring the actual flushing of the
BA window buffer to the regular input path. The timeout handler now simply
advances the BA window across any missing frames at the head of the window,
and if_input() is no longer called from the context of this timeout handler.
The window will be flushed once another frame arrives.
Packet loss under streamy traffic conditions and during Rx bursts is reduced.
Much less stuttering, more stable tcpbench, and easier flight in Minecraft.
tested by phessler@, Martin Vahlensieck, jmc@, Uwe Werler, and myself
|
|
Fix code which was still looking for this flag at the old location.
The 'hidenwid' feature was slightly broken as a result: The SSID was leaked
in probe responses to wildcard probe requests. There are other trivial ways
of snooping a "hidden" SSID however so this is not a big deal.
Problem reported by Mogens Jensen.
|
|
There are access points out there which insist on establishing a block ack
agreement with the client before the WPA handshake can complete. This is sad,
but we cannot operate against such APs if we require the handshake to complete
first.
This reverts CVS commit 4wXCjWU3qNtIX7gW.
Problem reported and fix tested by Brandon Sahlin on bugs@
|
|
Some drivers, such as ral(4), cannot provide the IV required for a replay
check because hardware strips the IV before passing the frame to the driver.
Which means frames with the RXI_HWDEC flag but without the 'protected' bit
set in the frame header must be passed without any further verification and
without updating the last-seen packet number.
All we can do is hope that these devices perform replay checking correctly.
Fixes a regression where some ral(4) devices would fail to receive packets
on encrypted networks. Reported and fix confirmed by Hendrik Meyburgh.
ok mpi@
|
|
So far, drivers using hardware CCMP decryption were expected to keep the
most recently seen CCMP packet number (PN) up-to-date, and to discard frames
with lower PNs as replays.
A-MPDU subframes may legitimately arrive out of order, and the drivers skipped
CCMP replay checking for such frames. Re-ordering happens in ieee80211_inputm(),
after the driver is done with a frame. Drivers cannot tell replayed frames
apart from legitimate out-of-order retransmissions.
To fix this, update the PN value in ieee80211_inputm() after subframes have
been reordered into their proper sequence. Drivers still perform replay checks
but they no longer have to worry about updating the last seen PN value.
The 802.11 spec confirms that replay checking is supposed to happen after
A-MPDU re-ordering.
Tested by jmc@, benno@, solene@, and myself with the following drivers:
athn(4), iwn(4), iwm(4), wpi(4), urtwn(4)
ok solene@
|
|
ok stsp@
|
|
Some peers will eagerly try to negotiate block ack (asking us to reserve
buffer space) before they are done authenticating themselves. No thanks.
Just let them try again later.
ok mpi@
|
|
as well as pulling frames off the Rx block ack reordering queue, when
an incoming frame above the current seqnum window forces us to slide
the window forward, potentially losing frames within the old window.
Leaving the seqnum window out of sync with the queue would cause needlessly
long stalls in traffic until the window moved again for some other reason.
Problem observed on lossy wifi whenever netstat -W indicated an increasing
"input block ack window slides" counter. With this fix, stalled frames can
be observed only for a relatively short amount of time whenever one or more
frames in the current window are lost.
ok mpi@
|
|
which we only send if an SSID is already configured. Thus a
scan only creates beacons. Especially on bwfm(4) only beacons
frames are faked, there are no probe responses. When a node
first is created, ni_rssi is 0, which is always smaller than
rxi_rssi, and it wil never be set for nodes on 5 GHz. Thus we
should always set ni_rssi if it is 0.
Tested by jan@ tobhe@
ok stsp@ deraadt@
|
|
PS-poll and BA-req frames are in fact being processed.
Do not count such frames as discarded control frames.
OK phessler kn mpi
|
|
AP on a new channel. Not doing so leads to a disconnect because AP
messages on the new channel are ignored.
|
|
This reduces drops caused by the ifq pressure drop mechanism and hence
increases throughput. Such drops are visible with e.g. 'netstat -dnI iwm0'.
Not all affected drivers have been tested yet but these changes are largely
mechanical and should be safe. As usual, please report any regressions.
With help from dlg@ and mpi@
Problem found by robert@
Tested by robert, jmc, Tracey Emer, Matthias Schmidt, florian, Björn Ketelaars
ok mpi@
|
|
Prevents WPA APs from appearing as non-WPA APs to the AP selection logic.
The decision whether or not to parse the IE was made as a side-effect
of a check for the highest mutually supported version of WPA.
We can safely assume that all our drivers support WPA versions <= 2
and parse the IE regardless of whether WPA is currently active or not.
ok mpi@
|
|
In particular, add Tx block ack session management to net80211, with
enough funcionality to support Tx aggregation on devices which perform
A-MPDU subframe scheduling in firmware.
Make use of the iwn(4) firmware Tx scheduler to build A-MPDUs.
net80211's QoS support code is now enabled and used by Tx aggregation.
A-MSDU frames inside A-MPDUs have been tested and work in principle.
For now, this feature is disabled because unfair TCP connection sharing
was observed during testing, where bursts of TCP Ack frames for a single
tcpbench(1) connection arriving in A-MSDUs made other TCP connections stall.
Switch off support for A-MSDUs inside A-MPDUs on the Rx side as well.
Tested on iwn chipsets 1000, 4965, 5100, 5300, 2200, 6200, 6205, 6300
(committed version of tested diff has all debug printfs removed)
tests/ok benno kmos mlarkin kevlo
|
|
in ieee80211com's ic_flags because we haven't been paying attention to
them (they're not in the same place in the code and hence easy to miss).
Move them to a dedicated variable to avoid this problem in the future.
Add a new 'stayauth' nwflag which can be set to let net80211 ignore
deauth frames. This can be useful when deauth frames are being
persistently spoofed by an attacker. Idea from beck@
ok beck@ phessler@
|
|
Don't accept A-MPDUs if not in RUN state, and don't accept them from
unassociated clients in hostap mode.
ok jmatthew@ kevlo@
|
