summaryrefslogtreecommitdiffstats
path: root/sys/net80211 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ieee80211_decrypt must use m_freem() instead of m_free()stsp2020-12-101-2/+2
| | | | | | Patch by zxystd from the OpenIntelWireless project (drivers for macOS) ok tobhe@
* Fix double-free on error in ieee80211_amsdu_decap().stsp2020-12-101-5/+5
| | | | | | Bug was introduced by my previous commit to this file. ok tobhe@
* Ignore trailing data in A-MSDU frame buffers if it is smaller than thestsp2020-12-091-12/+8
| | | | | | | | | 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@
* Disable A-MSDU support again.stsp2020-12-092-2/+8
| | | | | | | | | | 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@
* Flush reorder buffer after gap timeout, otherwise the frames remaintobhe2020-12-091-1/+6
| | | | | | | in the buffer until the next frame is received. Found by and fix from Christian Ehrhardt ok stsp@
* Enable 802.11 A-MSDU support again. It was disabled some time ago butstsp2020-12-082-18/+2
| | | | | | | the underlying problems have since been fixed. Using A-MSDUs results in improved download speeds with APs that support them. tested by robert@
* Fix 802.11 RSN capabilities announced to peers.stsp2020-12-081-3/+12
| | | | | | | | | | | | | | | | | | | | 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@
* Fix gapwait accounting. Count all the packets in the reordertobhe2020-12-081-24/+12
| | | | | | | | 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@
* Use BA agreement immediately after it is requested by the AP.tobhe2020-12-081-2/+17
| | | | | | | | | | 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@
* Always check for EBUSY when the return value of ic_set_key() is tested.krw2020-11-193-11/+44
| | | | | | | | 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@
* Don't enable port or link until all crypto keys are installed bykrw2020-11-121-9/+29
| | | | | | | | async task(s). Makes dhclient(8) much happier. Suggestions and ok stsp@, jmatthew@
* Kill unused IEEE80211_RADIOTAP_HWQUEUE.mpi2020-10-091-6/+1
| | | | | | | | | | 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@
* The command value of the _IOC() macro is limited to values [0..255].gerhard2020-10-061-2/+2
| | | | | | This change results in no binary change, it just makes things more clear. OK deraadt
* Add missing #if's to fix build without bpf(4).mvs2020-08-281-1/+3
| | | | ok deraadt@
* Improve processing of lost frames during 802.11 Rx aggregation.stsp2020-07-212-20/+54
| | | | | | | | | | | | | | | | | | 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
* The IEEE80211_F_HIDENWID flag is now part of ic_userflags, not ic_flags.stsp2020-07-201-2/+2
| | | | | | | | | | 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.
* ieee80211: track micfail timeout with getuptime(9) instead of tickscheloha2020-07-152-8/+8
| | | | | | With input from stsp@. ok stsp@
* When a wifi interface acts as a client and the WPA handshake is done,stsp2020-07-131-1/+3
| | | | | | | | | | | | | | | 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@
* Change users of IFQ_DEQUEUE(), IFQ_ENQUEUE() and IFQ_LEN() to use thepatrick2020-07-101-2/+2
| | | | | | "new" API. ok dlg@ tobhe@
* Undo pseudo-driver changes early in ieee80211_ifdetach() to prevent astsp2020-06-081-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@
* Revert "Ignore new Rxblock ack agreements until the WPA handshake is done."stsp2020-06-011-6/+1
| | | | | | | | | | | 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@
* Typo in WPA supplicant state machine: RNSA_SUPP_PTKDONE -> RSNA_SUPP_PTKDONEstsp2020-05-313-8/+8
|
* Remove a dead assignment to ni_rsn_state in ieee80211_node_leave_rsn().stsp2020-05-311-3/+1
| | | | Patch by Mikolaj Kucharski
* If no station happens to be associated when ieee80211_setkeys() runs thenstsp2020-05-291-1/+5
| | | | | | | 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@
* In hostap mode, after completing a new group key handshake with allstsp2020-05-291-1/+7
| | | | | | | | | | | | | 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@
* Let unencrypted 802.11 frames pass during hardware decryption post-processing.stsp2020-05-261-7/+13
| | | | | | | | | | | | | | 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@
* Revert previous; Set the ESS capability bit in assoc requests again.stsp2020-05-191-2/+2
| | | | | | | Association to some access points breaks without the ESS capability bit. Apparently I misunderstood something. Reported by krw@ and tb@
* Do not set the 802.11 ESS capability bit in association requests.stsp2020-05-191-2/+2
| | | | | | | The ESS capability bit should be set if the transmitter is an AP. Association requests are sent by clients. ok jca@
* Fix CCMP replay check with 11n Rx aggregation and CCMP hardware offloading.stsp2020-05-155-91/+231
| | | | | | | | | | | | | | | | | | | | | | | 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@
* Purge the ic_bss->ni_savedq mbuf queue when a wireless interface goes down.stsp2020-05-051-2/+6
| | | | | | | | | | | | | | | | | | | | | | 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)
* Prevent divide-by-zero in MiRA which I managed to trigger with iwn(4).stsp2020-05-011-1/+4
| | | | ok deraadt@
* Add the 'nomimo' nwflag which disables MIMO in 11n mode.stsp2020-04-291-3/+5
| | | | | | | | | 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@
* Prevent MiRA from jumping from very high to very low rates whilestsp2020-04-171-1/+4
| | | | | | | | | | 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@
* Eliminate an unnecessary intermediate variable in ieee80211_mira_choose().stsp2020-04-111-4/+2
| | | | suggested by jmatthew
* Skip MiRA's event-based probing if we're already at the minimum orstsp2020-04-111-5/+7
| | | | | | maximum rate of our current rateset. ok tb@
* Update MiRA probing interval of probed rates which are worse than thestsp2020-04-111-24/+18
| | | | | | | | | | | | | | | | 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@
* Fix ifconfig "media:" line for 11n wifi interfaces during and after bgscan.stsp2020-04-082-2/+23
| | | | | | | | 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@
* Don't let MiRA trigger event-based probing if the current measurementstsp2020-03-301-3/+3
| | | | | | | | | | | | | | | | | | | | | 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@
* Compute MiRA's moving average and standard deviation after computing thestsp2020-03-291-10/+10
| | | | | | | | | | 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@
* Make sure hdrlen is initialized.tobhe2020-03-111-2/+3
| | | | ok stsp@
* Properly wrap 802.11 frame sequence numbers when incrementing them.stsp2020-03-061-4/+4
| | | | ok tb@ tobhe@ mpi@
* Fix MiRA probing shortcut comparing measured throughput against thestsp2020-03-051-3/+4
| | | | | | | | | 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@
* Fix a MiRa probing short-cut comparing current to previous measurements.stsp2020-03-051-2/+2
| | | | | | | | | 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@
* Cancel MiRA probing timeouts if a channel quality change triggers probing.stsp2020-03-051-1/+3
| | | | | Avoids unnecessary re-probing in case a timeout had been scheduled already. tweak + ok tb@
* fix build without MIRA_AGGRESSIVE_DOWNWARDS_PROBINGstsp2020-03-051-2/+5
| | | | ok tb@
* MiRA needs to add tx time overhead for ACK only for single-frame transmissions.stsp2020-03-051-5/+7
| | | | | Resolves XXX comments regarding block-ack support. with simplification tweak from + ok tb@
* Fix dead link to the MiRA paper and add DOI link to the published version.tb2020-03-031-2/+3
| | | | ok stsp
* Fix MiRA's sub-frame error rate computation.stsp2020-03-032-6/+6
| | | | | | | | | | | | | | | 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@
* Do not send any QoS data frames unless Tx aggregation has been negotiated.stsp2020-03-031-10/+7
| | | | | | | | | | 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
* Fix an mbuf corruption issue which occurs in net80211 hostap mode.stsp2020-02-181-9/+8
| | | | | | | | | | | | | | | | | | | | | | | 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
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.