Do not use a random MAC address for the GAS exchange that is used as
part of the DPP protocol exchange since that would break DPP.
Configurator expects the same MAC address to be used for DPP
Authentication exchange and DPP Configuration exchange (GAS).
Since the DPP Authentication exchange has already used the MAC address
configured on the interface, use of a random address for the GAS
exchange would not provide any additional privacy protection. If a
random MAC address needs to be used for this type of an exchange, that
random address would need to be first configured on the interface before
starting DPP exchange.
This does not change GAS query behavior for any other use case, i.e.,
the gas_rand_mac_addr configuration continues to apply to all the
Interworking/Hotspot 2.0 uses.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous implementation did not check that we are associated with
the sender of the GAS response before checking for PMF status. This
could have accepted Venue URL when not in associated state. Fix this by
explicitly checking for association with the responder first.
This fixes an issue that was detected, e.g., with these hwsim test case
sequences:
gas_anqp_venue_url_pmf gas_anqp_venue_url
gas_prot_vs_not_prot gas_anqp_venue_url
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Force use of the wildcard BSSID address in GAS query frames with DPP
regardless of how the gas_address3 configuration parameter is set. DPP
specification mandates this and the use of GAS here is really outside
the context of a BSS, so using the wildcard BSSID makes sense even for
the corner case of Configurator running on a known AP (where IEEE 802.11
standard would allow the BSSID of the AP to be used).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If a DPP_STOP_LISTEN call happens to be received when there is a pending
gas-query radio work that has not yet been started, it was possible for
gas_query_stop() to go through gas_query_done() processing with
gas->work == NULL and that ended up with the pending GAS query getting
freed without removing the pending radio work that hold a reference to
the now freed memory. Fix this by removing the pending non-started radio
work for the GAS query in this specific corner case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Previously, only the success and failure (to TX) cases were handled. It
is also possible for the driver to transmit the frame, but not receive
an ACK from the recipient. Address that by waiting for a short period of
time for a response. This fixes cases where OSU provider icon fetching
could get stuck if no ACK frame is received.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add support to send GAS requests with a randomized transmitter address
if supported by the driver. The following control interface commands
(and matching configuration file parameters) can be used to configure
different types of randomization:
"SET gas_rand_mac_addr 0" to disable randomizing TX MAC address,
"SET gas_rand_mac_addr 1" to randomize the complete TX MAC address,
"SET gas_rand_mac_addr 2" to randomize the TX MAC address except for OUI.
A new random MAC address will be generated for every
gas_rand_addr_lifetime seconds and this can be configured with
"SET gas_rand_addr_lifetime <timeout>".
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
When AP responds with comeback delay for initial GAS query sent by STA,
gas_query_timeout should be cancelled to avoid GAS failures when
comeback delay is more than GAS_QUERY_TIMEOUT_PERIOD. The
gas_query_timeout is getting registered again when tx_status is received
for GAS comeback request.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If radio_add_work() fails, gas_query_req() ended up freeing the query
payload and returning an error. This resulted in also the caller trying
to free the query payload. Fix this by not freeing the buffer within
gas_query_req() in error case to be consistent with the other error
cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
This function was added with the initial GAS implementation, but there
was no user for it at the time and no clear use now either, so remove
the unused function and the related GAS query reason code.
Signed-off-by: Jouni Malinen <j@w1.fi>
Apply the GAS specific rule of using Protected Dual of Public Action
frame only after having checked that the action code indicates this to
be a GAS response. Previously, non-GAS Public Action frames could have
been incorrectly dropped because of this check if received during an
association with PMF enabled.
Signed-off-by: Jouni Malinen <j@w1.fi>
The GAS-QUERY-DONE event with result=INTERNAL_ERROR was reported on most
other error cases, but the failure triggered by not being able to
transmit a GAS Initial Request stopped the query silently. Make this
more consistent with other error cases by reporting the same event.
Signed-off-by: Jouni Malinen <j@w1.fi>
IEEE Std 802.11-2012, 10.19 (Public Action frame addressing) specifies
that the wildcard BSSID value is used in Public Action frames that are
transmitted to a STA that is not a member of the same BSS.
wpa_supplicant used to use the actual BSSID value for all such frames
regardless of whether the destination STA is a member of the BSS.
P2P does not follow this rule, so P2P Public Action frame construction
must not be changed. However, the cases using GAS/ANQP for non-P2P
purposes should follow the standard requirements.
Unfortunately, there are deployed AP implementations that do not reply
to a GAS request sent using the wildcard BSSID value. The previously
used behavior (Address3 = AP BSSID even when not associated) continues
to be the default, but the IEEE 802.11 standard compliant addressing
behavior can now be configured with gas_address3=1.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Use the SA field instead of BSSID in the received Action frame to
determine whether PMF has been negotiated with the transmitter. While
these fields are supposed to be same for Public Action frames from an
AP, it would be possible that a frame is received with different values.
The following operations in gas_query_rx() use SA, so do the same for
the PMF check.
Signed-off-by: Jouni Malinen <j@w1.fi>
The minimum comeback delay 1 is used to indicate that fragmentation is
needed instead of indicating that the response is going to be available
only after some time. Do not cancel offchannel wait for this case
between the initial and comeback exchanges to avoid delaying the full
operation unnecessarily.
Signed-off-by: Jouni Malinen <j@w1.fi>
It is possible for a comeback response to get lost especially when going
through a large GAS exchange fragmented to multiple frames in an
environment with interference or other traffic. Make this less likely to
fail the full exchange by trying full GAS query again and using longer
wait time on the GAS comeback exchanges.
Signed-off-by: Jouni Malinen <j@w1.fi>
When exchanging GAS frames with the AP, the initial response from the AP
may take a while to come, since the AP may need to fetch the info from a
server. The next fragments/comeback response frames should take much
less time since the AP already has all of the info, so the wait time
for these frames can be reduced.
In addition, some drivers, e.g., mac80211, try to combine ROC based flows,
to improve medium utilization. For example, if the requested ROC fits
entirely in a previous requested ROC they can be combined. Thus, reducing
the wait time for the next frames can improve medium utilization.
Shorten the duration of GAS comeback to improve medium utilization and
overall GAS exchange times.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Commit 2c0d0ae370 ('GAS: End
remain-on-channel due to delayed GAS comeback request') started ending
the remain-on-channel operation between the initial request and the
following comeback request. However, it did not check or update the
offchannel_tx_started variable. While this alone would not necessarily
be problematic, this makes it more difficult to optimize wait time for
offchannel TX operations, so make sure the internal tracking variable
gets updated.
Signed-off-by: Jouni Malinen <j@w1.fi>
During the sequence of exchanging GAS frames with the AP, the AP can
request to come back in X amount of time and resend the GAS request.
Previously, wpa_supplicant did not terminate the remain-on-channel
session, but rather waited until the requested comeback delay had
expired, and then tried to send the GAS frame (potentially to save the
time that is required to schedule a new remain on channel flow).
This might cause unnecessary idle time (can be close to 1000 ms) in
which the device might be off-channel. Ending the current
remain-on-channel session and then rescheduling makes better usage of
the time in this case.
End remain-on-channel session due to receiving a delayed GAS comeback
request from the AP.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
This adds experimental support for wpa_supplicant to assign random local
MAC addresses for both pre-association cases (scan, GAS/ANQP) and for
connections. MAC address policy for each part can be controlled
separately and the connection part can be set per network block.
This requires support from the driver to allow local MAC address to be
changed if random address policy is enabled. It should also be noted
that number of drivers would not support concurrent operations (e.g.,
P2P and station association) with random addresses in use for one or
both.
This functionality can be controlled with the global configuration
parameters mac_addr and preassoc_mac_addr which set the default MAC
address policies for connections and pre-association operations (scan
and GAS/ANQP while not connected). The global rand_addr_lifetime
parameter can be used to set the lifetime of a random MAC address in
seconds (default: 60 seconds). This is used to avoid unnecessarily
frequent MAC address changes since those are likely to result in driver
clearing most of its state. It should be noted that the random MAC
address does not expire during an ESS connection, i.e., this lifetime is
only for the case where the device is disconnected.
The mac_addr parameter can also be set in the network blocks to define
different behavior per network. For example, the global mac_addr=1 and
preassoc_mac_addr=1 settings and mac_addr=0 in a home network profile
would result in behavior where all scanning is performed using a random
MAC address while connections to new networks (e.g.,
Interworking/Hotspot 2.0) would use random address and connections to
the home network would use the permanent MAC address.
Signed-off-by: Jouni Malinen <j@w1.fi>
The GAS query TX operation used a fixed wait time of 1000 ms for the
reply. However, it would be possible for the driver to not support this
long remain-on-channel maximum. Limit this wait time based on driver
support, if needed.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The special case of non-zero status code used in a GAS Comeback Response
frame to indicate that additional delay is needed before the response is
available was not working properly. This case needs to allow the status
code check to be bypassed for the comeback case prior to having received
any response data.
Signed-off-by: Jouni Malinen <j@w1.fi>
While testing rfkill blocking of a scanning interface, it
was seen that the ongoing scan never completes. This happens
since EVENT_SCAN_RESULTS is discarded on a disabled interface.
Fix this and also other possible radio work completion issues
by removing all the radio works (including started) of the
disabled interface.
To be able to remove already started radio works, make their
callbacks be reentrant with deinit flag (when the work
is started), so each radio work should be able to handle
its own termination.
Signed-hostap: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
When GAS is used with PMF negotiated, Protected Dual of Public Action
frames are expected to be used instead of Public Action frames, i.e.,
the GAS/ANQP frames are expected to be encrypted. Conver Public Action
GAS queries to use Dual of Public Action frame if PMF has been
negotiated with the AP to which the frame is being sent.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This type of protection against concurrent connection and offchannel GAS
operations is now enforced through the wpa_radio work mechanism, so this
separate protection mechanism is not needed anymore.
Signed-hostap: Jouni Malinen <j@w1.fi>
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.
