EAP-pwd side-channel attack
Published: April 10, 2019
Identifiers:
- CVE-2019-9495 (cache attack against EAP-pwd)
Latest version available from: https://w1.fi/security/2019-2/
Vulnerability
Number of potential side channel attacks were recently discovered in the
SAE implementations used by both hostapd and wpa_supplicant (see
security advisory 2019-1 and VU#871675). EAP-pwd uses a similar design
for deriving PWE from the password and while a specific attack against
EAP-pwd is not yet known to be tested, there is no reason to believe
that the EAP-pwd implementation would be immune against the type of
cache attack that was identified for the SAE implementation. Since the
EAP-pwd implementation in hostapd (EAP server) and wpa_supplicant (EAP
peer) does not support MODP groups, the timing attack described against
SAE is not applicable for the EAP-pwd implementation.
A novel cache-based attack against SAE handshake would likely be
applicable against the EAP-pwd implementation. Even though the
wpa_supplicant/hostapd PWE derivation iteration for EAP-pwd has
protections against timing attacks, this new cache-based attack might
enable an attacker to determine which code branch is taken in the
iteration if the attacker is able to run unprivileged code on the victim
machine (e.g., an app installed on a smart phone or potentially a
JavaScript code on a web site loaded by a web browser). This depends on
the used CPU not providing sufficient protection to prevent unprivileged
applications from observing memory access patterns through the shared
cache (which is the most likely case with today's designs).
The attacker could use information about the selected branch to learn
information about the password and combine this information from number
of handshake instances with an offline dictionary attack. With
sufficient number of handshakes and sufficiently weak password, this
might result in full recovery of the used password if that password is
not strong enough to protect against dictionary attacks.
This attack requires the attacker to be able to run a program on the
target device. This is not commonly the case on an authentication server
(EAP server), so the most likely target for this would be a client
device using EAP-pwd.
The commits listed in the end of this advisory change the EAP-pwd
implementation shared by hostapd and wpa_supplicant to perform the PWE
derivation loop using operations that use constant time and memory
access pattern to minimize the externally observable differences from
operations that depend on the password even for the case where the
attacker might be able to run unprivileged code on the same device.
Vulnerable versions/configurations
All wpa_supplicant and hostapd versions with EAP-pwd support
(CONFIG_EAP_PWD=y in the build configuration and EAP-pwd being enabled
in the runtime configuration).
It should also be noted that older versions of wpa_supplicant/hostapd
prior to v2.7 did not include additional protection against certain
timing differences. The definition of the EAP-pwd (RFC 5931) does not
describe such protection, but the same issue that was addressed in SAE
earlier can be applicable against EAP-pwd as well and as such, that
implementation specific extra protection (commit 22ac3dfebf7b, "EAP-pwd:
Mask timing of PWE derivation") is needed to avoid showing externally
visible timing differences that could leak information about the
password. Any uses of older wpa_supplicant/hostapd versions with EAP-pwd
are recommended to update to v2.7 or newer in addition to the mitigation
steps listed below for the more recently discovered issue.
Possible mitigation steps
- Merge the following commits to wpa_supplicant/hostapd and rebuild:
OpenSSL: Use constant time operations for private bignums
Add helper functions for constant time operations
OpenSSL: Use constant time selection for crypto_bignum_legendre()
EAP-pwd: Use constant time and memory access for finding the PWE
These patches are available from https://w1.fi/security/2019-2/
- Update to wpa_supplicant/hostapd v2.8 or newer, once available
- Use strong passwords to prevent dictionary attacks
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
[bump PKG_RELEASE]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
SAE side-channel attacks
Published: April 10, 2019
Identifiers:
- VU#871675
- CVE-2019-9494 (cache attack against SAE)
Latest version available from: https://w1.fi/security/2019-1/
Vulnerability
Number of potential side channel attacks were discovered in the SAE
implementations used by both hostapd (AP) and wpa_supplicant
(infrastructure BSS station/mesh station). SAE (Simultaneous
Authentication of Equals) is also known as WPA3-Personal. The discovered
side channel attacks may be able to leak information about the used
password based on observable timing differences and cache access
patterns. This might result in full password recovery when combined with
an offline dictionary attack and if the password is not strong enough to
protect against dictionary attacks.
Cache attack
A novel cache-based attack against SAE handshake was discovered. This
attack targets SAE with ECC groups. ECC group 19 being the mandatory
group to support and the most likely used group for SAE today, so this
attack applies to the most common SAE use case. Even though the PWE
derivation iteration in SAE has protections against timing attacks, this
new cache-based attack enables an attacker to determine which code
branch is taken in the iteration if the attacker is able to run
unprivileged code on the victim machine (e.g., an app installed on a
smart phone or potentially a JavaScript code on a web site loaded by a
web browser). This depends on the used CPU not providing sufficient
protection to prevent unprivileged applications from observing memory
access patterns through the shared cache (which is the most likely case
with today's designs).
The attacker can use information about the selected branch to learn
information about the password and combine this information from number
of handshake instances with an offline dictionary attack. With
sufficient number of handshakes and sufficiently weak password, this
might result in full discovery of the used password.
This attack requires the attacker to be able to run a program on the
target device. This is not commonly the case on access points, so the
most likely target for this would be a client device using SAE in an
infrastructure BSS or mesh BSS.
The commits listed in the end of this advisory change the SAE
implementation shared by hostapd and wpa_supplicant to perform the PWE
derivation loop using operations that use constant time and memory
access pattern to minimize the externally observable differences from
operations that depend on the password even for the case where the
attacker might be able to run unprivileged code on the same device.
Timing attack
The timing attack applies to the MODP groups 22, 23, and 24 where the
PWE generation algorithm defined for SAE can have sufficient timing
differences for an attacker to be able to determine how many rounds were
needed to find the PWE based on the used password and MAC
addresses. When the attack is repeated with multiple times, the attacker
may be able to gather enough information about the password to be able
to recover it fully using an offline dictionary attack if the password
is not strong enough to protect against dictionary attacks. This attack
could be performed by an attacker in radio range of an access point or a
station enabling the specific MODP groups.
This timing attack requires the applicable MODP groups to be enabled
explicitly in hostapd/wpa_supplicant configuration (sae_groups
parameter). All versions of hostapd/wpa_supplicant have disabled these
groups by default.
While this security advisory lists couple of commits introducing
additional protection for MODP groups in SAE, it should be noted that
the groups 22, 23, and 24 are not considered strong enough to meet the
current expectation for a secure system. As such, their use is
discouraged even if the additional protection mechanisms in the
implementation are included.
Vulnerable versions/configurations
All wpa_supplicant and hostapd versions with SAE support (CONFIG_SAE=y
in the build configuration and SAE being enabled in the runtime
configuration).
Acknowledgments
Thanks to Mathy Vanhoef (New York University Abu Dhabi) and Eyal Ronen
(Tel Aviv University) for discovering the issues and for discussions on
how to address them.
Possible mitigation steps
- Merge the following commits to wpa_supplicant/hostapd and rebuild:
OpenSSL: Use constant time operations for private bignums
Add helper functions for constant time operations
OpenSSL: Use constant time selection for crypto_bignum_legendre()
SAE: Minimize timing differences in PWE derivation
SAE: Avoid branches in is_quadratic_residue_blind()
SAE: Mask timing of MODP groups 22, 23, 24
SAE: Use const_time selection for PWE in FFC
SAE: Use constant time operations in sae_test_pwd_seed_ffc()
These patches are available from https://w1.fi/security/2019-1/
- Update to wpa_supplicant/hostapd v2.8 or newer, once available
- In addition to either of the above alternatives, disable MODP groups
1, 2, 5, 22, 23, and 24 by removing them from hostapd/wpa_supplicant
sae_groups runtime configuration parameter, if they were explicitly
enabled since those groups are not considered strong enough to meet
current security expectations. The groups 22, 23, and 24 are related
to the discovered side channel (timing) attack. The other groups in
the list are consider too weak to provide sufficient security. Note
that all these groups have been disabled by default in all
hostapd/wpa_supplicant versions and these would be used only if
explicitly enabled in the configuration.
- Use strong passwords to prevent dictionary attacks
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
[bump PKG_RELEASE]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Cherry-pick Multi-AP commits from uptream:
9c06f0f6a hostapd: Add Multi-AP protocol support
5abc7823b wpa_supplicant: Add Multi-AP backhaul STA support
a1debd338 tests: Refactor test_multi_ap
bfcdac1c8 Multi-AP: Don't reject backhaul STA on fronthaul BSS
cb3c156e7 tests: Update multi_ap_fronthaul_on_ap to match implementation
56a2d788f WPS: Add multi_ap_subelem to wps_build_wfa_ext()
83ebf5586 wpa_supplicant: Support Multi-AP backhaul STA onboarding with WPS
66819b07b hostapd: Support Multi-AP backhaul STA onboarding with WPS
8682f384c hostapd: Add README-MULTI-AP
b1daf498a tests: Multi-AP WPS provisioning
Add support for Multi-AP to the UCI configuration. Every wifi-iface gets
an option 'multi_ap'. For APs, its value can be 0 (multi-AP support
disabled), 1 (backhaul AP), 2 (fronthaul AP), or 3 (fronthaul + backhaul
AP). For STAs, it can be 0 (not a backhaul STA) or 1 (backhaul STA, can
only associate with backhaul AP).
Also add new optional parameter to wps_start ubus call of
wpa_supplicant to indicate that a Multi-AP backhaul link is required.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This updates hostapd to version the git version from 2018-12-02 which
matches the 2.7 release.
The removed patches were are already available in the upstream code, one
additional backport is needed to fix a compile problem.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
similar to hostapd, also add a ubus interface for wpa_supplicant
which will allow handling WPS push-button just as it works for hostapd.
In order to have wpa_supplicant running without any network
configuration (so you can use it to retrieve credentials via WPS),
configure wifi-iface in /etc/config/wireless:
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'wwan'
option mode 'sta'
option encryption 'wps'
This section will automatically be edited if credentials have
successfully been acquired via WPS.
Size difference (mips_24kc): roughly +4kb for the 'full' variants of
wpa_supplicant and wpad which do support WPS.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Backport two upstream fixes to address overly verbose logging of MAC ACL
rejection messages.
Fixes: FS#1468
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Unauthenticated EAPOL-Key decryption in wpa_supplicant
Published: August 8, 2018
Identifiers:
- CVE-2018-14526
Latest version available from: https://w1.fi/security/2018-1/
Vulnerability
A vulnerability was found in how wpa_supplicant processes EAPOL-Key
frames. It is possible for an attacker to modify the frame in a way that
makes wpa_supplicant decrypt the Key Data field without requiring a
valid MIC value in the frame, i.e., without the frame being
authenticated. This has a potential issue in the case where WPA2/RSN
style of EAPOL-Key construction is used with TKIP negotiated as the
pairwise cipher. It should be noted that WPA2 is not supposed to be used
with TKIP as the pairwise cipher. Instead, CCMP is expected to be used
and with that pairwise cipher, this vulnerability is not applicable in
practice.
When TKIP is negotiated as the pairwise cipher, the EAPOL-Key Key Data
field is encrypted using RC4. This vulnerability allows unauthenticated
EAPOL-Key frames to be processed and due to the RC4 design, this makes
it possible for an attacker to modify the plaintext version of the Key
Data field with bitwise XOR operations without knowing the contents.
This can be used to cause a denial of service attack by modifying
GTK/IGTK on the station (without the attacker learning any of the keys)
which would prevent the station from accepting received group-addressed
frames. Furthermore, this might be abused by making wpa_supplicant act
as a decryption oracle to try to recover some of the Key Data payload
(GTK/IGTK) to get knowledge of the group encryption keys.
Full recovery of the group encryption keys requires multiple attempts
(128 connection attempts per octet) and each attempt results in
disconnection due to a failure to complete the 4-way handshake. These
failures can result in the AP/network getting disabled temporarily or
even permanently (requiring user action to re-enable) which may make it
impractical to perform the attack to recover the keys before the AP has
already changes the group keys. By default, wpa_supplicant is enforcing
at minimum a ten second wait time between each failed connection
attempt, i.e., over 20 minutes waiting to recover each octet while
hostapd AP implementation uses 10 minute default for GTK rekeying when
using TKIP. With such timing behavior, practical attack would need large
number of impacted stations to be trying to connect to the same AP to be
able to recover sufficient information from the GTK to be able to
determine the key before it gets changed.
Vulnerable versions/configurations
All wpa_supplicant versions.
Acknowledgments
Thanks to Mathy Vanhoef of the imec-DistriNet research group of KU
Leuven for discovering and reporting this issue.
Possible mitigation steps
- Remove TKIP as an allowed pairwise cipher in RSN/WPA2 networks. This
can be done also on the AP side.
- Merge the following commits to wpa_supplicant and rebuild:
WPA: Ignore unauthenticated encrypted EAPOL-Key data
This patch is available from https://w1.fi/security/2018-1/
- Update to wpa_supplicant v2.7 or newer, once available
Signed-off-by: John Crispin <john@phrozen.org>
Clean up conflicts/provides/depends hell and add PROVIDES for
eapol-test variants while at it.
Update mesh-DFS patchset from Peter Oh to v5 (with local fixes) which
allows to drop two revert-patches for upstream commits which previously
were necessary to un-break mesh-DFS support.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Support for building wpa_supplicant/hostapd against wolfssl has been
added upstream recently, add build option to allow users using it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The max_oper_chwidth settings was parsed incorrectly for big endian system.
This prevented the system to switch to VHT80 (or VHT160). Instead they were
mapped to:
* HT20: 20MHz
* VHT20: 20MHz
* HT40: 40MHz
* VHT40: 40MHz
* VHT80: 40MHz
* VHT160: 40MHz
This happened because each max_oper_chwidth setting in the config file was
parsed as "0" instead of the actual value.
Fixes: a4322eba2b ("hostapd: fix encrypted mesh channel settings")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Fix encrypted (or DFS) AP+MESH interface combination in a way similar
to how it's done for AP+STA and fix netifd shell script.
Refresh patches while at it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Import two patches from Peter Oh to allow setting channel
bandwidth in the way it already works for managed interfaces.
This fixes mesh interfaces on 802.11ac devices always coming up in
VHT80 mode.
Add a patch to allow HT40 also on 2.4GHz if noscan option is set, which
also skips secondary channel scan just like noscan works in AP mode.
This time also make sure to add all files to the patch before
committing it...
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Import two patches from Peter Oh to allow setting channel
bandwidth in the way it already works for managed interfaces.
This fixes mesh interfaces on 802.11ac devices always coming up in
VHT80 mode.
Add a patch to allow HT40 also on 2.4GHz if noscan option is set, which
also skips secondary channel scan just like noscan works in AP mode.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
For unencrypted mesh networks our scripts take care of setting
the various mesh_param values. wpa_supplicant changes somes of them
when being used for SAE encrypted mesh and previously didn't allow
configuring any of them. Add support for setting mesh_fwding (which
has to be set to 0 when using other routing protocols on top of
802.11s) and update our script to pass the value to wpa_supplicant.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
And import patchset to allow 802.11s mesh on DFS channels, see also
http://lists.infradead.org/pipermail/hostap/2018-April/038418.html
Fix sae_password for encryption mesh (sent upstream as well).
Also refreshed existing patches and fixed 463-add-mcast_rate-to-11s.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The following patches were merged upstream:
000-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch
replaced by commit 0e3bd7ac6
001-Prevent-reinstallation-of-an-already-in-use-group-ke.patch
replaced by commit cb5132bb3
002-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch
replaced by commit 87e2db16b
003-Prevent-installation-of-an-all-zero-TK.patch
replaced by commit 53bb18cc8
004-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch
replaced by commit 0adc9b28b
005-TDLS-Reject-TPK-TK-reconfiguration.patch
replaced by commit ff89af96e
006-WNM-Ignore-WNM-Sleep-Mode-Response-without-pending-r.patch
replaced by commit adae51f8b
007-FT-Do-not-allow-multiple-Reassociation-Response-fram.patch
replaced by commit 2a9c5217b
008-WPA-Extra-defense-against-PTK-reinstalls-in-4-way-ha.patch
replaced by commit a00e946c1
009-Clear-PMK-length-and-check-for-this-when-deriving-PT.patch
replaced by commit b488a1294
010-Optional-AP-side-workaround-for-key-reinstallation-a.patch
replaced by commit 6f234c1e2
011-Additional-consistentcy-checks-for-PTK-component-len.patch
replaced by commit a6ea66530
012-Clear-BSSID-information-in-supplicant-state-machine-.patch
replaced by commit c0fe5f125
013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
replaced by commit 114f2830d
Some patches had to be modified to work with changed upstream source:
380-disable_ctrl_iface_mib.patch (adding more ifdef'ery)
plus some minor knits needed for other patches to apply which are not
worth being explicitely listed here.
For SAE key management in mesh mode, use the newly introduce
sae_password parameter instead of the psk parameter to also support
SAE keys which would fail the checks applied on the psk field (ie.
length and such). This fixes compatibility issues for users migrating
from authsae.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
If the auth or assoc request was denied the reason
was always WLAN_STATUS_UNSPECIFIED_FAILURE.
That's why for example the wpa supplicant was always
trying to reconnect to the AP.
Now it's possible to give reasoncodes why the auth
or assoc was denied.
Signed-off-by: Nick Hainke <vincent@systemli.org>
Neighbor reports are enabled implicitly on use, beacon reports and BSS
transition management need to be enabled explicitly
Signed-off-by: Felix Fietkau <nbd@nbd.name>
wpa_disable_eapol_key_retries can't prevent attacks against the Wireless
Network Management (WNM) Sleep Mode handshake. Currently, hostapd
processes WNM Sleep Mode requests from clients regardless of the setting
wnm_sleep_mode. Backport Jouni Malinen's upstream patch 114f2830 in
order to ignore such requests by clients when wnm_sleep_mode is disabled
(which is the default).
Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
[rewrite commit subject (<= 50 characters), bump PKG_RELEASE]
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
- Remove obsolete patch chunks regarding fixed_freq
- Instead of patching in custom HT40+/- parameters, use the standard
config syntax as much as possible.
- Use fixed_freq for mesh
- Fix issues with disabling obss scan when using fixed_freq on mesh
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The wpa_supplicant code for IBSS allows to set the mcast rate. It is
recommended to increase this value from 1 or 6 Mbit/s to something higher
when using a mesh protocol on top which uses the multicast packet loss as
indicator for the link quality.
This setting was unfortunately not applied for mesh mode. But it would be
beneficial when wpa_supplicant would behave similar to IBSS mode and set
this argument during mesh join like authsae already does. At least it is
helpful for companies/projects which are currently switching to 802.11s
(without mesh_fwding and with mesh_ttl set to 1) as replacement for IBSS
because newer drivers seem to support 802.11s but not IBSS anymore.
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Tested-by: Simon Wunderlich <simon.wunderlich@openmesh.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [refresh]
When sta is configured, hostapd receives 'stop' and 'update' command from
wpa_supplicant. In the update command, hostapd gets sta parameters with
which it configures ap.
Problem is, with the default wireless configuration:
mode:11g freq:2.4GHz channel:1
If sta is connected to 5GHz network, then ap does not work. Ideally with
340-reload_freq_change.patch hostapd should reload the frequency changes
and start ap in 5GHz, but ap becomes invisible in the network.
This issue can be reproduced with following /etc/config/wireless:
config wifi-device radio0
option type mac80211
option channel 1
option hwmode 11g
option path 'virtual/uccp420/uccwlan'
option htmode 'none'
config wifi-iface 'ap'
option device 'radio0'
option encryption 'none'
option mode 'ap'
option network 'ap'
option ssid 'MyTestNet'
option encryption none
config wifi-iface 'sta'
option device radio0
option network sta
option mode sta
option ssid TestNet-5G
option encryption psk2
option key 12345
This change updates current_mode structure based on configured hw_mode
received from wpa_supplicant. Also prepare rates table after frequency
selection.
Signed-off-by: Abhilash Tuse <Abhilash.Tuse@imgtec.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [cleanup, patch refresh]
It wasn't possible to read hostapd wpa_printf messages unless running
hostapd manually. It was because hostapd was printing them using vprintf
and not directly to the syslog.
We were trying to workaround this problem by redirecting STDIN_FILENO
and STDOUT_FILENO but it was working only for the initialization phase.
As soon as hostapd did os_daemonize our solution stopped working.
Please note despite the subject this change doesn't affect debug level
messages only but just everything printed by hostapd with wpa_printf
including MSG_ERROR-s. This makes it even more important as reading
error messages can be quite useful for debugging.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Update to latest upstream HEAD:
- Refreshed all
- Delete patches and parts which made it upstream
Compile tested Full & Mini configs
Run-tested Mini config
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [another update, remove broken patch]
This more of a demo for the previous commit that comes with
this one, where I added support for copying source from 'src' to
the build dir(s).
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
One second is not enough for some devices to ackowledge null data frame
which is sent at the end of ap_max_inactivity interval. In particular,
this causes severe Wi-Fi instability with Apple iPhone which may take
up to 3 seconds to respond.
Signed-off-by: Dmitry Ivanov <dima@ubnt.com>
SVN-Revision: 47149
When using FullMAC drivers (e.g. brcmfmac) we don't get mgmt frames so
check for banned client in probe request handler won't ever be used.
Since cfg80211 provides us info about STA associating let's put a check
there.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 47064
r45270 removed ieee80211n=%d from the format string but didn't remove
the parameter itself. Though this probably doesn't cause any harm, it's
quite confusing and unneeded.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 45351
madwifi was dropped upstream, can't find it anywhere in OpenWrt
either, thus finally burrying madwifi.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45045
This change adds the configuration options "bssid_whitelist" and
"bssid_blacklist" used to limit the AP selection of a network to a
specified (finite) set or discard certain APs.
This can be useful for environments where multiple networks operate
using the same SSID and roaming between those is not desired. It is also
useful to ignore a faulty or otherwise unwanted AP.
In many applications it is useful not just to enumerate a group of well
known access points, but to use a address/mask notation to match an
entire set of addresses (ca:ff:ee:00:00:00/ff:ff:ff:00:00:00).
This is especially useful if an OpenWrt device with two radios is used to
retransmit the same network (one in AP mode for other clients, one as STA for
the uplink); the following configuration prevents the device from associating
with itself, given that the own AP to be avoided is using the bssid
'C0:FF:EE:D0:0D:42':
config wifi-iface
option device 'radio2'
option network 'uplink'
option mode 'sta'
option ssid 'MyNetwork'
option encryption 'none'
list bssid_blacklist 'C0:FF:EE:D0:0D:42/00:FF:FF:FF:FF:FF'
This change consists of the following cherry-picked upstream commits:
b3d6a0a8259002448a29f14855d58fe0a624ab76
b83e455451a875ba233b3b8ac29aff8b62f064f2
79cd993a623e101952b81fa6a29c674cd858504f
(squashed to implement bssid_{white,black}lists)
0047306bc9ab7d46e8cc22ff9a3e876c47626473
(Add os_snprintf_error() helper)
Signed-off-by: Stefan Tomanek <stefan.tomanek+openwrt@wertarbyte.de>
SVN-Revision: 44438
This patch fixes adding new stations for some specific drivers when
using more than 1 BSS.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 43951
With this patch WPS discovery can be started or canceled over ubus if
WPS is enabled in wireless configuration. This is equivalent of
'hostapd_cli wps_pbc' and 'hostapd_cli wps_cancel' commands.
Signed-off-by: Petar Koretic <petar.koretic@sartura.hr>
SVN-Revision: 42459
Fixed wpa_supplicant when the radio is in 40MHz mode so that it no
longer restarts hostapd with the second channel disabled.
Signed-off-by: Lance Chaney <furryfur1@gmail.com>
SVN-Revision: 41019
