Merge the practically copy-pasted implementations in wpa_supplicant and
hostapd into a single shared implementation in dpp.c for managing
configurator and boostrapping information. This avoid unnecessary code
duplication and provides a convenient location for adding new global DPP
data.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The memcpy calls added for exposing the PMK from wpa_auth module could
end up trying to copy the same memory buffer on top of itself.
Overlapping memory areas are not allowed with memcpy, so this could
result in undefined behavior. Fix this by making the copies conditional
on the updated value actually coming from somewhere else.
Fixes: b08c9ad0c7 ("AP: Expose PMK outside of wpa_auth module")
Signed-off-by: Jouni Malinen <j@w1.fi>
This code was after the FILS handling that would have encrypted the
frame. While FILS and OWE are never used together, the OWE handling
should really be before the FILS handling since no IEs can be added
after the FILS encryption step. In addition, the Diffie-Hellman
Parameter element is not a Vendor Specific element, so it should be
before some of the Vendor Specific elements even though it is not
defined in IEEE 802.11.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use Diffie-Hellman key exchange to derivate additional material for
PMK-to-PTK derivation to get PFS. The Diffie-Hellman Parameter element
(defined in OWE RFC 8110) is used in association frames to exchange the
DH public keys. For backwards compatibility, ignore missing
request/response DH parameter and fall back to no PFS in such cases.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
DPP allows Diffie-Hellman exchange to be used for PFS in PTK derivation.
This requires an additional Z.x (x coordinate of the DH shared secret)
to be passed to wpa_pmk_to_ptk(). This commit adds that to the function
and updates all the callers to pass NULL,0 for that part in preparation
of the DPP specific changes to start using this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous OWE implementation on the AP side rejected any
(Re)Association Request frame with the Diffie-Hellman Parameter element
if AKM was not OWE. This breaks compatibility with DPP PFS, so relax
that rule to allow DPP AKM to be used as well. While this commit alone
does not add support for PFS, this allows interoperability between
non-PFS implementation on the AP and a newer PFS implementation on the
STA.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Share a single parsing implementation for both hostapd and
wpa_supplicant to avoid code duplication. In addition, clean up the
implementation to be more easily extensible.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The queue_len * 50 ms wait time was too large with the retransmission
timeouts used in the mesh case for SAE. The maximum wait of 750 ms was
enough to prevent successful completion of authentication after having
hit the maximum queue length. While the previous commit is enough to
allow this to complete successfully in couple of retries, it looks like
a smaller wait time should be used here even if it means potentially
using more CPU.
Drop the processing wait time to queue_len * 10 ms so that the maximum
wait time is 150 ms if the queue is full.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous design of simply queuing all SAE commit messages was not
exactly good at allowing recovery from a flooding state if the valid
peer used frequent retransmissions of the SAE message. This could
happen, e.g., with mesh BSSs using SAE. The frequent retransmissions and
restarts of SAE authentication combined with SAE confirm messages
bypassing the queue ended up in not being able to finish SAE exchange
successfully.
Fix this by modifying the queuing policy to queue SAE confirm messages
if there is a queued SAE commit message from the same peer so that the
messages within the same exchange do not get reordered. In addition,
replace queued SAE commit/confirm message if a new matching message is
received from the same peer STA. This is useful for the case where the
peer restarts SAE more quickly than the local end has time to process
the queued messages.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use this new message from Enrollee to Configurator to indicate result of
the config object provisioning if both devices support protocol version
2 or newer.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Derive PMKR1Name during the FILS authentication step, verify that the
station uses matching PMKR1Name in (Re)Association Request frame, and
add RSNE[PMKR1Name] into (Re)Association Response frame when going
through FT initial mobility domain association using FILS. These steps
were missed from the initial implementation, but are needed to match the
IEEE 802.11ai requirements for explicit confirmation of the FT key
hierarchy (similarly to what is done in FT 4-way handshake when FILS is
not used).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This gets rid of a confusing error message "FILS: Failed to add PMKSA
cache entry based on ERP" for cases where PMKSA caching is disabled in
hostapd (disable_pmksa_caching=1). Functionality remains unchanged,
i.e., no cache entry was added before this change either.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
hostapd configuration parameters fragm_threshold and rts_threshold were
documented to disable the threshold with value -1 and not change driver
configuration if the parameter is not included. However, -1 was mapped
into not changing the driver value, so the explicit disabling part did
not work.
Replace the default values for these to be -2 so that explicitly set
configuration value -1 can be distinguished from the case of not
including the parameter. Map the -1 value to a driver request to disable
the threshold. Ignore any error from this operation just in case to
avoid breaking functionality should some drivers not accept the (u32) -1
value as a threshold value request to disable the mechanism.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This patch added 'check_cert_subject' support to match the value of
every field against the DN of the subject in the client certificate. If
the values do not match, the certificate verification will fail and will
reject the user.
This option allows hostapd to match every individual field in the right
order, also allow '*' character as a wildcard (e.g OU=Development*).
Note: hostapd will match string up to 'wildcard' against the DN of the
subject in the client certificate for every individual field.
Signed-off-by: Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com>
Signed-off-by: Jared Bents <jared.bents@rockwellcollins.com>
Signed-off-by: Jouni Malinen <j@w1.fi>
Include only one of hostapd_mgmt_rx() and hostapd_action_rx() functions
in the build. Previously, NEED_AP_MLME builds (i.e., cases where hostapd
AP MLME implementation is included) included both of these functions and
both were tried in sequence. In addition to being difficult to
understand, that could result in unexpected behavior if
hostapd_mgmt_rx() rejected a frame and return 0 to allow
hostapd_action_rx() to attempt to process the frame.
All the operations included in hostapd_action_rx() are supposed to be
available through the hostapd_mgmt_rx() call in handle_action() and
those should result in the exact same Category/Action-based handler
function to be called in the end. As such, this should not result in
different behavior. And if there is a difference, that would be pointing
at a hidden bug that would need to be fixed anyway. Furthermore, builds
without NEED_AP_MLME would not have any difference in behavior or
contents of the binary either.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no need to go through the following handler calls in
hostapd_action_rx() after having found the matching WLAN_ACTION_WNM
handler.
Signed-off-by: Jouni Malinen <j@w1.fi>
hostapd_action_rx() was pointing at incorrect field (Action vs.
Category) for the wpa_ft_action_rx() call and the length check for SA
Query Action frames. This resulted in those frames getting dropped as
invalid (FT) or ignored as truncated (SA Query). Fix this by pointing to
the correct place at the beginning of the frame body.
This issue had a long history. These were broken during cleanup in
commit dbfb8e82ff ("Remove unnecessary EVENT_RX_ACTION") which
actually fixed the initial reason for the error accidentally. It was
just that that error was needed to cancel out another earlier error..
One of the errors came from misuse of the EVENT_RX_ACTION API in commit
deca6eff74 ("atheros: Add new IEEE 802.11r driver_ops"). That pointed
struct rx_action data/len to cover the Action frame from the Category
field to the end of the frame body while the API was documented to cover
Action field to the end of the frame body. This error was cancelled by
another error in commit 88b32a99d3 ("FT: Add FT AP support for drivers
that manage MLME internally") that called wpa_ft_action_rx() with the
struct rx_action::data field as the second argument. That argument needs
to point to the Category field, but that struct rx_action field was
supposed to point to the Action field.
Number of the Action frame handlers added into hostapd_action_rx() had
been fixed more or less accidentally after this in various other
commits, but the FT and SA Query handlers had ended up maintaining the
incorrect operations. This is now fixing those.
This seems to fix at least some cases of FT-over-DS with drivers that
use driver-based AP MLME. Such drivers might use internal SA Query
processing, so it is not clear whether that part actually fixes any real
issues.
Signed-off-by: Jouni Malinen <j@w1.fi>
Copy the Finite Cyclic Group field value from the request to the
response Authentication frame if we end up rejecting the request due to
unsupported group.
IEEE Std 802.11-2016 has conflicting statements about this behavior.
Table 9-36 (Presence of fields and elements in Authentication frames)
indicates that the Finite Cyclic Group field is only included with
status code values 0 (success) and 76 (anti-clogging token request)
while SAE protocol description implying that the Finite Cyclic Group
field is set to the rejected group (12.4.8.6.3 and 12.4.8.6.4).
The standard language needs to cleaned up to describe this
unambiguously, but since it looks safe to add the field into the
rejection case and since there is desire to have the field present to be
able to implement what exactly is stated in 12.4.8.6.4, it looks
reasonable to move ahead with the AP mode implementation change. There
is no change in wpa_supplicant for now to modify its behavior based on
whether this field is present, i.e., wpa_supplicant will continue to
work with both the old and new hostapd behavior for SAE group
negotiation.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new hostapd configuration parameter wps_cred_add_sae=1 can be used
to request hostapd to add SAE configuration whenever WPS is used to
configure the AP to use WPA2-PSK and the credential includes a
passphrase (instead of PSK). This can be used to enable WPA3-Personal
transition mode with both SAE and PSK enabled and PMF enabled for PSK
and required for SAE associations.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Do not start SAE authentication from scratch if a STA starts a new
attempt for the same group while we still have previously generated PWE
available. Instead, use the previously generated PWE as-is and skip
anti-clogging token exchange since the heavy processing is already
completed. This saves unnecessary processing on the AP side in case the
STA failed to complete authentication on the first attempt (e.g., due to
heavy SAE load on the AP causing a timeout) and makes it more likely for
a valid STA to be able to complete SAE authentication during a DoS
attack.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add a 16-bit token index into the anti-clogging token. This can be used
to enforce only a single use of each issued anti-clogging token request.
The token value is now token-index |
last-30-octets-of(HMAC-SHA256(sae_token_key, STA-MAC-address |
token-index)), i.e., the first two octets of the SHA256 hash value are
replaced with the token-index and token-index itself is protected as
part of the HMAC context data.
Track the used 16-bit token index values and accept received tokens only
if they use an index value that has been requested, but has not yet been
used. This makes it a bit more difficult for an attacker to perform DoS
attacks against the heavy CPU operations needed for processing SAE
commit since the attacker cannot simply replay the same frame multiple
times and instead, needs to request each token separately.
While this does not add significant extra processing/CPU need for the
attacker, this can be helpful in combination with the queued processing
of SAE commit messages in enforcing more delay during flooding of SAE
commit messages since the new anti-clogging token values are not
returned before the new message goes through the processing queue.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This allows better control of processing new SAE sessions so that other
operations can be given higher priority during bursts of SAE requests,
e.g., during a potential DoS attack. The receive commit messages are
queued (up to maximum of 15 entries) and processed from eloop callback.
If the queue has multiple pending entries, more wait time is used to go
through the each new entry to reduce heavy CPU load from SAE processing.
Enable anti-clogging token use also based on the pending commit message
queue and not only based on the already started sessions.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Change the AP mode default for SAE to enable only the group 19 instead
of enabling all ECC groups that are supported by the used crypto library
and the SAE implementations. The main reason for this is to avoid
enabling groups that are not as strong as the mandatory-to-support group
19 (i.e., groups 25 and 26). In addition, this disables heavier groups
by default.
In addition, add a warning about MODP groups 1, 2, 5, 22, 23, and 24
based on "MUST NOT" or "SHOULD NOT" categorization in RFC 8247. All the
MODP groups were already disabled by default and would have needed
explicit configuration to be allowed.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This extension of VLAN assignment code had a bug in one of the code
paths where vlan_id could have been left uninitialized. This could
result in SAE authentication getting rejected in cases where VLAN
assignment is not used if the uninitialized stack memory had nonzero
value.
Fixes: dbfa691df4 ("VLAN assignment based on used WPA/WPA2 passphrase/PSK")
Signed-off-by: Jouni Malinen <j@w1.fi>
Avoid an unnecessary unsigned integer overflow warning due to loop index
j-- use.
hostapd.c:661:10: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned int'
Signed-off-by: Jouni Malinen <j@w1.fi>
(&mgmt->u.deauth.reason_code + 1) is not exactly clean and now that we
have the u8 variable[] member in the struct after this field, use that
directly to avoid clang compiler warning:
ctrl_iface_ap.c:454:18: error: taking address of packed member
'reason_code' of class or structure 'ieee80211_mgmt::(anonymous
union)::(anonymous)' may result in an unaligned pointer value
[-Werror,-Waddress-of-packed-member]
Signed-off-by: Jouni Malinen <j@w1.fi>
Split the check and decrementation into separate steps to avoid an
unnecessary UBSan warning.
hostapd.c:1895:14: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long')
Signed-off-by: Jouni Malinen <j@w1.fi>
hapd->conf might be NULL in case initialized failed, so better be
prepared for that when debug printing interface name in the deinit path.
hostapd.c:312:54: runtime error: member access within null pointer of type 'struct hostapd_bss_config'
hostapd.c:351:29: runtime error: member access within null pointer of type 'struct hostapd_bss_config'
hostapd.c:2158:18: runtime error: member access within null pointer of type 'struct hostapd_bss_config'
Signed-off-by: Jouni Malinen <j@w1.fi>
iface->num_bss is unsigned integer, so need to explicit typecast it to
unsigned before decrementation by one even when the result is stored in
an unsigned integer.
../src/ap/hostapd.c:2185:26: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long'
Signed-off-by: Jouni Malinen <j@w1.fi>
According to IEEE Std 802.11-2016, 9.4.2.25 when fields of an RSNE are
not included, the default values are used. The cipher suite defaults
were hardcoded to CCMP in the previous implementation, but the default
is actually different for DMG: GCMP (per 9.4.2.25.2).
It is not possible to find out from the RSNE if the network is non-DMG
or DMG, so callers of wpa_parse_wpa_ie_rsn() need to handle this case
based on context, which can be different for each caller.
In order to fix this issue, add flags to the wpa_ie_data indicating
whether pairwise/group ciphers were included in the RSNE. Callers can
check these flags and fill in the appropriate ciphers. The
wpa_parse_wpa_ie_rsn() function still initializes the ciphers to CCMP by
default so existing callers will not break. This change also fixes some
callers which need to handle the DMG network case.
Signed-off-by: Lior David <liord@codeaurora.org>
The Wi-Fi Alliance Multi-AP Specification v1.0 allows onboarding of a
backhaul STA through WPS. To enable this, the WPS Registrar offers a
different set of credentials (backhaul credentials instead of fronthaul
credentials) when the Multi-AP subelement is present in the WFA vendor
extension element of the WSC M1 message.
Add new configuration options to specify the backhaul credentials for
the hostapd internal registrar: multi_ap_backhaul_ssid,
multi_ap_backhaul_wpa_psk, multi_ap_backhaul_wpa_passphrase. These are
only relevant for a fronthaul SSID, i.e., where multi_ap is set to 2 or
3. When these options are set, pass the backhaul credentials instead of
the normal credentials when the Multi-AP subelement is present.
Ignore the Multi-AP subelement if the backhaul config options are not
set. Note that for an SSID which is fronthaul and backhaul at the same
time (i.e., multi_ap == 3), this results in the correct credentials
being sent anyway.
The security to be used for the backaul BSS is fixed to WPA2PSK. The
Multi-AP Specification only allows Open and WPA2PSK networks to be
configured. Although not stated explicitly, the backhaul link is
intended to be always encrypted, hence WPA2PSK.
To build the credentials, the credential-building code is essentially
copied and simplified. Indeed, the backhaul credentials are always
WPA2PSK and never use per-device PSK. All the options set for the
fronthaul BSS WPS are simply ignored.
Signed-off-by: Davina Lu <ylu@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Marianna Carrera <marianna.carrera.so@quantenna.com>
The Multi-AP specification only specifies that information elements have
to be added to the Association Request and Association Response frame;
it doesn't specify anything about what should be done in case they are
missing. Previously, we rejected non-backhaul associations on a
backhaul-only BSS, and non-fronthaul associations on a fronthaul-only
BSS.
However, this makes WPS fail when fronthaul and backhaul are separate
SSIDs. Indeed, WPS for the backhaul link is performed on the *fronthaul*
SSID. Thus, the Association Request frmae used for WPS *will* contain
the Multi-AP IE indicating a backhaul STA. Rejecting that association
makes WPS fail.
Therefore, accept a multi-AP backhaul STA Association Request frame on a
fronthaul-only BSS. Still issue a warning about it, but only at level
DEBUG intead of INFO. Also change the condition checking to make it
clearer.
While we're at it, also fix the handling of unexpected bits in the
Multi-AP IE. 4 bits are reserved in the specification, so these
certainly have to be ignored. The specification also doesn't say that
setting one of the other bits is not allowed. Therefore, only report
unexpected values in the Multi-AP IE, don't reject because of it. Note
that a malformed IE (containing more than one byte) still triggers a
rejection.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
str_token() can return NULL for the name if the remaining token contains
only the delimiter. Fix this to avoid NULL pointer dereference with a
corner case of an invalid value used in the configuration.
Fixes: ec5c39a557 ("AP: Allow identifying which passphrase station used with wpa_psk_file")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new sae_password parameter [|vlanid=<VLAN ID>] can now be used to
assign stations to a specific VLAN based on which SAE Password
Identifier they use. This is similar to the WPA2-Enterprise case where
the RADIUS server can assign stations to different VLANs and the
WPA2-Personal case where vlanid parameter in wpa_psk_file is used.
Signed-off-by: Jouni Malinen <j@w1.fi>
Extend wpa_psk_file to allow an optional VLAN ID to be specified with
"vlanid=<VLAN ID>" prefix on the line. If VLAN ID is specified and the
particular wpa_psk_file entry is used for a station, that station is
bound to the specified VLAN. This can be used to operate a single
WPA2-Personal BSS with multiple VLANs based on the used passphrase/PSK.
This is similar to the WPA2-Enterprise case where the RADIUS server can
assign stations to different VLANs.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If the ap_handle_timer() timeout is reached for a not-associated STA, do
not default to disassociating that STA first since Disassociation frame
is not really appropriate to send to a STA that is not in associated
state. Instead, skip directly to deauthentication and STA entry removal.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add test-eapol program that can be used for fuzzing the EAPOL-Key
Supplicant and Authenticator implementations. This tool can write
Supplicant or Authenticator messages into a file as an initialization
step and for the fuzzing step, that file (with potential modifications)
can be used to replace the internally generated message contents.
The TEST_FUZZ=y build parameter is used to make a special build where a
hardcoded random number generator and hardcoded timestamp are used to
force deterministic behavior for the EAPOL-Key operations. This will
also make the implementation ignore Key MIC and AES keywrap errors to
allow processing of modified messages to continue further.
Signed-off-by: Jouni Malinen <j@w1.fi>
ieee802_11_rx_wnmsleep_req() might have been called for a short frame
that has no more payload after the Public Action field, i.e., with len
== 0. The bounds checking for the payload length was done only for the
information elements while the one octet Dialog Token field was read
unconditionally. In the original implementation, this could have
resulted in reading one octet beyond the end of the received frame data.
This case has not been reachable after the commit e0785ebbbd ("Use
more consistent Action frame RX handling in both AP mode paths"), but it
is better to address the specific issue in ieee802_11_rx_wnmsleep_req()
as well for additional protection against accidential removal of the
check and also to have something that can be merged into an older
version (pre-v2.7) if desired. The comments below apply for such older
versions where the case could have been reachable.
Depending on driver interface specific mechanism used for fetching the
frame, this could result in reading one octet beyond the end of a
stack/hash buffer or reading an uninitialized octet from within a
buffer. The actual value that was read as the Dialog Token field is not
used since the function returns immediately after having read this value
when there is no information elements following the field.
This issue was initially added in commit d32d94dbf4 ("WNM: Add
WNM-Sleep Mode implementation for AP") (with CONFIG_IEEE80211V=y build
option) and it remained in place during number of cleanup and fix
changes in this area and renaming of the build parameter to
CONFIG_WNM=y. The impacted function was not included in any default
build without one of the these optional build options being explicitly
enabled. CONFIG_WNM=y is still documented as "experimental and not
complete implementation" in hostapd/defconfig. In addition, commit
114f2830d2 ("WNM: Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0
case") made this function exit before the impact read if WNM-Sleep Mode
support was not explicitly enabled in runtime configuration
(wnm_sleep_mode=1 in hostapd.conf). Commit e0785ebbbd ("Use more
consistent Action frame RX handling in both AP mode paths") made this
code unreachable in practice.
Add an explicit check that the frame has enough payload before reading
the Dialog Token field in ieee802_11_rx_wnmsleep_req().
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This patch adds a new flag 'crl_reload_interval' to reload CRL
periodically. This can be used to reload ca_cert file and the included
CRL information on every new TLS session if difference between the last
reload and the current time in seconds is greater than
crl_reload_interval.
This reloading is used for cases where check_crl is 1 or 2 and the CRL
is included in the ca_file.
Signed-off-by: Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com>
Signed-off-by: Jared Bents <jared.bents@rockwellcollins.com>
It is now possible to optionally specify keyid for
each wpa_psk_file entry:
keyid=something 00:00:00:00:00:00 secretpassphrase
When station connects and the passphrase it used
has an associated keyid it will be appended to the
AP-STA-CONNECTED event string:
wlan0: AP-STA-CONNECTED 00:36:76:21:dc:7b keyid=something
It's also possible to retrieve it through the control interface:
$ hostapd_cli all_sta
Selected interface 'ap0'
00:36:76:21:dc:7b
...
keyid=something
New hostapd is able to read old wpa_psk_file. However, old hostapd will
not be able to read the new wpa_psk_file if it includes keyids.
Signed-off-by: Michal Kazior <michal@plume.com>
This doesn't change any behavior on its own. It's going to be used to
expose per-station keyids and allow reloading passphrases in runtime.
Signed-off-by: Michal Kazior <michal@plume.com>
Support the new Extended Capabilities field bits 81 and 82 to indicate
whether SAe Password Identifiers are in use.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add support for configuring parameters for the MU EDCA Parameter Set
element per IEEE P802.11ax/D3.0.
Signed-off-by: Siva Mullati <siva.mullati@intel.com>
When an interface is re-enabled after it was disabled during CAC, it
won't ever get active since hostapd is waiting for a CAC_FINISHED while
kernel side is waiting for a CMD_RADAR_DETECT to start a CAC.
This commit checks for a pending CAC when an interface is enabled and if
so restarts its DFS processing.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
While the AP is configured to enable both FT-PSK and WPA-PSK, an HP
printer request both AKMs (copied from AP?) in Association Request
frame, but don't add MDIE and don't use FT. This results in the
connection failing.
Next in logs we see:
RSN: Trying to use FT, but MDIE not included
IE - hexdump(len=26): 30 18 01 00 00 0f ac 04 01 00 00 0f ac 04
02 00 00 0f ac 02 00 0f ac 04 00 00
This is seen with some HP and Epson printers. Work around this by
stripping FT AKM(s) when MDE is not present and there is still a non-FT
AKM available.
Signed-off-by: Janusz Dziedzic <janusz@plumewifi.com>
While selecting a new channel as a reaction to radar event we need to
take into account supported bandwidth for each channel provided via
nl80211. Without this modification hostapd might select an unsupported
channel that would fail during AP startup.
Signed-off-by: Dmitry Lebed <dlebed@quantenna.com>
While doing automatic channel selection we need to take into account
supported bandwidth for each channel provided via nl80211. Without this
modification hostapd might select an unsupported channel which would
fail during AP startup.
Signed-off-by: Dmitry Lebed <dlebed@quantenna.com>
This adds checks to common code to verify supported bandwidth options
for each channel using nl80211-provided info. No support of additional
modes is added, just additional checks. Such checks are needed because
driver/hardware can declare more strict limitations than declared in the
IEEE 802.11 standard. Without this patch hostapd might select
unsupported channel and that will fail because Linux kernel does check
channel bandwidth limitations.
Signed-off-by: Dmitry Lebed <dlebed@quantenna.com>
