| Age | Commit message (Collapse) | Author |
|---|
|
apostrophe.
|
|
Ensure that we supply the access point's DTIM period to firmware after
an active scan, as soon as the next beacon arrives. This prevents the
problems which prompted us to keep active scans disabled in our drivers.
Problem debugged and patch by zxystd from the OpenIntelWireless project.
I made some tweaks regarding TIM parsing, which were reviewed by zxystd.
Johannes Berg from Intel has confirmed to me via IRC that firmware
will misbehave if running with a zero DTIM period.
Tested:
8265: jca, stsp
9260: kettenis (possible fallout observed here; will keep an eye on it)
9650: stsp
ax200: zxystd, kevlo, stsp
ax201: stsp
ok kevlo@ kettenis@
|
|
The original purpose of ieee80211_find_node_for_beacon() was to avoid
storing duplicate nodes with the same source MAC address in a hash table.
Later on, our node table data structure was changed from a hash table
to an RB tree. The RB tree can only store a single node per MAC address.
However, find_node_for_beacon() was kept regardless, now documented to
serve a different purpose.
Its new purpose is to tell apart different nodes which happen to use
the same MAC address and hence cannot both be stored in the RB tree.
The idea is to filter such duplicate nodes out during a scan. But colliding
nodes are told apart by RSSI and channel, and either may change over time.
So this does not really prevent duplicate MAC addresses from causing issues.
The code which decides which node is "better" can erroneously match an
AP against itself, in case the AP uses a hidden SSID. This caused
workarounds for hidden SSID to pile up over time.
Just a bit further down, the code looks up the same node again and
performs all of the intended node state updates. Simply skipping the
ieee80211_find_node_for_beacon() check makes such state updates work.
ok tobhe@
|
|
everyone else seems to use ETHERTYPE_EAPOL, and as a bonus it also
appears to be more correct.
ok deraadt@ stsp@
|
|
when a power-saving client decides to leave our hostap interface.
Prevents a "key unset for sw crypto" panic as we try to send a frame
to a node which is in COLLECT state with its WPA keys already cleared.
We were already clearing the queue which buffers power-saved frames for
the client node. This queue is stored within the node structure itself.
However, the interface has another global queue for frames which need to
be transmitted by the driver to a set of nodes during the next DTIM.
We missed removing frames for a departing node from this global queue.
While here, add missing node refcount adjustments as frames get purged.
Problem reported by Mikolaj Kucharski, who tested this fix for more
than a week with athn(4), with no further panics observed.
|
|
Sending routing messages requires a socket lock which may sleep.
ieee80211_set_link_state() is called from interrupts and timeouts where
sleeping is not allowed. mvs@ pointed out that if_link_state_change()
is already using a task for this reason.
Should fix a witness-related panic reported by cheloha@
ok mvs@ tobhe@ florian@
|
|
allows the driver to take control of the roaming teardown sequence.
This handler allows drivers to ensure that race conditions between
firmware state and net80211 state are avoided, and will be used by
the iwm(4) and iwx(4) drivers soon.
Split the existing roaming teardown sequence into two steps, one step
for tearing down Tx block ack sessions which sends a DELBA frame, and a
second step for flushing Tx rings followed by sending a DEAUTH frame.
We used to queue both frames, expecting to switch APs once both were sent.
Now we effectively expect everything to be sent before we queue a final
DEAUTH frame, and wait for just this frame to be sent before switching.
This already made issues on iwm/iwx less frequent but by itself this was
not enough to close all races for those drivers. It should however help
when adding background scan support to a non-firmware device driver.
Tested, with driver patches:
iwm 8265: Aaron Poffenberger, stsp
iwm 9260: florian
iwm 9560: sthen
iwx ax200: jmc, stsp
|
|
Noticed while testing iwm/iwx roaming patches, where my AP would request
a new Rx BA session when we had already decided to roam away. There is no
need to set up a new Rx BA session with our old AP which we would have to
immediately tear down again anyway.
|
|
These files were unhooked from the build in April 2021.
|
|
'nwid'/'nwkey', the keys will be set at random times when 'join'/'nwkey' is
used. So also stop trying to set IEEE80211_CIPHER_NONE keys on that path.
James Hastings confirms this fixes his '(null node)' panics on run(4). Thanks!
ok stsp@
|
|
and notify drivers when the channel width has changed.
|
|
For the moment we use either the 40MHz rate set or the 20 MHz one,
depending on whether our peer supports 40MHz channels.
If this turns out to be suboptimal we could probe the 40MHz and 20MHz
rate sets separately to detect which one works better.
The same applies to use of the short guard interval (SGI), which is
either always on or off at the moment. Again, probing for this could
be added later if needed.
|
|
Sending frames from ieee80211_node_join_bss() won't work as expected.
I missed that IEEE80211_SEND_MGMT() calls if_start() immediately after
queueing the management frame. This means the probe request is being
sent in a state where, while ic_bss represents our new AP, the driver
did not yet have a chance to move the device over to our new AP.
The auth request for the new AP is sent from ieee80211_newstate() which
runs after the driver has reconfigured the device. If want to send a
probe request to the new AP then we would need to send it at that point,
before the auth frame gets sent.
|
|
Tested by fkr on iwx ax200/ax201 and myself on iwm 8265.
Also tested by florian and bket as part of a larger diff.
ok mpi@
|
|
My assumption that frames which are buffered on the power save
queue were already encrypted was wrong. And the issue which this
change intended to fix is still present (reported by Mikolaj Kucharski).
|
|
sessions entirely in firmware. This will be used by iwx(4).
|
|
action frame subtypes we care about (i.e. those related to 11n block ack).
ok mpi@
|
|
block ack window when a new Tx block ack agreement is established.
In the future this change will allow the iwx(4) driver to initialize this
sequence number such that it corresponds to what the firmware expects.
Note that ba->ba_winstart is set to ni->ni_qos_txseqs[tid] when a new Tx agg
agreement is initiated in ieee80211_node_addba_request(). Unless the driver
resets ba->ba_winstart before ieee80211_addba_resp_accept() runs, which is
what iwx(4) will do, the assignment added with this patch is a no-op.
|
|
Fragmented frames were never of any practical use to us anyway, given that
our net80211 stack does not (yet?) re-assemble them.
Counter-measure against attacks where an arbitrary packet is injected in a
fragment with attacker-controlled content (via an AP which supports fragments).
See https://papers.mathyvanhoef.com/usenix2021.pdf
Section 6.8 "Treating fragments as full frames"
ok mpi@
|
|
|
|
This mitigates an attack where a single 802.11 frame is interpreted as an
A-MSDU because of a forged AMSDU-present bit in the 802.11 QoS frame header.
See https://papers.mathyvanhoef.com/usenix2021.pdf section 3.2.
MAC address validation is added as an additional measure to prevent hostap
clients from sending A-MSDU subframes with a spoofed source address.
An earlier version of this patch was reviewed by Mathy Vanhoef, who spotted
a bug in my original attempt at preventing spoofed addresses.
ok mpi@
|
|
about the offending key. This will hopefully help with debugging.
|
|
Sending data frames to nodes in other states is wrong since the node's
data structure might not be set up properly in such states.
This could explain occasional "key unset for sw crypto" panics observed
with athn(4) hostap interfaces.
Problem reported and fix tested by Mikolaj Kucharski.
|
|
statistics have been gathered for a candidate Tx rate. The goal is
to avoid Tx rate choices that might turn out to be too optimistic.
In practice this only affects the case where we probe upwards. If the
current Tx rate starts seeing loss we will still scale down very quickly.
Based on a larger collection of patches by Christian Ehrhardt.
I have made stylistic tweaks for consistency.
Tested:
iwn 6205: stsp, Josh Grosse
iwm 7265: stsp
iwm 8265: Matthias Schmidt
iwm 9260: phessler
|
|
- HT protection settings (this was already implemented)
- ERP (11g) protection setting
- short slottime setting
- short preamble setting
- EDCA (QoS) parameters
All of these parameters are communicated in beacons and hardware is
now kept up-to-date with them.
Prompted by a problem report from Christian Ehrhardt regarding ERP.
Tested:
iwn 6205: stsp, Josh Grosse
iwm 7265: trondd
iwm 8265: stsp, Matthias Schmidt
iwm 9260: phessler
iwx ax200: stsp, jmc, gnezdo
|
|
re-enable de-aggregation of A-MSDUs in net80211 for all drivers capable
of 11n mode. This can provide improved Rx performance if the access point
supports transmission of A-MSDUs nested in A-MDPUs.
iwm(9) 9k and iwx(4) devices de-aggregate A-MSDUs in hardware.
Neither our drivers nor the net80211 stack were prepared to handle this.
Add two Rx-info flags which drivers can use to avoid having subframes which
arrived in the same A-MSDU rejected as duplicates in the net80211 input layer:
IEEE80211_RXI_HWDEC_SAME_PN allows the same CCMP packet number for a series
of subsequent frames. IEEE80211_RXI_SAME_SEQ allows the same 802.11 frame
header sequence number for a series of subsequent of frames.
Handle A-MPDU reordering on iwm 9k and iwx devices, based on code from iwlwifi.
Rx block ack window information is provided by firmware. So far this info was
ignored by drivers and reordering of A-MPDU subframes happened twice: Once in
firmware, and again in net80211.
Tested:
iwm 7260: bcallah, dv
iwm 7265: mpi, trondd, Matthias Schmidt
iwm 8260: bket, Marcus MERIGHI
iwm 8265: stsp, tracey, Uwe Werler
iwm 9260: phessler, matthieu
iwm 9560: stsp, Uwe Werler
iwx ax200: jmc, stsp
iwx ax201: stsp
|
|
11ac/n/a/g/b as applicable. Fixes an issue where hostap would end up
running in the rather meaningless MODE_AUTO unless a mode was explicitly
configured with ifconfig.
Found while investigating issues reported by trondd testing my athn RA patch.
ok deraadt@
|
|
IEEE 802.11 sequence numbers wrap around at 0xfff, not 0xffff.
ok phessler@ kevlo@
|
|
value is only used after checking if it's valid or not.
CID 1502921
OK stsp@ phessler@
|
|
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@
|
