Avoid concurrent GAS operations with any other exclusive use of the
radio by using the radio work queuing mechanism. This replaces some of
the earlier constraints on concurrent operations with the more generic
wpa_radio work concept.
Signed-hostap: Jouni Malinen <j@w1.fi>
Need to use the pointer to the current ongoing query instead of matching
from the pending list based on the destination address so that we get
the correct query instance when processing the TX status report.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
These operations can have conflicting offchannel requirements, so wait
with a new scan trigger until a pending GAS query has been completed.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Offchannel operations needed for a GAS query can conflict with ongoing
scan/connection progress, so delay GAS queries if such an operation is
in progress on the current interface or any virtual interface sharing
the same radio.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It would be possible to issue another GAS query when a previous one is
still in progress and this could result in conflicting offchannel
operations. Prevent that by delaying GAS query initiation until the
previous operation has been completed.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This allow GAS operations to be fine-tuned based what happens with GAS
query TX. Failed queries are timed out immediately and acknowledged
queries are given some more time to account for possible TX queue
latencies.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The five second timeout for GAS queries is excessive and can result in
long waits in cases where APs are either misconfigured or frames are
lost.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This makes the design more robust against unexpected duplicates since
each new GAS exchange gets a different dialog token compared to the
previous one.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It looks like it may be possible for an older GAS response to get retransmitted
even after the first copy has been processed. While this should not really come
up all the way to wpa_supplicant due to sequence number being same (i.e.,
duplicate detection should from the frame), some cases have been observed where
this did cause issues. Drop such a frame silently without dropping the ongoing
GAS session to allow a frame with the next frag_id to be processed after this.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The pending GAS entry must be removed from the list when it is removed.
This fixes an issue with potential segfault due to freed memory being
accessed if the driver fails to accept a GAS query.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
GAS_QUERY_TIMEOUT value was used for two different things - enum for
status callback and #define for internal eloop timeout). The latter
overwrites the former and as such, the timeout reported ended up going
out with value 5 which matches with GAS_QUERY_CANCELLED instead of
GAS_QUERY_TIMEOUT. This value was not used in existing code, so this
should not modify the current behavior. Anyway, the correct reason for
the failure should be reported. Rename the internal #define for the
timeout period to avoid the name conflict. [Bug 463]
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>
This implements GAS request mechanism that is aimed at being used to
replace use case specific GAS/ANQP implementations in the future.
Compared to the earlier implementation in P2P SD, this implementation
includes support for multiple concurrent requests and more thorough
validation of frames against the pending query data.
GAS header processing, including comeback and reassembly, are handled
within gas_query.c and the users of this module will only need to
provide the Query Request and process the (possibly reassembled)
Query Response.
