| Age | Commit message (Collapse) | Author |
|---|
|
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@
|
|
ok stsp
|
|
When describing the equation for computing a sub-frame error rate (SFER) the
MiRA paper uses "hardware retries" to refer to the number of times a frame,
which eventually failed entirely, was retransmitted (a situation our drivers
would call "txfail"), and "nBad" to refer to frames which were "received
with errors" (and this is what our drivers would call "retries").
Because of my misunderstanding of the wording used in the paper our
SFER equation ended up with the "retries" and "nBad" variables swapped.
Swapping them back produces more meaningful results with reasonable
frame loss percentages based on the counters passed in by drivers.
ok tb@
|
|
Actual QoS support could be added to net80211 in the future, but for now we
only use QoS frames for A-MPDU aggregation. Without QoS support, sending
non-aggregated QoS frames does not actually buy us anything and makes it
harder to look at packet captures and tell whether frames sent by an OpenBSD
machine were in fact aggregated or not.
Tested on iwn(4) by jmc@, paco@, bket@, paco@, and Lauri Tirkkonen
|
|
When sizing a memory allocation for a probe response frame, the AP used
the SSID length stored in the node structure which represents the client,
but used the actual length of the SSID when copying it into the frame.
If the actual length is sufficiently large this will result in corruption
of an adjacent mbuf on the free list since m->m_next will be overwritten
with data written to the tail of the probe response frame.
Bad things happen later on when the adjacent mbuf is used. Sometimes
the corruption is detected by mbufpl's use-after-free checking, at
other times we end up crashing somewhere in the network stack.
To prevent such a mistake from occuring again I am removing the 'ni'
argument from ieee80211_get_probe_resp() altogether. It is not needed.
A quick workaround is to configure a short SSID.
Debugged with help from claudio, kettenis, and dlg.
ok claudio
|
|
reconnect to the AP
OK stsp@
|
|
immediately instead of waiting to (randomly) switch away and switch
back.
Found by martijn@
OK stsp@
|
|
that will also trigger background scans, remain with the current AP.
Avoids ping-pong in environments where APs are tuned for low transmit
range, such as 36c3.
ok phessler benno
|
|
ok phessler benno
|
|
ok phessler
|
|
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@
|
|
Firmware-based Tx retries were disabled when it was found that MiRA
makes better choices while probing with a constant Tx retry rate.
Before that change, high Tx rates looked better than they actually
were. The change resulted in less retries and thus higher throughput
because a lower, but actually working, initial Tx rate eventually
became the preferred choice.
However, disallowing retries at lower rates also resulted in increased
amounts of observable packet loss, especially while the connection to
the AP was still fresh and bad Tx rates had not been discovered yet.
To get the best of both worlds, use a constant Tx rate for retries while
MiRA is probing and otherwise allow firmware fallback to lower rates.
tested by Tracey Emery, pamela, jasper, and myself, on 7265/8265/9260
|
|
|
|
by an ioctl if the driver had not yet initialized the channel map.
Crash reported by nayden@
ok sthen@
|
|
From now on, this behaviour must be explicitly enabled with ifconfig join "".
ok sthen jcs deraadt
|
