Age | Commit message (Collapse) | Author |
|
No fnuctional change.
|
|
A malicious AP could trick clients into connecting to the malicious AP
instead of the desired AP. All frames would then be sent in the clear.
This problem was found and reported by Mathy Vanhoef who also provided
an initial patch which we improved together.
|
|
ok mpi@
|
|
rateset with the AP is calculated only after the association response was
received, which is too late. Fix rates when an AP is selected after a scan.
ok mpi@ tb@
|
|
associated nodes with particular properties: 11b-only ("non-ERP") nodes,
nodes requiring long slot time, nodes using WPA, nodes not supporting 11n,
nodes currently dozing in powersave state, and nodes with a pending group
key update confirmation.
These counters weren't properly maintained.
There are bugs in the stack where these counters and actual node properties
got out of sync. This is exposed by panics which are supposed to help us
catch such bugs. But these panics don't provide real clues.
Instead of maintaining global counters forcing us to hunt refcounting bugs,
count nodes with the property in question on demand, by iterating over all
nodes and checking their state.
This is cheap since we'll never have more than 100 nodes cached, and none of
the cases where we need such information is in a performance critical path.
Prevents panics in hostap mode reported by Lauri Tirkkonen on bugs@ last
year (https://marc.info/?l=openbsd-bugs&m=147513817930489&w=2) and also
encountered by my 11n APs ("panic: bogus non-HT station count 0").
tested by Lauri, tb@, and myself
ok mpi@ tb@
|
|
number from the 802.11-2007 standard to the 802.11-2012 standard.
|
|
from the client parameter set, rather than from the AP parameter set.
ok mpi@
|
|
by drivers to pass default EDCA parameters to firmware instead of passing
local hardcoded values.
ok millert@
|
|
These are either due to driver bugs or rounding errors in fixed point math
but can be dealt with gracefully and don't occur often (only one instance
of this problem has been reported in the wild so far).
Turn related panics into debug printfs.
With 'ifconfig athn0 debug' the kernel now prints notifications about
out-of-range SFER values in dmesg. Compile a kernel with 'option MIRA_DEBUG'
to get a dump of driver stats in dmesg as well.
This change should prevent an undesirable panic reported by Peter Kay,
though it does not actually address the root cause of the problem.
ok tb@
|
|
cancels timeouts, and resets driver stats. Call it when probing has
finished instead of manually resetting only probing state.
Right now this is only called once but an upcoming change will reuse it.
|
|
chain. Else this function will sometimes signal end of AMSDU frame too early.
Patch by Imre Vadasz.
ok mpi@ phessler@
|
|
Without this fix it was impossible to use WPA1 without also making use of the
wpaciphers option to enable TKIP. Problem noticed by pirofti@.
ok mpi@
|
|
The existing code (from damien@) already took care of freeing related buffers
but because block ack state was not reset we were still trying to use these
buffers if the node sent another A-MPDU. This problem only affects 11n hostap.
Fixes kernel crash reported by Timo Myyra on bugs@
|
|
titled "Predicting and Abusing WPA2/802.11 Group Keys" by Mathy Vanhoef.
https://media.ccc.de/v/33c3-8195-predicting_and_abusing_wpa2_802_11_group_keys
If an attacker knows the WPA group key the attacker could inject a unicast
frame by sending a group-encrypted frame to the AP with addresses set as:
addr1 (receiver): ff:ff:ff:ff:ff:ff
addr2 (source): MAC of attacker
addr3 (target): MAC of victim client
The AP would forward this frame as unicast, re-encrypted with the pair-wise
session key of the victim client. But an AP should not forward such frames.
Guessing a WPA group key used by an OpenBSD AP is hard because our random
numbers are actually random. So we are not vulnerable to this attack but
we are fixing the forwarding path anyway.
ok mpi@ tb@
|
|
No functional change.
The previous name was chosen at a time when I could not yet anticipate
what this function would really end up doing.
The new name should make this function's purpose more obvious, especially
where it appears at strategic places in driver code.
|
|
requiring 11n wireless drivers to provide an ic_ampdu_rx_start() function.
The athn(4) driver won't need this function since the hardware receives
A-MPDU and sends block ack without setting up anything.
|
|
clear HT capabilities stored in its node cache object.
A node may switch from 11n mode to 11a/b/g mode.
If we don't clear HT capabilities from the cache the node will
be mistaken as 11n-capable after reassociation.
ok phessler@ mpi@
|
|
|
|
|
|
Fixes problems with timing of frame transmissions which caused packet loss.
tested by myself and tb@
ok phessler@ mpi@ tb@
|
|
that Linux clients will decide to use 11n mode.
ok phessler@
|
|
For now we flip-flop only between non-member protection and non-HT protection.
Running a HT network without protection would require monitoring environmental
conditions (e.g. foreign beacons) which make HT protection necessary.
The ic_update_htprot driver function becomes optional because it won't be
needed by all drivers. Only call it if the driver has set a function pointer.
ok tb@
|
|
Return early and do nothing if the node is already in COLLECT state upon
entry to this function.
|
|
function, not afterwards. Drivers now know whether a joining node supports HT
which helps with setting up state such as which Tx rate to use.
|
|
It was creating a corrupt beacon element by ommitting one byte.
Fix this and fill the element with actual data from the ic_bss node instead
of filling it with zeroes, allowing future 11n hostap to announce the current
HT protection mode correctly.
|
|
including removing the 802.1x configuration from the card.
Found while coming home from CCC Congress.
OK stsp@
|
|
ok phessler@ tb@
|
|
which are not supported by both peers, as already done elsewhere.
ok phessler@ tb@
|
|
It is time for this legacy of WEP to die (remember WEP?).
The 802.11-2012 standard says:
The use of TKIP is deprecated. The TKIP algorithm is unsuitable for
the purposes of this standard.
TKIP has numerous problems. One of which is that TKIP allows a denial of
service attack which can be triggered by any client. Report 2 Michael MIC
failures to a TKIP AP to trigger "TKIP countermeasures". The AP is now
required by the 802.11 standard to lock everyone out for at least 60 seconds.
The network will remain unusable for as long as such MIC failure reports
are sent twice per minute.
TKIP remains available for interoperability purposes, for now.
It must be enabled manually with ifconfig(8).
Prompted by discussion with Mathy Vanhoef.
ok deraadt@ sthen@ reyk@
|
|
we're not in 11n mode. This will allow tcpdump to show the mode correctly.
ok mpi@
|
|
Waiting more time does not buy us anything and makes a denial of service
a tiny bit easier.
Suggested by Mathy Vanhoef.
|
|
Client-side bug found while investigating TKIP countermeasures.
|
|
The previous code would disable the AP until next reboot upon MIC failure.
Instead, disable the AP for 60 seconds, as required by the 802.11 standard.
I randomly added a bit of time (up to 120 seconds total) just because we can.
Problem reported by Mathy Vanhoef, thanks!
ok deraadt@
random input reyk@
|
|
The previous approach with an extra timeout was dumb (and of course untested).
Additional fixes include:
- Take HT protection settings into account when determining whether RTS is used.
- Stop probing the current rateset as soon as measurements become worse.
- Properly move probing timeouts for bad rates further into the future.
Tested with MIMO-enabled iwm(4) (MCS 0-15) and also iwn(4) (MCS 0-7 only).
Early versions also tested by phessler@ and bmercer@, and more testing by tb@.
ok tb@
|
|
ok tb@ phessler@
|
|
ok stsp@
|
|
This algorithm was designed for use with MIMO and Tx aggregation.
This is joint work with tb@, who helped with all the tricky math bits.
Additional help with testing by phessler@, mpi@, and jmatthew@.
I believe this is now ready for wider testing, and for future work to
happen in-tree.
A paper which explains the algorithm can be found at:
http://www.cs.ucla.edu/wing/publication/papers/Pefkianakis.MOBICOM10.pdf
Roughly, this algorithm attempts to keep track of the current "goodput"
(the effective data rate) for each MCS. It converges towards a rate which
gets the most bits per second transmitted with least loss.
Occasionally, frames will be steered to different rates to probe for changes.
(The algorithm does not send frames on its own. It only advances whenever
the driver has sent a frame.)
Time-based probing to adjacent MCS rates occurs periodically.
This is similar to what AMRR does, except that eventually mira will
try out multi-antenna modes as well.
Event-based probing happens when a sudden change in goodput is detected.
I've chosen to make downwards probing fast, and upwards probing slow.
(The paper does not specify such a preference.)
This means it should react quickly to worsening conditions and pull the
rate down (perhaps to the lowest possible rate). It should then raise
upwards slowly on a rate-per-rate basis as conditions improve again.
In my testing this works as intended as I keep moving a laptop outside
and inside the AP's range.
Not linked to the build yet.
ok mpi@ kettenis@
|
|
the same as FreeBSD is using and is already recognized by third party tools.
For this file a documentation change is all that's needed.
ok kettenis
|
|
command to the firmware and waits for confirmation. This command can
fail and there was no way we could recover from such an error.
Allow drivers to return EBUSY from their ic_ampdu_rx_start() handler to
tell the stack not to send a confirmation just yet. The stack provides
functions which the driver can call to accept or refuse the request.
There is no functional change yet. This just shuffles code around so
drivers may insert themselves into the process.
ok mpi@
|
|
in the node structure. This should be useful for iwm(4) in the future.
ok phessler@
|
|
shaves about 5k off an amd64 GENERIC.MP kernel
|
|
Fixes dBm values displayed by 'ifconfig scan' with several drivers.
ok mpi@ jca@
|
|
a slight priority in cases where good matches exist in either band.
ok sthen@
|
|
A flag which indicates whether HT has been negotiated with a node,
and the current Tx MCS value we use for a node.
This grows struct ieee80211_nodereq. Applications using it must be recompiled.
ok mpi@
|
|
bytes). This is what other OS have been doing for years. In our stack this
feature was present but disabled at compile-time by an #ifdef.
This is a low risk change because drivers were already required to use RTS
whenever the AP set the USE_PROTECTION flag in ERP elements of its beacons.
This change allows for reasonable throughput on loaded 11g networks
whereas before they were practically unusable.
tests and ok phessler@
|
|
bands in a single scan offload request. This will be used by iwm(4) soon.
ok kettenis@, earlier version ok phessler@
|
|
still lingering in the node cache. This could cause an AID to be assigned
twice, once to a newly associated node and once to a different node in
COLLECT cache state (i.e. marked for future eviction from the node cache).
Drivers (e.g. rt2860) may use AIDs to keep track of nodes in firmware
tables and get confused when AIDs aren't unique across the node cache.
The symptom observed with rt2860 were nodes stuck at 1 Mbps Tx rate since
the duplicate AID made the driver perform Tx rate (AMRR) accounting on
the wrong node object.
To find out if a node is associated we now check the node's cache state,
rather than comparing the node's AID against zero. An AID is assigned when
a node associates and it lasts until the node is eventually purged from the
node cache (previously, the AID was made available for re-use when the node
was placed in COLLECT state). There is no need to be stingy with AIDs since
the number of possible AIDs exceeds the maximum number of nodes in the cache.
Problem found by Nathanael Rensen.
Fix written by Nathanael and myself. Tested by Nathanael.
Comitting now to get this change tested across as many drivers as possible.
|
|
Sure stsp@
|
|
ok mpi@
|
|
counter if sn == 0 and ba_missedsn == 0xfff.
ok stsp@
|