Include and verify the OCI element in AMPE Open and Confirm frames. Note
that the OCI element is included even if the other STA didn't advertise
support of OCV. The OCI element is only required and verified if both
peers support OCV.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
APs and mesh peers use the VHT Operation element to advertise certain
channel properties (e.g., the bandwidth of the channel). Save this
information element so we can later access this information.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
Make the buf_len calculation match more closely with the following
wpa_buf*() operations. The extra room from the existing elements was
apparently sufficiently large to cover this, but better add the two
octet header explicitly.
Signed-off-by: Jouni Malinen <j@w1.fi>
The maximum size of a Mesh Peering Management element in the case
of an AMPE close frame is actually 24 bytes, not 23 bytes, plus the
two bytes of the IE header (IEEE Std 802.11-2016, 9.4.2.102). Found by
inspection.
The other buffer components seem to use large enough extra room in their
allocations to avoid hitting issues with the full buffer size even
without this fix.
Signed-off-by: Bob Copeland <bobcopeland@fb.com>
Reword the comments to make gcc 8.1 recognize these as designed cases
and not trigger implicit-fallthrough warnings.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Let mesh STA A be a STA which has config disable_ht=1.
Let mesh STA B be a STA which has config disable_ht=0.
The mesh STA A and B was connected.
Previously, the mesh STA A sent frame with HT rate even though its HT
was disabled. This commit fixes the issue by checking the local BSS HT
configuration.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
The remote mesh STA which had configuration disable_ht40=1 could have HT
Capabilities element which includes Supported Channel Width Set = 1
(both 20 MHz and 40 MHz operation is supported) even though it had HT
Operation element which includes STA Channel Width = 0 (20 MHz channel
width only). Previously, local peer recognized such a remote peer as 40
MHz band width enabled STA because local peer only checked HT
Capabilities element. This could cause disconnection between
disable_ht40=1 mesh STA and disable_ht40=0 mesh STA. They could
establish a mesh BSS but could not ping with ath9k_htc device. This
commit fixes the issue by refering HT Operation element.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Some deployed stations incorrectly consider nsts capability in
(Re)Association Response frame as required capability instead of maximum
capability and if it is greater than station's capability then beamform
will not happen in uplink traffic.
This commit adds support for an optional workaround to use station's
nsts capability in (Re)Association Response frame if the station's nsts
is less than AP by using the use_sta_nsts=1 configuration parameter.
This configuration is introduced in this commit and it is disabled by
default.
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Previously, mesh power management functionality works only with kernel
MPM. Because user space MPM did not report mesh peer AID to kernel,
the kernel could not identify the bit in TIM element. So this patch
reports mesh peer AID to kernel.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
{OPN,CNF,CLS}_IGNR events were removed during P802.11s draft development
process. Replace these with not generating a MPM FSM event. In addition,
add the standard REQ_RJCT event and option to pass in a specific reason
code to mesh_mpm_fsm().
Signed-off-by: Jouni Malinen <j@w1.fi>
During the P802.11s draft development, there were separate LISTEN and
IDLE states. However, the current IEEE 802.11 standards uses only the
IDLE state while the implementation called this LISTEN. Rename the state
in the implementation to match the one used in the standard to avoid
confusion. In addition, rename OPEN_{SENT,RCVD} to OPN_{SNT,RCVD} to
match the exact spelling of these states in the standard.
Signed-off-by: Jouni Malinen <j@w1.fi>
REVmc/D6.0 14.5.5.2.2 (Processing Mesh Peering Open frames for AMPE)
mandates the OPN_RJCT event to be invoked if AES-SIV decryption for
received Mesh Peering Open frame fails. This allows a Mesh Peering Close
frame to be sent in such a case.
Signed-off-by: Jouni Malinen <j@w1.fi>
The "Accepting Additional Mesh Peerings bit == 0" means the peer cannot
accept any more peers, so suppress attempt to open a connection to such
a peer.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
This moves pairwise, group, and management group ciphers to various mesh
data structures to avoid having to hardcode cipher in number of places
through the code. While CCMP and BIP are still the hardcoded ciphers,
these are now set only in one location.
Signed-off-by: Jouni Malinen <j@w1.fi>
The AMPE element includes number of optional and variable length fields
and those cannot really be represented by a fixed struct
ieee80211_ampe_ie. Remove the optional fields from the struct and
build/parse these fields separately.
This is also adding support for IGTKdata that was completely missing
from the previous implementation. In addition, Key RSC for MGTK is now
filled in and used when configuring the RX MGTK for a peer.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous implementation was incorrect in forcing the MGTK to be used
as the IGTK as well. Define new variable for storing IGTK and use that,
if set, to configure IGTK to the driver. This commit does not yet fix
AMPE element parsing to fill in this information.
Signed-off-by: Jouni Malinen <j@w1.fi>
This extends the data structures to allow variable length MGTK to be
stored for RX. This is needed as an initial step towards supporting
different cipher suites.
Signed-off-by: Jouni Malinen <j@w1.fi>
IEEE Std 802.11-2012 13.5.6.3 State transitions require an action
sending SETKEYS primitive to MAC when OPN_ACPT event occurs in CNF_RCVD
state in case of AMPE is used, but since MTK calculation is missed in
this condition, all zero valued key are passed to MAC and cause unicast
packet decryption error. This could happen if the first transmission of
plink Open frame is dropped and Confirm frame is processed first
followed by retransmitted Open frame.
Fix this by calculating the MTK also in this sequence of unexpected
messages.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
IEEE Std 802.11-2012 Table 13-2, MPM finite state machine requires to
clear retryTimer when CNF_ACPT event occurs in OPN_SNT state which is
missing, so add it to comply with the standard.
This was found while debugging an MTK issue and this commit fixes a
potential issue that mesh sends invalid event (PLINK_OPEN) which will
lead another invalid timer register such as MeshConfirm Timer. This
behaviour might lead to undefined mesh state.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
This patch add functionality of mesh SAE PMKSA caching. If the local STA
already has peer's PMKSA entry in the cache, skip SAE authentication and
start AMPE with the cached value.
If the peer does not support PMKSA caching or does not have the local
STA's PMKSA entry in the cache, AMPE will fail and the PMKSA cache entry
of the peer will be removed. Then STA retries with ordinary SAE
authentication.
If the peer does not support PMKSA caching and the local STA uses
no_auto_peer=1, the local STA can not retry SAE authentication because
NEW_PEER_CANDIDATE event cannot start SAE authentication when
no_auto_peer=1. So this patch extends MESH_PEER_ADD command to use
duration(sec). Throughout the duration, the local STA can start SAE
authentication triggered by NEW_PEER_CANDIDATE even though
no_auto_peer=1.
This commit requires commit 70c93963ed
('SAE: Fix PMKID calculation for PMKSA cache'). Without that commit,
chosen PMK comparison will fail.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
This allows a mesh peer connection to be initiated manually in
no_auto_peer mesh networks.
Signed-off-by: Natsuki Itaya <Natsuki.Itaya@jp.sony.com>
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
This command allows the specified mesh peer to be disconnected.
Signed-off-by: Natsuki Itaya <Natsuki.Itaya@jp.sony.com>
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
When a mesh point reconnects by starting from Authentication frame
sequence, the plink count was not decremented from its last connection.
This resulted in leaking peer link count and causing wpa_supplicant to
reject the connection after max_peer_links (default: 99) reconnects.
This was reproduced by pre-configuring 2 mesh points with mesh
credentials. Boot both mesh points and make sure they connect to each
other. Then in a loop reboot one of the mesh points after it
successfully connects while leaving the other mesh point up and running.
After 99 iterations the supplicant on mesh point that is not rebooting
will reject the connection request from the other mesh point.
Fix this by decrementing num_plinks when freeing a STA entry that is
still in PLINK_ESTAB state.
Signed-off-by: Srinivasa Duvvuri <sduvvuri@chromium.org>
If the local driver indicated a peer candidate event when the peer had
already initiated peering exchange in open mesh case, we used to force a
new exchange to be started instead of allowing the previously started
exchange to complete. This is not desirable, so make this initiation of
the new exchange conditional on there not being an already started (or
successfully completed) exchange.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the local driver event for a new peer candidate arrived only after
the peer had already initiated the peering exchange, we used to clear
the link state. This resulted in the already completed (or in progress)
exchange getting abandoned and a new exchange initiated. This is not
desirable since the already started (or even completed) exchange can be
used. Clear the link state only when adding the new STA entry for the
first time, i.e., use the same !sta->my_lid condition in handling the
driver event similarly to how the peer initiated cases were already
handled.
Signed-off-by: Jouni Malinen <j@w1.fi>
The messages were sent out with wpa_msg_ctrl() so they were not visible
in the debug log. However, these would be quite helpful strings to
search for in the debug log, so change these messages to use wpa_msg().
Signed-off-by: Jouni Malinen <j@w1.fi>
Provide details on the pointers to the subfields and rename "pmk" to
"chosen_pmk" and use SAE_PMKID_LEN macro with it to make the code more
readable.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
From IEEE Std 802.11-2012 13.3.5:
If the incoming Mesh Peering Management frame is for AMPE and the
Chosen PMK from the received frame contains a PMKID that does not
identify a valid mesh PMKSA, the frame shall be silently discarded.
We were not checking the PMKID previously, and we also weren't parsing
it correctly, so fix both.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Mesh Points themselves have capability to support VHT as long as
hardware supports it. However, supporting VHT in mesh mode was disabled
because no one had clearly tested and confirmed its functionality. Since
VHT80 has now been verified to work with ath10k QCA988X driver and
mac80211_hwsim, enable VHT support in mesh mode.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
Set WLAN_STA_WMM flag to Mesh STA by default since Mesh STAs are QoS
STAs. Mesh STA's HT capabilities won't be parsed properly without the
flag.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
IEEE Std 802.11-2012 13.3.1 states that the AID should be generated on
the local node for each peer. Previously, we were using the peer link ID
(generated by the peer) which may not be unique among all peers. Correct
this by reusing the AP AID generation code.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
The RSN IE is required by IEEE Std 802.11-2012 on SAE use case:
Table 8-262 Mesh Peering Open frame Action field format
Table 8-263 Mesh Peering Confirm frame Action field format
Add the RSN IE to these frames.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Check the element length in the parser and remove the length field from
struct ieee802_11_elems since the element is of fixed length.
Signed-off-by: Jouni Malinen <j@w1.fi>
Currently, there is a race in open mesh networks where mesh STA A
receives a beacon from B and sends a peering open frame to initiate
peering. STA B, having not yet received a beacon from A and thus
created the corresponding station entry, will ignore all such open
frames. If the beacon interval is sufficiently long then peering
will not succeed as a result.
In fact B can simply create the station entry when the popen is
received, as is done in Linux's in-kernel MPM, avoiding the issue.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Previously, we would only free the station entry if a peering close
frame was received (freeing the station entry causes the kernel to
start sending peer candidate events again when suitable beacons are
received, triggering peering or authentication to restart).
The end result is the same in any case regardless of close reason:
if we leave holding state then peering has started again, so go
ahead and remove the station in all cases.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
The plink_state exists both wpa_supplicant and kernel. Synchronize them
with wpa_mesh_set_plink_state().
Signed-off-by: Kenzoh Nishikawa <Kenzoh.Nishikawa@jp.sony.com>
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
There is a possible race condition between receiving the
NEW_PEER_CANDIDATE event and the Authentication frame from the peer.
Previously, if the Authentication frame RX event was indicated first,
that frame got dropped silently. Now, this frame is still dropped, but a
copy of it is stored and the frame gets processed on the following
NEW_PEER_CANDIDATE event if that is received for the same peer within
two seconds.
Signed-off-by: Jouni Malinen <j@w1.fi>
It is possible that these location ended up getting called before mesh
startup operations had been completed and that could result in
dereferencing NULL pointers. Address those error cases by verifying that
the needed parameters are available before using them.
Signed-off-by: Jouni Malinen <j@w1.fi>
