| Age | Commit message (Collapse) | Author |
|---|
|
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@
|
|
current best rate, not worse than the rate currently being probed.
This seems to be a more accurate interpretation of the MiRA paper.
The paper says the interval for a rate needs to be updated if the rate's
goodput is worse than that of the "current transmission rate" (see the
"Adaptive probing interval" section). Our implementation interpreted
"current transmission rate" as "rate being probed right now" and adjusted
the interval of the previously probed rate. However, the context of this
section of the paper suggests that "current transmissions rate" intends to
refer to the currently selected best rate for our non-probing transmissions.
testing and ok tb@ jmatthew@
|
|
Media was displayed as e.g. "autoselect (OFDM6)" even though 11n was active
because the current media mode is changed to AUTO for background scanning
and was never switched back to 11N.
ok mpi@ pirofti@
|
|
equals the average measurement, i.e. if the standard deviation is zero.
Change comparisons of current measurement to the average measurement
from >= to > in the "channel becomes good" check, and from <= to < in
the "channel becomes bad" check.
The paper's equations are written with <= and >= and thus so was our
implementation. But checking for equality makes no sense in the context
of event-triggered probing: The intention is to react to changes in
channel quality, which occur for instance when a laptop moves around
or when RF noise comes and goes. When the current measurement and the
average measurement are equal, this means channel quality has not
changed at all and starting to probe for a new rate is not necessary.
We should probably even add a margin to avoid triggering probing
based on small fluctuations, but this can be done later.
ok tb@
|
|
current measurement, not before.
The MiRA paper mentions these calculations in the order we implemented them.
But the moving average and standard deviation depend on the value of the
goodput measurement, not the other way around.
ok tb@
|
|
ok stsp@
|
|
ok tb@ tobhe@ mpi@
|
|
theoretical throughput of another MCS.
Packet loss indicates that this MCS isn't necessarily going to be the best
choice, so do not allow lossy throughput measurements to win unchallenged.
ok tb@
|
|
When checking if a previously probed MCS had a better measurement,
do not allow the current MCS being probed to win right away.
Otherwise we may end up sticking to our current Tx rate even
if further probing would yield a better result.
ok tb@
|
|
Avoids unnecessary re-probing in case a timeout had been scheduled already.
tweak + ok tb@
|
|
ok tb@
|
|
Resolves XXX comments regarding block-ack support.
with simplification tweak from + ok tb@
|
