| Age | Commit message (Collapse) | Author |
|---|
|
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@
|
|
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@
|
|
We were echoing back all RSN capabilities announced by our peer, even
for features which we don't support.
One such feature is Management Frame Protection (MFP). If we announce this
capability then the peer sends us encrypted management frames which won't
be processed. One symptom of this is that we fail to negotiate block ack
with APs that support MFP.
Only echo the RSN capabilities which we support, i.e. key replay counters.
Handle MFP and PBAR bits here as done elsewhere. Neither of these features
is enabled yet at run-time. As far as I can tell, the remaining RSN caps are
not supported by drivers (e.g. SPP A-MPDU) or won't be supported (outdated
WEP->TKIP transition support). The corresponding bits should always be clear.
Problem with 0 input block ack sessions found by sthen@ and robert@
Fix tested by sthen@, robert@, phessler@, and kmos@
ok phessler@ kmos@
|
|
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@
|
|
Fixes urtwn(4) repeated DEAUTH and subsequent loss/restoration of link.
It was a great dhclient(4) stress test. Note that urtwn(4) is the first
and so far only device whose *_set_key() function returns EBUSY.
Debugging hints and ok stsp@
|
|
async task(s).
Makes dhclient(8) much happier.
Suggestions and ok stsp@, jmatthew@
|
|
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@
|
|
This change results in no binary change, it just makes things more clear.
OK deraadt
|
|
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.
|
|
With input from stsp@.
ok stsp@
|
|
update the WPA group cipher value in interface configuration data.
Code relying in this value will otherwise get the group cipher wrong.
One obvious example is ifconfig which now displays the negotiated group
cipher rather than always displaying the default value 'ccmp'.
Fixes a regression where athn(4) no longer worked against WPA2 APs which
use TKIP as a group cipher for compatibility with WPA1.
Problem reported by Tim Chase.
ok kettenis@
|
|
"new" API.
ok dlg@ tobhe@
|
|
use-after-free when a wireless device is detached.
Pseudo-driver detach hooks may end up calling back into the driver, e.g. via
an ioctl. So these hooks must run before net80211 data structures are freed.
Reported by ratchov@ who saw the following trace when athn(4) detached while
it was part of a trunk(4) interface. The trunk(4) detach hooks were run after
ieee80211_ifdetach() had been run by athn_detach(). These hooks called back
into the driver via athn_ioctl() which now operated on freed memory.
uvm_fault(0xffffffff81facdd0, 0xb14, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at ieee80211_ba_del+0x20: cmpl $0,0x2c(%r15)
ddb{0}> ieee80211_ba_del(0) at ieee80211_ba_del+0x20
ieee80211_newstate(ffff8000000c1048,0,ffffffff) at ieee80211_newstate+0xb51
athn_stop(ffff8000000c1048,1) at athn_stop+0x70
athn_ioctl(ffff8000000c1048,80206910,ffff800014d63800) at athn_ioctl+0x15b
ifnewlladdr(ffff8000000c1048) at ifnewlladdr+0x100
trunk_port_destroy(ffff800000589800) at trunk_port_destroy+0x320
if_hooks_run(ffff8000000c10b8) at if_hooks_run+0xb0
if_deactivate(ffff8000000c1048) at if_deactivate+0x24
ether_ifdetach(ffff8000000c1048) at ether_ifdetach+0x1d
athn_detach(ffff8000000c1000) at athn_detach+0x17b
athn_pci_detach(ffff8000000c1000,1) at athn_pci_detach+0x2a
config_detach(ffff8000000c1000,1) at config_detach+0x156
config_detach_children(ffff8000000b7500,1) at config_detach_children+0x58
pci_detach_devices(ffff8000000b7500,1) at pci_detach_devices+0x24
ppb_hotplug_remove(ffff800000033e00) at ppb_hotplug_remove+0x35
taskq_thread(ffffffff81f4bd48) at
ok mpi@ ratchov@
|
|
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@
|
|
|
|
Patch by Mikolaj Kucharski
|
|
complete group key renewal immediately. The old code would not install
the new group key unless a station in need of re-keying was present.
Tested by Mikolaj Kucharski on bugs@
|
|
associated clients and before switching over to the new group key,
purge the AP's global power-save frame queue. This queue may contain
group-addressed frames which were encrypted with the old group key.
Clients will not be able to decrypt such frames, and purging the queue
prevents a panic ("key unset for sw crypto") where athn(4) attempts to
transmit such frames from its software beacon alert interrupt handler.
This is another variant of the problem fixed in CVS commit ufdFLtcLfPRrbshM.
Panic reported and fix tested by Mikolaj Kucharski 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@
|
|
Association to some access points breaks without the ESS capability bit.
Apparently I misunderstood something.
Reported by krw@ and tb@
|
|
The ESS capability bit should be set if the transmitter is an AP.
Association requests are sent by clients.
ok jca@
|
|
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@
|
|
Purging this queue prevents a panic which occurs when a WPA2-enabled athn(4)
hostap interface is reconfigured while this queue contains frames.
In hostap mode, this queue contains group-addressed (broadcast) frames
which are buffered for clients sleeping in powersave state. Frames on
this queue are transmitted when it is time to send another beacon, at
which point in time sleeping clients wake up to receive such frames.
The panic message is "key unset for sw crypto", which can be explained as
follows: Group keys are cleared when the interface goes down. The beacon Tx
interrupt handler gets triggered by hardware when the interface comes back
up. This handler attempts to encrypt the queued frames for transmission,
resulting in the above panic since the group key has been zeroed out.
This panic has been observed with athn(4) by Jan Stary and Ted Patterson,
and Ted has confirmed that this patch fixes the problem.
ok kettenis@ (with the caveat that it's been a long time since he put our
AP-side powersave support into a working state)
|
|
ok deraadt@
|
|
This flag restricts a wireless driver to MCS0 - MCS7 for both transmission
and reception. It can be set to work around packet loss in 11n mode caused
by unused antenna connectors on a MIMO-capable wireless network device.
man page tweak from tracey@
ok deraadt@
|
|
switching ratesets when probing.
Fixes iwm(4) switching from MCS 15 down to MCS 0, rather than switching
to a comparable rate in the next rateset, such as MCS 7. This wasn't
supposed to happen but did because of a MiRA implementation bug.
ok jmatthew@
|
|
suggested by jmatthew
|
|
maximum rate of our current rateset.
ok tb@
|
