android_external_wpa_supplicant_8/src/p2p, branch cm-13.0

P2P: Continue p2p_find after sending non-success Invitation Response

2016-07-01T11:18:08+00:00

This was previously handled for the case where the non-success
Invitation Response frame was sent out during the Listen phase. However,
in the case the Action frame TX ended up getting scheduled when the
Search phase scan had already started (e.g., due to the driver reporting
Invitation Request RX late enough for the Listen-to-Search transition
having already started), the postponed Action frame TX status processing
did not cover the specific case of non-success Invitation Response. This
could result in the p2p_find operation getting stopped (stuck in SEARCH
state) unexpectedly

Fix this by calling p2p_check_after_scan_tx_continuation() from
Invitation Response TX callback handler if the invitation was rejected.

CRs-Fixed: 1002261
Git-commit: 3433721c5f9073c0d45c1109b825f1dcbabbf517
Git-repo : git://w1.fi/srv/git/hostap.git
Signed-off-by: Jouni Malinen 

Change-Id: Ic045516f31520fbe8ba068c88fe247df1746f29a

P2P: Adjust service discovery maximum fragment size for 60 GHz

2016-04-14T22:49:30+00:00

In the 60 GHz band, service discovery management frames are sent over
the control PHY and have a smaller maximum frame size (IEEE Std
802.11ad-2012, 21.4.3.2). Fix the code to use sufficiently small
fragment size when operating in the 60 GHz band.

The 60 GHz fragment size (928) is derived from the maximum frame size
for control PHY (1023) and subtracting 48 bytes of header size, and some
spare so we do not reach frames with the absolute maximum size.

Change-Id: I80ccbdc1a8a66e921a2da28f8ddb9487064f7dc0
Signed-off-by: Lior David 
Git-commit: e4a1469cecee8d21044fb6e97f85aa807f498b62
Git-repo: git://w1.fi/srv/git/hostap.git
CRs-Fixed: 985990

P2P: Add Dev Info attribute to Probe Request frames in 60 GHz

2016-04-14T22:48:50+00:00

When building P2P IE for Probe Request frames in P2P scan, add the
device information attribute if the 60 GHz band is included in the scan,
since this is required by the P2P specification.

Change-Id: Ib4439786cc1297859234e0b0661e7c1b5576c896
Signed-off-by: Lior David 
Git-commit: c58eed6dc72f3169154d94cd258cdcbdcd24913a
Git-repo: git://w1.fi/srv/git/hostap.git
CRs-Fixed: 985990

P2P: Add support for VHT 80+80 MHz and 160 MHz

2016-04-01T11:23:06+00:00

The new max_oper_chwidth and freq2 arguments to P2P_CONNECT, P2P_INVITE,
and P2P_GROUP_ADD control interface commands can be used to request
larger VHT operating channel bandwidth to be used than the previously
used maximum 80 MHz.

Signed-off-by: Jouni Malinen 
Git-commit: c27f4c9006ccfdadffe9455ea887502e8ba989eb
Git-repo : git://w1.fi/srv/git/hostap.git
Change-Id: Ie7020e68f3442f2d20493488fde3f6f043de7fde
CRs-Fixed: 944221

P2P: Define operating classes for VHT 80+80 and 160

2016-04-01T11:22:19+00:00

This adds definitions for the global operating classes 129 and 130 for
VHT 80+80 MHz and 160 MHz use cases.

Signed-off-by: Jouni Malinen 
Git-commit: 5e1da9c8fdcadb0171d5448fa09960f976804155
Git-repo : git://w1.fi/srv/git/hostap.git
Change-Id: Ifb4dfec7e7f6fa4dac125260c488195562e2c170
CRs-Fixed: 944221

P2P: Do not reply to GO Negotiation Request if peer is waiting for us

2016-04-01T11:21:45+00:00

This improves robustness of GO Negotiation in special cases where GO
Negotiation Request frames from the peer may end up getting delivered
multiple times, e.g., due to interference and retransmitted frames not
getting properly filtered out in duplicate detection (which is something
that number of drivers do not implement for pre-associated state).

If we have already replied with GO Negotiation Response frame with
Status 1 (not yet ready), do not reply to another GO Negotiation Request
frame from the peer if we have already received authorization from the
user (P2P_CONNECT command) for group formation and have sent out our GO
Negotiation Request frame. This avoids a possible sequence where two
independent GO Negotiation instances could go through in parallel if the
MAC address based rule on avoiding duplicate negotiations is not able to
prevent the case. This can allow GO Negotiation to complete successfully
whereas the previous behavior would have likely resulted in a failure
with neither device sending a GO Negotiation Confirm frame.

Signed-off-by: Jouni Malinen 
Git-commit: 2b12b3602aa5ee60fbbaf723e508321eb86ee10f
Git-repo: git://w1.fi/srv/git/hostap.git
Change-Id: Ifb8cf34c7e58ce8fd5aef57b3d2e3b8fb1e733de
CRs-fixed: 924507

P2P: Support driver preferred freq list for invitation case

2016-04-01T11:18:57+00:00

When using P2P invitation to re-invoke a persistent P2P group without
specifying the operating channel, query the driver for the preferred
frequency list, and use it to select the operating channel of the group.

Signed-off-by: Jouni Malinen 
Git-commit: fbcddaed9aa62587e7b74cd22df4b4cdaca6b101
Git-repo: git://w1.fi/srv/git/hostap.git
Change-Id: I2fcf33980771e57e11539ee580cf4fe783b6719f
CRs-fixed: 887890

P2P: Process preferred frequency list as part of GO Neg Req/Resp

2016-04-01T11:17:41+00:00

When processing a GO Negotiation Request and Response, if local driver
supports the preferred channel list extension, then:

- Check if peer's preference for operating channel is already included
  in our preferred channel list and if so, take the oper_channel as is.

- If peer's preference for operating channel is not in local device's
  preferred channel list and peer device has provided its preferred
  frequency list in the GO Negotiation Request/Response, then find a
  channel that is common for both preferred channel lists and use it
  for oper_channel.

- If peer's preference for operating channel is not in local device's
  preferred channel list and peer device doesn't use preferred channel
  list extension, i.e., no preferred channel list in GO Negotiation
  Request/Response, then look for a channel that is common for local
  device's preferred channel list and peer's list of supported channels
  and use it for oper_channel.

- In case no common channel is found, use the peer's preference for
  oper_channel as is.

Signed-off-by: Jouni Malinen 
Git-commit: 6cc364946cd30681cd1e3a2ca061173be3227d11
Git-repo: git://w1.fi/srv/git/hostap.git
Change-Id: I2ba4cddfd03c741ee82ecbefe64617080e720d3e
CRs-fixed: 887890

P2P: Expose driver preferred frequency list fetch to P2P

2016-04-01T11:16:52+00:00

This adds a callback function that can be used from the P2P module to
request the current preferred list of operating channels from the
driver.

Signed-off-by: Jouni Malinen 
Git-commit: fc71f7d99db620097296720af1d46b1b94afb0f8
Git-repo: git://w1.fi/srv/git/hostap.git
Change-Id: I8135b44c91bdaa89fe80a3e4f802dadfbe557662
CRs-fixed: 842468

P2P: Do not omit known operating channel preference from GO Neg Resp

2016-04-01T11:16:29+00:00

Add an extra condition to omit operating channel preference when
building GO Negotiation Response. If the local device supports the
preferred frequency list extension, then when sending a GO Negotiation
Response frame, advertise the preferred operating channel unless local
device is assuming the P2P Client role and has an empty preferred
frequency list, in which case local device can omit its preference for
the operating channel.

This change helps make use of the preferred frequency list and the
calculated best channel for both negotiating parties of the P2P
connection.

Signed-off-by: Jouni Malinen 
Git-commit: 0ef54bd30e3d6d66fe060098c45c61dfaf87e00e
Git-repo: git://w1.fi/srv/git/hostap.git
Change-Id: I2192ac1fcac9253876fae3f54f10f5a89d0e3bac
CRs-fixed: 842468