This is mainly for testing purposes to allow multiple FETCH_OSU ANQP
operations to be ran without having to wait for full scan between each
query.
Signed-off-by: Jouni Malinen <j@w1.fi>
When a station starts an association to a Hotspot 2.0 network, request
the driver to do the following, based on the BSS capabilities:
1. Enable gratuitous ARP filtering
2. Enable unsolicited Neighbor Advertisement filtering
3. Enable unicast IP packet encrypted with GTK filtering if
DGAF disabled bit is zero
Clear the filter configuration when the station interface is
disassociated.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
This adds a new command based Hotspot 2.0 icon retrieval option.
In short, here is the new command sequence:
1. REQ_HS20_ICON <bssid> <file-name>
2. event: RX-HS20-ICON <bssid> <file-name> <size>
3. GET_HS20_ICON <bssid> <file-name> <offset> <size>
(if needed, repeat with larger offset values until full icon is
fetched)
5. DEL_HS20_ICON <bssid> <file-name>
REQ_HS20_ICON is a new command that is analogous to HS20_ICON_REQUEST
with the slight difference that an entry to store the icon in memory is
prepared. The RX-HS20-ICON event has been augmented with BSSID,
file-name and size, and GET_HS20_ICON is used to retrieve a chunk of up
to <size> bytes of icon data at offset <offset>. Each chunk is returned
as a base64 encoded fragment, preceded by "HS20-ICON-DATA", BSSID, and
file-name as well as the starting offset of the data.
If there is no entry prepared for the icon when the ANQP result comes
back, hs20_process_icon_binary_file falls back to legacy behavior.
Finally the DEL_HS20_ICON command deletes (all) icons associated with
BSSID and file-name (there could be several if retries are used and they
have different dialog tokens).
Signed-off-by: Jan Nordqvist <jannq@google.com>
Commit 17b8995cf5 ('Interworking: Try to
use same BSS entry for storing GAS results') added a mechanism to try to
pair GAS request and response to a single BSS entry to cover cases where
multiple BSS entries may exists for the same BSSID. However, that commit
did not cover the Hotspot 2.0 ANQP elements. Extend this mechanism to
all ANQP elements. This can help in cases where information in the
Hotspot 2.0 specific ANQP elements got lost if a hidden SSID or some
other reason of duplicated BSS entries was present while doing ANQP
fetches.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows a single ANQP query to be used to fetch both IEEE 802.11
defined ANQP elements and Hotspot 2.0 vendor specific elements.
ANQP_GET <addr> <info id>[,<info id>]...
[,hs20:<subtype>][...,hs20:<subtype>]
For example:
ANQP_GET 00:11:22:33:44:55:66 258,268,hs20:3,hs20:4
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Scan operation is not that reliable, so try couple of times if no
OSU provider matches are found during fetch_osu command.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The new wpa_cli fetch_osu command can be used to fetch information about
all OSU providers and write that to a text file with the icons in
separate files. cancel_osu_fetch command can be used to stop ongoing OSU
provider list fetch.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Subscription remediation notification WNM-Notification Request is now
shown in the following way in wpa_supplicant control interface:
<3>HS20-SUBSCRIPTION-REMEDIATION http://example.com/foo/
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The HS 2.0 Indication element from wpa_supplicant now includes the
release number field and wpa_supplicant shows the release number of the
AP in STATUS command (hs20=1 replaced with hs20=<release>).
The new update_identifier field in the cred block can now be used to
configure the PPS MO ID so that wpa_supplicant adds it to the Indication
element in Association Request frames.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The Hotspot 2.0 specification seems to mandate this element to be
included in all (Re)Association Request frames if the station is Hotspot
2.0 capable. However, that results in conflicts with other requirements
like no TKIP use when this element is present. The design is really
supposed to include the indication element only for Hotspot 2.0
associations regardless of what the current specification implies.
Remove the HS 2.0 Indication element from (Re)Association Request frame
whenever the connection is not for Hotspot 2.0 purposes.
Signed-hostap: Jouni Malinen <j@w1.fi>
