This was done with spatch using the following semantic patch and minor
manual edits to clean up coding style and avoid compiler warnings in
driver_wext.c:
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !os_memcmp(a, b, ETH_ALEN)
+ ether_addr_equal(a, b)
Signed-off-by: Jouni Malinen <j@w1.fi>
This variable is not specific to any P2P group interface and since it
was already used through global->p2p_init_wpa_s, it is cleaner to simply
move this to the global structure so that there is a single variable
instead of per-interface variables and need to pick the correct
interface.
Signed-off-by: Jouni Malinen <j@w1.fi>
There could be multiple pending TX operations and if the earlier ones
have used wait_time, but the last one did not, the driver call for
canceling pending wait was not done. This could result in the driver
getting stuck waiting for the previously scheduled wait time and not
being able to do new operations until that. Fix this by canceling the
wait if any of the past offchannel_send_action() calls since the last
offchannel_send_action_done() used non-zero wait_time.
This was showing up as issues in certain DPP Public Action frame
sequences when the same offchannel operation is used with multiple
frames and the last frame in the sequence does not need wait_time.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The P2P Device interface can only send Public Action frames. Non-Public
Action frames must be sent over a group interface. The previous
implementation sometimes tried to send non-Public Action frames such as
GO Discoverability over the P2P Device interface, however, the source
address of the frame was set to the group interface address so the code
in offchannel.c knew to select the correct interface for the TX.
The check breaks when the P2P Device and group interfaces have the same
MAC address. In this case the frame will be sent over the P2P Device
interface and the send will fail.
Fix this problem in two places:
1. In offchannel, route non-Public Action frames to the GO
interface when the above conditions are met.
2. When a TX_STATUS event arrives on such routed frame, it will
arrive on the GO interface but it must be handled by the P2P Device
interface since it has the relevant state logic.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
This makes it easier to analyze debug logs for issues related to
multiple pending Action TX frames.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for a Action frame sequence completion to stop an
ongoing offchannel remain-on-channel operation unexpectedly in cases
where TX operation was offloaded to the driver and such an operation
happened to occur during a previously started remain-on-channel (e.g.,
for P2P listen state).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
On receiving the cancel remain on channel event, the pending_tx
is scheduled immediately and returned. This was preventing
the wpas_p2p_listen_start function from execution thereby resulting
in termination of the long listen operation.
Signed-off-by: Jithu Jance <jithu@broadcom.com>
Both the wpa_s->pending_action_src and src argument to
wpas_get_tx_interface() were used somewhat randomly. Make this more
consistent since these values are pointing to the same address and the
implementation is easier to understand when it is obvious that there is
only one address being used.
Signed-off-by: Jouni Malinen <j@w1.fi>
The extra_roc_dur parameter can now be used in CONFIG_TESTING_OPTIONS=y
builds to simulate driver behavior where the ROC duration gets increased
without user space request.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the offchannel TX frame command was offloaded to the driver in
offchannel_send_action(), we must not send another copy of the frame if
a remain-on-channel event happens to be delivered between this TX
command and the matching TX status event. It was possible for the
duplicated frame to cause problems, e.g., with P2P invitation exchange
if the same Invitation Request frame got sent twice and only the first
one getting accepted by the peer.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It is possible for there to be two pending off-channel TX frames, e.g.,
when two devices initiate GO Negotiation at more or less the same time.
This could result in the TX status report for the first frame clearing
wpa_s->pending_action_tx that included the newer frame that has not yet
been transmitted (i.e., is waiting to be sent out). Avoid losing that
frame by confirming that the TX status payload matches the pending frame
before clearing the pending frame and reporting the TX status callback.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
cfg80211 does not allow the zero duration of remain-on-channel. Instead,
use 20 ms as default waiting time when remain-on-channel is used to
schedule offchannel transmission that does not expect a response.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
There is no need for p2p_supplicant.c to access wpa_s->pending_action_tx
so move these references to offchannel.c to get a bit cleaner interface
between the components.
Signed-hostap: Jouni Malinen <j@w1.fi>
Remove the GPL notification text from files that were initially
contributed by Atheros Communications or Qualcomm Atheros.
Signed-hostap: Jouni Malinen <j@w1.fi>
This can be used to apply the no-CCK rule conditionally depending on
which frame is being sent. The no-CCK rule applies only for P2P
management frames while SA Query and FT use cases do not have similar
restrictions.
Signed-hostap: Jouni Malinen <j@w1.fi>
