Age | Commit message (Collapse) | Author |
|
In particular, add Tx block ack session management to net80211, with
enough funcionality to support Tx aggregation on devices which perform
A-MPDU subframe scheduling in firmware.
Make use of the iwn(4) firmware Tx scheduler to build A-MPDUs.
net80211's QoS support code is now enabled and used by Tx aggregation.
A-MSDU frames inside A-MPDUs have been tested and work in principle.
For now, this feature is disabled because unfair TCP connection sharing
was observed during testing, where bursts of TCP Ack frames for a single
tcpbench(1) connection arriving in A-MSDUs made other TCP connections stall.
Switch off support for A-MSDUs inside A-MPDUs on the Rx side as well.
Tested on iwn chipsets 1000, 4965, 5100, 5300, 2200, 6200, 6205, 6300
(committed version of tested diff has all debug printfs removed)
tests/ok benno kmos mlarkin kevlo
|
|
in ieee80211com's ic_flags because we haven't been paying attention to
them (they're not in the same place in the code and hence easy to miss).
Move them to a dedicated variable to avoid this problem in the future.
Add a new 'stayauth' nwflag which can be set to let net80211 ignore
deauth frames. This can be useful when deauth frames are being
persistently spoofed by an attacker. Idea from beck@
ok beck@ phessler@
|
|
Don't accept A-MPDUs if not in RUN state, and don't accept them from
unassociated clients in hostap mode.
ok jmatthew@ kevlo@
|
|
ok phessler@
|
|
Previously such frames would be counted as decryption failures which is
nonsense because they don't carry any data which could be encrypted.
Problem analyzed by, and fix developed together with, Lauri Tirkkonen.
|
|
Some APs (Aruba 105) send a bogus basic MCS set in assoc responses
which prevents us from enabling 11n support with those APs, while
these APs still behave as if were were an 11n client which renders
the association unusable.
The basic MSC set is already provided in beacons anyway, and the
802.11 2012 standard says the basic MSC set is reserved in frames
other than beacons (see Table 8-130).
ok mpi@
|
|
response in case a lower RSSI is measured for a subsequent beacon.
I have run into a 5Ghz AP which sends beacons with very low Tx power for some
reason, while probe responses are transmitted with reasonable signal strength.
This change ensures such 5GHz APs will be considered as a reasonable choice
during access point selection.
Discussed with sthen@, Patrick Dohman, and others on tech@
ok phessler@ pirofti@
|
|
Patch by Jesper Wallin
|
|
point in scheduling ic_bgscan_timeout() since this timeout will find that
it has nothing to do.
ok phessler pirofti
|
|
a node's RSSI info while we are still in INIT state.
ok phessler@
|
|
The iwm(4) driver will now roam between access points which share an SSID.
Use 'ifconfig iwm0 debug' and 'tail -f /var/log/messages' to watch it do so.
Tested by several people in various iterations.
As usual, let me know if you run into issues.
ok phessler deraadt
|
|
Some wifi drivers send a probe request if the hardware reports "missed beacon"
events. If the AP replies with a probe response it is still servicing us and
there is no need to search for a new AP. However, the management timer was not
reset if a beacon was received while in RUN state. So the interface watchdog
always ended up putting the driver into SCAN state after a missed beacon event,
even if the AP did respond to our probe request. Under some conditions this
bug would cause spurious disconnects.
Problem reported and fix tested by mlarkin@
(Using the management timer in RUN state is a new convention. Before support
for missed beacons was added, this timer was only used during the association
sequence to handle APs which don't respond to our assoc requests and such.)
|
|
frames to dmesg, if debug mode was enabled with ifconfig.
This debug output was much too verbose and not actually useful for debugging.
tcpdump -y IEEE802_11_RADIO will show the same information.
ok sthen@
|
|
to make it more readable.
help, many explanations and ok stsp
|
|
Input, help & ok stsp
|
|
If an AP is configured to hide its SSID it sends a non-zero length SSID
which contains only zeroes. The AP sends its actual SSID only in probe
responses after a client includes this SSID in a probe request.
If we happened to receive a beacon before the probe response we stored a
non-zero-length SSID of zeroes and never updated the SSID when the probe
response arrived. The client was then unable to find the AP.
test & ok jung@
|
|
constants.
The consensus is that if both operands are constant, we don't need
mallocarray. Reminded by tedu@
ok deraadt@
|
|
ok deraadt@
|
|
the interface operates in hostap mode.
test & ok tb@
|
|
ieee80211_node. Pass these fields to 'ifconfig scan' instead of giving it
currently configured/enabled settings.
Fixes display of AP WPA capabilities in 'ifconfig scan' while the wifi
interface is not configured to use WPA (my previous commit attempted to
fix the same problem but didn't make it work in all cases).
ok tb@
|
|
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.
|
|
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@
|
|
chain. Else this function will sometimes signal end of AMSDU frame too early.
Patch by Imre Vadasz.
ok mpi@ phessler@
|
|
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@
|
|
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@
|
|
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@
|
|
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@
|
|
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.
|
|
ok mpi@
|
|
counter if sn == 0 and ba_missedsn == 0xfff.
ok stsp@
|
|
Fix a case where ieee80211_ba_input() failed to account for that.
ok tb@
|
|
tb@ discovered that we were not following the 802.11-2012 standard correctly
for frames which fall within the range [winend, windend+winsize]. This could
cause valid frames to be dropped because we moved the window too far ahead.
with and ok tb@
|
|
counters that keep track of consecutive frames falling outside the window.
|
|
netstat(1) needs to be recompiled to work with new kernel.
ok deraadt mpi
|
|
tested by and ok stsp@
|
|
pointers.
These functions have been introduced to abstract some of the MP-
safeness^Wmadness and should be use everywhere.
Prodded by a comment from jsg@.
ok mikeb@, stsp@
|
|
ok stsp@
|
|
Suggested by sthen@
ok tb@
|
|
Should have been part of the QoS "no data" fix.
ok tb@
|
|
current BlockAck window compare against the actual window size, rather than
the maximum window size possible. As a result, two consecutive if-blocks
now check for the same condition, so merge them.
|
|
|
|
just once, by assigning its value to the 'count' variable earlier and reusing
'count' where this expression was used.
No functional change. This just results in better readability.
|
|
will cause major confusion since they don't carry a sequence number.
ok mpi@ sthen@
|
|
interface debug flag is set (enabled with: ifconfig iwn0 debug).
Shows the frame's sequence number and the current BA window.
I'm adding this for diagnosis, just in case it will be needed to make
future decisions about tuning the heuristic which works around network
stalls caused by such frames.
|
|
is asking for it. This timeout should not be required anymore now that krw@'s
hangs are fixed by working around APs which make sequence numbers jump about.
|
|
than the current 11n BlockAck window. The previous code would be fooled into
moving the window forward and then drop packets until their sequence numbers
catch up with the new window, which can take several minutes.
Fixes traffic stalls observed with Broadcom APs.
ok krw@ tb@
|
|
|
|
duplicates rather than input errors. These subframes have either already
been received, or the window was moved by the gap timeout which should only
happen with buggy APs. Neither condition indicates a severe problem.
Perhaps we will introduce a separate counter for this later.
|