aboutsummaryrefslogtreecommitdiffstats
path: root/src/p2p
Commit message (Collapse)AuthorAgeFilesLines
* P2P: Validate SSID element length before copying itJouni Malinen2015-10-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | This fixes a possible memcpy overflow for P2P dev->oper_ssid in p2p_add_device(). The length provided by the peer device (0..255 bytes) was used without proper bounds checking and that could have resulted in arbitrary data of up to 223 bytes being written beyond the end of the dev->oper_ssid[] array (of which about 150 bytes would be beyond the heap allocation) when processing a corrupted management frame for P2P peer discovery purposes. This could result in corrupted state in heap, unexpected program behavior due to corrupted P2P peer device information, denial of service due to process crash, exposure of memory contents during GO Negotiation, and potentially arbitrary code execution. Thanks to Google security team for reporting this issue and smart hardware research group of Alibaba security team for discovering it. Change-Id: I9f350f20cdd010f2c096514b245b4a901ad74e46 Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
* WFD: Add support for sending Wi-Fi Display service discovery requestsJouni Malinen2012-12-143-0/+59
| | | | | | | | | | | | | | | | | wpa_cli p2p_serv_disc_req command can now be used to request WSD request to be sent to specified or all peers who support WSD. format: wifi-display <list of roles> <list of subelements> examples: p2p_serv_disc_req 00:00:00:00:00:00 wifi-display [source] 2,3,4,5 p2p_serv_disc_req 02:01:02:03:04:05 wifi-display [pri-sink] 3 p2p_serv_disc_req 00:00:00:00:00:00 wifi-display [sec-source] 2 p2p_serv_disc_req 00:00:00:00:00:00 wifi-display [source+sink] 2,3,4,5 p2p_serv_disc_req 00:00:00:00:00:00 wifi-display [source][pri-sink] 2,3,4,5 Change-Id: I14f8a92aa9a2161d7db97f5670d2dfe3b63ef1e3 Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
* WFD: Add Wi-Fi Display supportJouni Malinen2012-12-148-22/+619
| | | | | | | | | | | | | | | | | | | | This commit adds control interface commands and internal storage of Wi-Fi Display related configuration. In addition, WFD IE is now added to various P2P frames, Probe Request/Response, and (Re)Association Request/Response frames. WFD subelements from peers are stored in the P2P peer table. Following control interface commands are now available: SET wifi_display <0/1> GET wifi_display WFD_SUBELEM_SET <subelem> [hexdump of length+body] WFD_SUBELEM_GET <subelem> Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> [vishalm@ti.com: Backported it to curent tree] Signed-off-by: Vishal Mahaveer <vishalm@ti.com> Change-Id: Ief0cd61903facd9209927d9dc84c8f093f3b6bac
* P2P: Fix broken rx action frame handling (INTERNAL-SQUASH)Eyal Shapira2012-11-132-1/+5
| | | | | | | | | | | | | | | | | | | | | | Commit "P2P: Fix duplicate handling of rx action frames" went too far and dropped any rx action frames arriving on the GO interface. It assumed that any action frames were duplicated and received on both GO interface and P2P device interface. This is wrong as some actions frames like P2P presence request are sent to the GO interface address and won't be duplicated. The root cause of the duplication lies within the Rx path in mac80211 in Johannes` patch "mac80211: accept public action frames with mismatched BSSID". When wpa_s works with a separate group interface this creates a duplicated Rx on both the P2P dev interface and the GO interface. Fix the issue by canceling the duplication in wpa_s and discarding public action frames with unmatching bssid arriving on a dedicated GO interface (This should be squashed with "P2P: Fix duplicate handling of rx action frames") Signed-off-by: Eyal Shapira <eyal@wizery.com>
* P2P: cancel action frame offchan wait after recv go neg resp (UPSTREAM)Eyal Shapira2012-11-021-1/+1
| | | | | | | | | | | A wait of 200ms is configured after sending the go neg request. The go neg process can end quickly within less than 200ms. If this wait isn't canceled it can cause the beaconing of the GO to start while mac80211 is still off channel on the listen channel and this may cause beaconing on the wrong channel if oper channel is different from the listen channel. Signed-off-by: Eyal Shapira <eyal@wizery.com>
* Revert "Add P2P IEs to probe requests only when in P2P (UPSTREAM)"Eyal Shapira2012-10-292-18/+0
| | | | | | | | | | | This is replaced by a recent patch by Jouni in the upstream: "P2P: Allow P2P functionality to be disabled per interface" This reverts commit a56f6df6f8e5dcd650893e8beb4a16a633c179d1. Conflicts: src/p2p/p2p.c
* P2P: cancel action frame offchan wait after recv go neg confEyal Shapira2012-10-241-0/+1
| | | | | | | | | | | The missing call to scan_action_done keeps us offchan on the listen channel for 250ms following sending go neg resp. In case the oper channel is different from the listen channel and we're GO a race could lead to start beaconing while offchan. This causes the beacons to go out on the listen channel instead of the oper channel. Signed-off-by: Eyal Shapira <eyal@wizery.com>
* P2P: fix oper channel selection (SQUASH)Arik Nemtsov2012-09-241-1/+2
| | | | | | | | | | | | Handles the forgotten p2p_process_go_neg_resp() case of patch: commit 66b8140a08b9f6297cd49a3428ada713bf668300 Author: Arik Nemtsov <arik@wizery.com> Date: Thu Aug 30 21:06:45 2012 +0300 P2P: always re-select oper channel if not hard coded Signed-off-by: Arik Nemtsov <arik@wizery.com>
* P2P: prefer operating channels where HT40 is possibleArik Nemtsov2012-09-041-0/+15
| | | | | | | | When no other user preference is specified, opt to use an operating channel that allows HT40 operation. This way, if driver capabilities and regulatory constraints allow, we might enjoy increased bandwidth. Signed-hostap: Arik Nemtsov <arik@wizery.com>
* P2P: always re-select oper channel if not hard codedArik Nemtsov2012-09-041-1/+16
| | | | | | | | | | | Since the operating channel is randomly set to 1/6/11 on init, which is always in the channel intersection, we were effectively ignoring the set of p2p preferred channels. Fix this by trying to get the best channel we can, unless the user hard coded the operating channel in the configuration file. Fall back to the initial randomly selected channel if a better one cannot be chosen. Signed-hostap: Arik Nemtsov <arik@wizery.com>
* P2P: Use larger GO config timeout if HT40 is usedJouni Malinen2012-09-045-3/+29
| | | | | | | Increase GO config timeout if HT40 is used since it takes some time to scan channels for coex purposes before the BSS can be started. Signed-hostap: Jouni Malinen <j@w1.fi>
* P2P: Enable 40 MHz support for autonomous P2P group additionRajkumar Manoharan2012-09-041-0/+2
| | | | | | | | Add optional "ht40" argument for p2p_group_add command to enable 40 MHz in 5GHz band. This configures the secondary channel, when HT support is enabled and if the HW supports 40 MHz channel width. Signed-hostap: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
* Add P2P IEs to probe requests only when in P2P (UPSTREAM)Eyal Shapira2012-08-132-0/+17
| | | | | | | | | | | | The current code caused P2P and consquently WPS IEs to be added to any probe as the check was for non null global->p2p. global->p2p gets set whenever P2P is initialized globally and that occurs on the first interface init. Fix this by indicating wps is in use only when in active P2P discovery or connection establishement. (i.e. not P2P_IDLE - either doing search, neg or provisioning) Signed-off-by: Eyal Shapira <eyal@wizery.com>
* P2P: Increase GO Negotiation timeoutsJouni Malinen2012-08-122-3/+3
| | | | | | | | | | | | | | | | | | | | | | p2p_set_timeout() calls in GO Neg Req/Resp TX callbacks used timeout of 100 ms which is the value given in the P2P specification for GO Negotiation, but this was actually shorter than the wait-for-offchannel-TX value (200 ms) used for the driver call. In addition, it looks like some devices (e.g., Galaxy Nexus with JB image) can take longer time to reply to GO Negotiation Response (somewhere between 200 and 250 ms has been observed). Increase the wait-for-GO-Neg-Resp timeout from 100 ms to 200 ms if GO Negotiation Request frame was acknowledged (this matches with the offchannel wait timeout that used previously). The no-ack case is left at 100 ms since we use GO Negotiation Request frame also to discover whether the peer is on its Listen channel. Increase the wait-for-GO-Neg-Conf timeout from 100 ms to 250 ms (and increase the offchannel wait timeout to matching 250 ms) as a workaround for devices that take over 200 ms to reply to GO Negotiation Response. Signed-hostap: Jouni Malinen <j@w1.fi>
* P2P: Avoid peer expiration while connection in progress (BRCM)Eyal Shapira2012-08-021-1/+34
| | | | | | | | (This seems to be a bug fix squashed in one of the BRCM patches. Could be that the probability of this occuring once the expiration time was reduced to 30s is higher) Signed-off-by: Eyal Shapira <eyal@wizery.com>
* P2P: Improve scan results handling (BRCM)Eyal Shapira2012-08-022-0/+25
| | | | | | | | | | | Avoid reporting scan results to the application in case a P2P search is in progress as there will be many events but the scan is only done on channels 1,6,11. This may cause APs on other channels to "disappear" from the scan results. Also avoid updating P2P interfaces with STA interfaces scan results in order to avoid having results which are not on the social channels. Signed-off-by: Eyal Shapira <eyal@wizery.com>
* P2P: Start blocked p2p find even if scan was on another interface (BRCM)Eyal Shapira2012-08-021-0/+12
| | | | | | | | | | | | | | p2p find can now defer starting the p2p scan due to an ongoing scan on a different interface. Relying on p2p_cb_on_scan_complete which is a per interface flag is wrong here and we won't resume the p2p find in case the scan wasn't on the same interface (which is the case in Android JB). Fix this by relying on the global p2p state instead. (This description is based on analysis of the code as the original BRCM commit doesn't contain any useful information) Signed-off-by: Eyal Shapira <eyal@wizery.com>
* P2P: Decrease peer expiry time (BRCM)Eyal Shapira2012-08-021-0/+4
| | | | | | | Changed from 5 min to 30 secs probably in order to avoid stale peers appearing in the Android UI. Signed-off-by: Eyal Shapira <eyal@wizery.com>
* Fix p2p service discoveryIrfan Sheriff2012-08-023-3/+100
| | | | | | | - Fix listen timing to improve SD reliability - Fix SD packet scheduling Signed-off-by: Eyal Shapira <eyal@wizery.com>
* Revert "P2P: Assume GO Negotiation failed if GO Neg Conf wait times out"Eyal Shapira2012-08-021-8/+0
| | | | | | | Galaxy Nexus takes time to send the GO Neg Confirm (~200ms) and this commit caused the GO Neg to fail because of this. This reverts commit 579a80982ad07619373876c09cdd60e2afcba5b5.
* P2P: update scan resultsEliad Peller2012-08-021-2/+13
| | | | | | | | | (not sure this should go upstream) update p2p scan results (and notify) if the listen_freq or go_state were changed. Signed-off-by: Eliad Peller <eliad@wizery.com>
* p2p: consider age for the p2p scan resultsYoni Divinsky2012-07-305-10/+34
| | | | | | | | | | | | | | | | | Cfg80211 caches the scan results according the channel number. Due to the 15 sec aging this might cause the user mode to see more than one scan result with the same BSSID, e.g. - one scan result for the p2p-device and one for the p2p-GO (once it's enabled). Fix this by updating the device entry only if the new peer entry is newer than the one previously stored. Signed-off-by: Yoni Divinsky <yoni.divinsky@ti.com> Signed-off-by: Victor Goldenshtein <victorg@ti.com> Signed-off-by: Igal Chernobelsky <igalc@ti.com>
* P2P: ignore neg_req with previously used dialog_tokenEliad Peller2012-07-301-0/+8
| | | | | | | | | | | | If for some reason we get a duplicate negotiation request, the supplicant will generate 2 different responses (different SSIDs) with the same dialog token. The remote peer will confirm one of them, but it will probably be the wrong one (the first it received). Workaround it by ignoring negotiation requests with the last used dialog_token. Signed-off-by: Eliad Peller <eliad@wizery.com>
* P2P: use GO channel for Operating Channel IEEliad Peller2012-07-303-3/+3
| | | | | | | [ To be upstreamed - Arik ] Change-Id: I5285126515b47cd3b4cdce717310835f23a78f0a Signed-off-by: Eliad Peller <eliad@wizery.com>
* P2P: Fix provision discovery retries during p2p_findJouni Malinen2012-07-232-5/+11
| | | | | | | | | | | | Commit 6b56cc2d97fe9efd1feea8d418714b4658b056f1 added retries of provision discovery request frames in IDLE state. However, it did not make the p2p_find case behave consistently with the new limitied retry behavior. This can result in way too many and frequent PD retries. Fix this by extending the previous commit to address PD retries and maximum retry limit consistently regardless of whether p2p_find is running. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> intended-for: hostap-1
* P2P: Check memory allocation result in a Service Discovery ResponseMasashi Honma2012-07-021-1/+6
| | | | | | | This patch adds a check of the return value of wpabuf_dup() in a large Service Discovery Response. Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
* P2P: Remove unused P2P_SCAN_SPECIFICJouni Malinen2012-06-301-3/+1
| | | | | | | This is not used anymore after the commit e6ecfc4fd3856309b2e1b9e0d23a8635752666e2. Signed-hostap: Jouni Malinen <j@w1.fi>
* P2P: Remove GO neg/invite special cases from searchJohannes Berg2012-06-301-37/+2
| | | | | | | | | | | | There are separate states for these, so we can't really get into this situation unless somebody tries to do multiple things at the same time. p2p_connect stops find and CONNECT state is used to probe the peer on its Listen channel with GO Negotiation Request frames. Similarly, p2p_invite() stops find and INVITE state is used to probe the peer on its Listen channel with Invitation Request frames. The older mechanism of using Search state functionality to find the peer can be removed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* P2P: Add p2p_client_list support for FullMAC Persistent GOMasashi Honma2012-06-172-12/+26
| | | | | | | | | Currently, FullMAC Persistent GO can't use p2p_client_list because its own hapd->p2p_group is NULL at ap_sta_set_authorized(). This patch changes the processing to use sta->p2p_ie instead of p2p_group_get_dev_addr() on FullMAC GO. Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
* P2P: Fix P2P Client Discoverability bit updatesJouni Malinen2012-06-161-6/+24
| | | | | | | | | | | | | | | | | | | | | The P2P Client Discoverability bit is reserved in most frames and its value in the local P2P peer table should only be updated based on P2P Group Info attribute from a GO. Fix this by avoiding changes to this dev_capab bit based on other P2P frames. It would be more correct to track this separately for each group in which the peer is a member, but since we do not do that for the other group specific information either, this can do for now. It should be noted that prior to commit 18485b5469c5eeea6a552264fbfaabb089a0a557 wpa_supplicant set this bit in all P2P frames. However, that commit changed this to match the specification, i.e., the bit is not set in frames which are received from P2P Device role. As such, this fix is needed to be able to figure out that a peer supports client discoverability capability after that commit. Signed-hostap: Jouni Malinen <j@w1.fi> intended-for: hostap-1
* P2P: Fix setting of P2P Client Discoverability bitMasashi Honma2012-06-163-6/+15
| | | | | | | | | | | | | In the P2P specification v1.1, the P2P Client Discoverability bit is described in Table 12 "Device Capability Bitmap definition". The table says "Within a P2P Group Info attribute and a (Re)association request frame the P2P Client Discoverability field shall be set to 1 when the P2P Device supports P2P Client Discoverability, and is set to 0 otherwise. This field shall be reserved and set to 0 in all other frames or uses.". To match with this, filter out P2P Client Discoverability bit from frames where its use is reserved. Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
* P2P: Ignore unexpected GO Neg Resp is we have sent RespJouni Malinen2012-06-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | There is a race condition in GO Negotiation Request frame sending and processing that may end up with both devices sending GO Negotiation Response. This response frame was previously accepted even if a response had already been sent. This could result in two GO Negotiation Confirm frames being exchanged and consequently, with two separate GO Negotiations completing concurrently. These negotiations could result in getting mismatching parameters (e.g., both device could believe it was the GO). Fix this by ignoring GO Negotiation Response from the peer if twe have already sent a GO Negotiation Response frame and we have the higher P2P Device Address. This is similar to the rule used to determine whether to reply to GO Negotiation Request frame when Request was already sent, i.e., the same direction of GO Negotiation is maintained here to enforce that only the negotiation initiated by the device with smaller P2P Device Address is completed. Signed-hostap: Jouni Malinen <j@w1.fi> intended-for: hostap-1
* P2P: Address race condition with GO Negotiation Request TX statusNeeraj Kumar Garg2012-06-092-2/+5
| | | | | | | | | | | | | | | | If both peers initiate GO Negotiation at about the same time, it is possible for the GO Negotiation Request frame from the peer to be received between the local attempt to send the GO Negotiation Request and TX status event for that. This could result in both devices sending GO Negotiation Response frames even though one of them should have skipped this based which device uses a higher MAC address. Resolve this race by incrementing go_neg_req_sent when p2p_send_action() returns success instead of doing this from the TX status callback. If the frame is not acknowledged, go_neg_req_sent is cleared in TX status handler. Signed-off-by: Neeraj Garg <neerajkg@broadcom.com>
* P2P: Assume GO Negotiation failed if GO Neg Conf wait times outJouni Malinen2012-06-081-0/+8
| | | | | | | | | | Stop the connection attempt if GO Negotiation Confirm is not received within 100 ms of the GO Negotiation Response getting acknowledged. Previously, we would have continued trying to connect to the peer even in this case which could result in confusing second GO Negotiation Request frame and unnecessarily long wait before indicating failure. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* P2P: Send GO Negotiation Confirm without waitJohannes Berg2012-06-061-1/+1
| | | | | | | The GO Negotiation Confirm frame doesn't need to be sent with a wait since we don't expect a response to it. Signed-hostap: Johannes Berg <johannes.berg@intel.com>
* P2P: Use consistent Device Capability in Beacon/Probe ResponseMasashi Honma2012-06-061-3/+2
| | | | | | | | | Concurrent Operation bit was not set for GO even if the device supports concurrent operations. Make sure the Device Capability value is consistent with other P2P use cases by using the value determined in p2p_init(). Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
* P2P: Add option for Provision Discovery before GO NegotiationJouni Malinen2012-05-115-4/+40
| | | | | | | | | | This is a workaround for interoperability issues with some deployed P2P implementations that require a Provision Discovery exchange to be used before GO Negotiation. The new provdisc parameter for the p2p_connect command can be used to request this behavior without having to run a separate p2p_prov_disc command. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* P2P: Reject PD Request for unknown groupJouni Malinen2012-05-081-0/+15
| | | | | | | | If PD Request includes P2P Group ID, verify that the specified group matches with a group we are currently operating. If no match is found, reject the PD Request for join-a-group case. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* P2P: Store SSID of the group in p2p_group dataJouni Malinen2012-05-083-0/+24
| | | | | | | | This can be used with P2P management operations that need to verify whether the local device is operating a specific group based on P2P Group ID attribute from a peer. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* P2P: Do not use prov_disc_resp() callback for rejected PDJouni Malinen2012-05-081-1/+3
| | | | | | | | | | | | Commit 349b213cc8babdc0212938714104f7e28d34b335 added a separate callback prov_disc_fail() for indicating PD failures, but it left the Provision Discovery Response handler to call both callbacks in case the peer rejected the PD. Commit f65a239ba4760cc6e8a169d21a4fcabed444a90b added ctrl_iface event for PD failures. This combination can result in two ctrl_iface events in the peer rejecting a PD case. Clean this up by only indicating the failure event. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* P2P: Wait 100 ms if driver fails to start listen operationJouni Malinen2012-05-081-0/+12
| | | | | | | | | | | | | | | | | | | | Some drivers may accept the remain-on-channel command, but instead of indicating start event for remain-on-channel, just indicate that the operation has been canceled immediately. This could result in continuous loop of search/listen states with very limited time to do anything else in wpa_supplicant if the scan command is also completed quickly (e.g., if the driver is unable to scan other channels than the current operating channel). As a workaround, do not start the next step (search) in P2P device discovery if this type of rejection of listen operation is detected. This gives some more time for wpa_supplicant to handle whatever else may be needed at to be done at the same time and reduces the amount of CPU used in a loop that does not really work correctly from the view point of being discoverable. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> intended-for: hostap-1
* P2P: Fix Device ID matching for Probe Request framesWei-Jen Lin2012-05-021-1/+1
| | | | | | | | | | The misplaced parenthesis caused Device ID matching to check only the first octet of the P2P Device Address, i.e., we could have replied to Probe Request frames that was searching for another device if any of the last five octets of the address were different. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> intended-for: hostap-1
* P2P: Add option to force SSID/passphrase for GO NegotiationJouni Malinen2012-04-272-5/+32
| | | | | | | | | | | | | An existing persistent group information can now be used to force GO Negotiation to use the previously used SSID/passphrase from a persistent group if we become a GO. This can be used as an alternative to inviting a new P2P peer to join the group (i.e., use GO Negotiation with GO intent 15 instead of starting an autonomous GO and using invitation), e.g., in case a GO Negotiation Request is received from a peer while we are not running as a GO. The persistent group to use for parameters is indicated with persistent=<network id> parameter to p2p_connect. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* P2P: Do not update peer Listen channel based on PD/InvitationJouni Malinen2012-04-264-12/+19
| | | | | | | | | | | | | | | | | | Commits 17bef1e97a5061a8b5443dc24166e28439911f0b and ffe98dfb88a19b66418184955ef272789e3abb68 started using p2p_add_device() with other frames than just Probe Response frames from scan results. However, these changes did not take into account that the PD Request and Invitation Request frames are normally received on the our own Listen channel, not on the Listen channel of the peer. As such, these frames must not be used to update Listen channel information for the peer. Fix this by letting p2p_add_device() know whether the results are from scan results and if not, skip the peer table updates that are specific to Probe Response frames. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> intended-for: hostap-1
* P2P: Fix disallowing of pending listen command to override connectJouni Malinen2012-04-161-1/+1
| | | | | | | | | | | | Commit d9bdba9f867577ed9da6df9c5c933033c71bcdf2 was supposed to allow p2p_listen to schedule new after scan operation only if a p2p_connect operation was not pending. However, it used incorrect P2P_AFTER_SCAN_ value for this and did not actually prevent overriding of p2p_connect and could have caused some p2p_listen operations to be skipped unnecessarily. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> intended-for: hostap-1
* P2P: Clear P2P_DEV_SD_INFO when new wildcard SD query is addedJouni Malinen2012-04-111-0/+6
| | | | | | | | Unlike the unicast SD queries, the queries directed to all peers depend on P2P_DEV_SD_INFO flag being cleared to allow the query to be sent to a peer that has previously replied to any SD query. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* DBus: Add ability to report probe requestsJohannes Berg2012-04-012-26/+51
| | | | | | | | | | | | | | | | Some applications require knowing about probe requests to identify devices. This can be the case in AP mode to see the devices before they connect, or even in P2P mode when operating as a P2P device to identify non-P2P peers (P2P peers are identified via PeerFound signals). As there are typically a lot of probe requests, require that an interested application subscribes to this signal so the bus isn't always flooded with these notifications. The notifications in DBus are then unicast only to that application. A small test script is also included. Signed-hostap: Johannes Berg <johannes.berg@intel.com>
* P2P: Use P2P Device ID attribute if Device Info not availableJouni Malinen2012-03-301-5/+8
| | | | | | | | | | | The "BSS p2p_dev_addr=address" command uses p2p_parse_dev_addr() to figure out the P2P Device Address of the GO from scan results. This used to work only if the P2P IE was received from Probe Response frames since only those include the P2P Device Info attribute. Make this work with Beacon frames, too, by using P2P Device ID attribute if the P2P Device Info attribute is not present. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* P2P: Add support for preferred channel listJouni Malinen2012-03-293-0/+74
| | | | | | | | | | | | | | | | | | | | | | p2p_pref_chan configuration parameter can now be used to set the list of preferred channel for P2P GO Negotiation. This will be used in the priority order if the peer does not support the channel we are trying to use as the GO (configured operating channel or the best 2.4 GHz/5 GHz channel) for the case where a forced channel is not used. p2p_pref_chan=<op class:channel>,... For example: p2p_pref_chan=81:1,81:2,81:3,81:4,81:5,81:6 This would configure 2.4 GHz channels 1-6 as the preferred ones with channel 1 the most preferred option. These configuration parameters can be set in wpa_supplicant.conf and dynamically updated with "wpa_cli set <param> <value>". Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
* P2P: Fix provisioning info clearing after successful WPS stepJouni Malinen2012-03-012-5/+5
| | | | | | | | | | | | Previously, this provisioning info was cleared using the P2P Interface Address of the GO as the key. That did not always work in the case the where we joined an already running group. This could result in the next connection to that same GO skipping provision discovery. Fix this by finding the peer entry based on its P2P Device Address instead of the P2P Interface Address which may not always be set. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> intended-for: hostap-1
generated by cgit v1.1 at 2024-05-06 06:53:03 +0000