| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 02_dbus_group_policy.patch | Add D-Bus group policy Debian does not use pam_console but uses group membership to control access to D-Bus. Activating both options in the conf file makes it work on Debian and Ubuntu. |
Michael Biebl <biebl@debian.org> | no | debian | 2007-03-08 | |
| 07_dbus_service_syslog.patch | Tweak D-Bus/systemd service activation configuration files: * log wpa_supplicant messages to syslog * activate control socket interface so that wpa_cli can be used by D-Bus activated wpa_supplicant daemon |
Kel Modderman <kel@otaku42.de> | no | 2012-04-21 | ||
| allow-tlsv1.patch | Enable TLSv1.0 by default OpenSSL 1.1.1 disables TLSv1.0 by default and sets the security level to 2. Some older networks may support for TLSv1.0 and less secure cyphers. |
Andrej Shadura <andrewsh@debian.org> | no | 2018-12-15 | ||
| disable-eapol-werror.patch | Disable -Werror for eapol_test This may make sense for the upstream, but we just want to build the tool to be useful to our users; dealing with build errors due to issues normally manifesting themselves as warnings is burdening for Debian and its downstreams. |
Andrej Shadura <andrew.shadura@collabora.co.uk> | no | 2021-02-12 | ||
| wpa_service_ignore-on-isolate.patch | Add IgnoreOnIsolate=yes to keep wpa-supplicant running while systemctl isolate > Add IgnoreOnIsolate=yes so that when switching "runlevels" in > oem-config will not kill off wpa and cause wireless to be > unavailable on first boot. (LP: #1576024) Also happens when running systemctl isolate default.target: > NM should be detecting that wpasupplicant is not running and start > it -- this should already have been working by way of wpasupplicant > being dbus-activated. [...] > It seems to me like IgnoreOnIsolate for wpasupplicant would be the > right thing to do, or to figure out why it isn't being properly > started when NM tries to use it. |
Mathieu Trudel-Lapierre <cyphermox@ubuntu.com> | no | 2017-03-13 | ||
| systemd-add-reload-support.patch | Add reload support to the systemd unit files When wifi password is written in /etc/wpa_supplicant/wpa_supplicant-if.conf, wpa_supplicant@if.service is started by systemd. When one adds a new pair of SSID and its password in the above config file, wpa_supplicant has to reload the changed config file. But "systemctl reload" was not accepted because "ExecReload" was missing from wpa_supplicant@.service. |
Ryutaroh Matsumoto <ryutaroh.matsumoto@nagoya-u.jp> | no | debian | 2019-07-08 | |
| manpage-replace-wheel-with-netdev.patch | Replace the wheel group with netdev wpa_supplicant.conf(5) manpage includes multiple examples with group wheel. Group wheel does not exist on Debian as a result the example fails. |
Thomas Glanzmann <thomas@glanzmann.de> | no | debian | 2022-02-13 | |
| upstream-fixes/0001-nl80211-add-extra-ies-only-if-allowed-by-driver.patch | nl80211: add extra-ies only if allowed by driver Upgrading wpa_supplicant from 2.9 to 2.10 breaks broadcom-wl based adapters. The reason for it is hostapd tries to install additional IEs for scanning while the driver does not support this. The kernel indicates the maximum number of bytes for additional scan IEs using the NL80211_ATTR_MAX_SCAN_IE_LEN attribute. Save this value and only add additional scan IEs in case the driver can accommodate these additional IEs. |
David Bauer <mail@david-bauer.net> | yes | debian upstream | http://lists.infradead.org/pipermail/hostap/2022-January/040185.html | 2022-01-30 |
| upstream-fixes/0002-AP-guard-FT-SAE-code-with-CONFIG_IEEE80211R_AP.patch | AP: guard FT-SAE code with CONFIG_IEEE80211R_AP wpa_supplicant doesn't support FT in AP mode, but it still negotiates FT-SAE. This can lead to an authentication failure when the AP is started with key_mgmt="SAE FT-SAE" and the STA supports both. Ensure that FT-SAE is not negotiated when CONFIG_IEEE80211R_AP is not defined. |
Beniamino Galvani <bgalvani@redhat.com> | no | 2022-04-04 | ||
| upstream-fixes/0003-OpenSSL-Drop-security-level-to-0-with-OpenSSL-3.0-wh.patch | OpenSSL: Drop security level to 0 with OpenSSL 3.0 when using TLS 1.0/1.1 Commit 9afb68b03976 ("OpenSSL: Allow systemwide secpolicy overrides for TLS version") with commit 58bbcfa31b18 ("OpenSSL: Update security level drop for TLS 1.0/1.1 with OpenSSL 3.0") allow this workaround to be enabled with an explicit network configuration parameter. However, the default settings are still allowing TLS 1.0 and 1.1 to be negotiated just to see them fail immediately when using OpenSSL 3.0. This is not exactly helpful especially when the OpenSSL error message for this particular case is "internal error" which does not really say anything about the reason for the error. It is is a bit inconvenient to update the security policy for this particular issue based on the negotiated TLS version since that happens in the middle of processing for the first message from the server. However, this can be done by using the debug callback for printing out the received TLS messages during processing. Drop the OpenSSL security level to 0 if that is the only option to continue the TLS negotiation, i.e., when TLS 1.0/1.1 are still allowed in wpa_supplicant default configuration and OpenSSL 3.0 with the constraint on MD5-SHA1 use. |
Jouni Malinen <j@w1.fi> | no | debian | upstream, commit:bc99366f9b960150aa2e369048bbc2218c1d414e | 2022-05-22 |
| allow-legacy-renegotiation.patch | Allow legacy renegotiation to fix PEAP issues with some servers | James Ralston <ralston@pobox.com> | no | 2022-05-01 | ||
| wpa_service_netdev.patch | Configure wpa_supplicant.service to create control sockets owned by group netdev | Andrej Shadura <andrew.shadura@collabora.co.uk> | no | debian | 2022-06-15 | |
| upstream-fixes/0013-wnm-Choose-best-available-bss-not-just-first-one.patch | wnm: Choose best available bss, not just first one. This should allow STA to make better choice about which BSS to roam to. Use estimated-throughput as comparison value. Can improve the est-tput measurement to improve this selection criteria if wanted in the future. |
Ben Greear <greearb@candelatech.com> | no | 2023-07-27 | ||
| upstream-fixes/0014-wpa_supplicant-Fix-wpa_supplicant-configuration-pars.patch | wpa_supplicant: Fix wpa_supplicant configuration parsing error In the original flow, after hostapd_config_tx_queue successfully parses a tx_queue variable, it would not return immediately. Then it would print out "unknow global field" later and set return val to -1. This patch returns immediately after hostapd_config_tx_queue successfully parses a tx_queue variable. |
Michael Lee <michael-cy.lee@mediatek.com> | no | 2023-07-27 | ||
| upstream-fixes/0015-Abort-ongoing-scan.patch | Abort ongoing scan Along with canceling queued scan, abort ongoing scan if any, this ensures Wi-Fi interface is in usable state after disconnect is issued, else subsequent scan after disconnect might fail with EBUSY. |
Chaitanya Tata <chaitanya.mgit@gmail.com> | no | 2023-07-18 | ||
| upstream-fixes/0016-Override-ieee80211w-from-pmf-for-AP-mode-in-wpa_supp.patch | [PATCH] Override ieee80211w from pmf for AP mode in wpa_supplicant Since NetworkManager doesn't support setting ieee80211w to wpa_supplicant and only support pmf, so override ieee80211w from pmf for AP mode if ieee80211w not configurated. Do not change behavior for the P2P GO cases. |
Chaoli Zhou <quic_zchaoli@quicinc.com> | no | 2022-09-08 | ||
| 0017-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch | CVE-2023-52160 PEAP client: Update Phase 2 authentication requirements The previous PEAP client behavior allowed the server to skip Phase 2 authentication with the expectation that the server was authenticated during Phase 1 through TLS server certificate validation. Various PEAP specifications are not exactly clear on what the behavior on this front is supposed to be and as such, this ended up being more flexible than the TTLS/FAST/TEAP cases. However, this is not really ideal when unfortunately common misconfiguration of PEAP is used in deployed devices where the server trust root (ca_cert) is not configured or the user has an easy option for allowing this validation step to be skipped. Change the default PEAP client behavior to be to require Phase 2 authentication to be successfully completed for cases where TLS session resumption is not used and the client certificate has not been configured. Those two exceptions are the main cases where a deployed authentication server might skip Phase 2 and as such, where a more strict default behavior could result in undesired interoperability issues. Requiring Phase 2 authentication will end up disabling TLS session resumption automatically to avoid interoperability issues. Allow Phase 2 authentication behavior to be configured with a new phase1 configuration parameter option: 'phase2_auth' option can be used to control Phase 2 (i.e., within TLS tunnel) behavior for PEAP: * 0 = do not require Phase 2 authentication * 1 = require Phase 2 authentication when client certificate (private_key/client_cert) is no used and TLS session resumption was not used (default) * 2 = require Phase 2 authentication in all cases |
Jouni Malinen <j@w1.fi> | yes | debian upstream | https://w1.fi/cgit/hostap/commit/?id=8e6485a1bcb0baffdea9e55255a81270b768439c | 2023-07-08 |
| CVE-2024-5290-lib_engine_trusted_path.patch | only load libraries from trusted path | Marc Deslauriers <marc.deslauriers@canonical.com> | no |