WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/net80211?h=master 2021-03-26T10:18:55Z 2021-03-26T10:18:55Z stsp stsp@openbsd.org 2021-03-26T10:18:55Z urn:sha1:01c40890b297bb64e37dd3f9f04abe0a780090ad IEEE 802.11 sequence numbers wrap around at 0xfff, not 0xffff. ok phessler@ kevlo@ 2021-03-25T16:23:39Z mestre mestre@openbsd.org 2021-03-25T16:23:39Z urn:sha1:d3ab93457784742bd95fc71e948dc3d3d5ffb48a value is only used after checking if it's valid or not. CID 1502921 OK stsp@ phessler@ 2021-03-23T12:03:44Z stsp stsp@openbsd.org 2021-03-23T12:03:44Z urn:sha1:8d36f12dbf9ce28c23b5e1c40158c943a0cc961e 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. 2021-03-23T11:58:38Z stsp stsp@openbsd.org 2021-03-23T11:58:38Z urn:sha1:04b94a2b6c8c78d979dee3d6a5797f9f7fc2fa84 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(). 2021-03-12T16:26:27Z stsp stsp@openbsd.org 2021-03-12T16:26:27Z urn:sha1:7611cb38512c61cc20d6799ca9f13cb7524a33a6 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. 2021-03-10T10:21:47Z jsg jsg@openbsd.org 2021-03-10T10:21:47Z urn:sha1:678831be5eff0bcb5217b54d0dcfb6698acf8411 ok gnezdo@ semarie@ mpi@ 2020-12-10T12:53:03Z stsp stsp@openbsd.org 2020-12-10T12:53:03Z urn:sha1:19a418d8d3bd4e9d1862882cd917c048f47d99d8 Patch by zxystd from the OpenIntelWireless project (drivers for macOS) ok tobhe@ 2020-12-10T12:52:49Z stsp stsp@openbsd.org 2020-12-10T12:52:49Z urn:sha1:d0faa20ec7872ce2c90ae0b877daee4daf471053 Bug was introduced by my previous commit to this file. ok tobhe@ 2020-12-09T21:54:11Z stsp stsp@openbsd.org 2020-12-09T21:54:11Z urn:sha1:e9230c34af2e44519a525203cd65ace35a9e9638 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@ 2020-12-09T15:50:58Z stsp stsp@openbsd.org 2020-12-09T15:50:58Z urn:sha1:043677ea2893d06e4ca76def9ce68893cc969508 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@