All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
To: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"Peer, Ilan" <ilan.peer@intel.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"Rodriguez, Luis" <rodrigue@qca.qualcomm.com>,
	"John W . Linville" <linville@tuxdriver.com>
Subject: Re: [PATCH v8] cfg80211: P2P find phase offload
Date: Wed, 5 Jun 2013 10:10:50 +0300	[thread overview]
Message-ID: <2109265.XIVW7kjjZK@lx-vladimir> (raw)
In-Reply-To: <20130604183023.GB6172@jouni.qca.qualcomm.com>

On Tuesday, June 04, 2013 09:30:23 PM Jouni Malinen wrote:
> On Tue, Jun 04, 2013 at 07:47:20PM +0300, Vladimir Kondratiev wrote:
> > I am a bit confused. I supposed that if devices A and B (not in a group yet)
> > try to discover each other, it works like the following
> > 
> > A ---- probe-req  ---> B (now B knows A)
> > A <--- probe-resp ---- B (now A knows B)
> 
> This depends on what exactly you mean with "discover". Sure, it is known
> that there is a P2P peer in the environment if a Probe Request frame
> with P2P IE is received from it. However, that does not necessarily mean
> we know enough of that peer to initiate new P2P operations.
> 
> > But if device is discovered by probe-resp only, it mean this should be
> > 
> > A ---- probe-req  ---> B
> > A <--- probe-resp ---- B (now A knows B)
> > A <--- probe-req  ---- B
> > A ---- probe-resp ---> B (now B knows A)
> 
> Probe Response frames include more information about the peer and that
> allows wpa_supplicant to complete the peer entry. This is the point when
> the peer is fully known and indicated to upper layers. The Probe Request
> frame RX case is just used internally within wpa_supplicant. (For
> completeness, number of other frames, i.e., P2P Action frames, can also
> complete the P2P peer entry, so this does not need to be Probe
> Response).

Thanks for clarification. So, I see that wpa_s wants all probe responses and
may want either all or selected probes, depending on the driver's capability
(NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD) and its own reasons.

Then, I think it would be appropriate to say following in the comment for
start_p2p_find (no code changes, it is only expectations for the friver behavior):

---cut---
While performing P2P discovery, driver should report all received
probe-request and probe-response frames via cfg80211_rx_mgmt,
accordingly to the rx mgmt filter, as set by mgmt_frame_register().
When reporting probes, driver/firmware may do its best to filter out
probes that would not be replied with probe-resp accordingly to the
P2P rules for active device configuration.
---cut---

This makes possible for wpa_s to choose exact configuration, and good
power saving is possible provided firmware answer probes.

Comments?

Thanks, Vladimir

  reply	other threads:[~2013-06-05  7:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04  6:44 [PATCH v8] P2P find phase offload Vladimir Kondratiev
2013-06-04  6:44 ` [PATCH v8] cfg80211: " Vladimir Kondratiev
2013-06-04 10:07   ` Peer, Ilan
2013-06-04 11:24     ` Vladimir Kondratiev
2013-06-04 12:07       ` Johannes Berg
2013-06-04 14:03         ` Vladimir Kondratiev
2013-06-04 14:29           ` Johannes Berg
2013-06-04 14:35             ` Malinen, Jouni
2013-06-04 16:47               ` Vladimir Kondratiev
2013-06-04 18:30                 ` Jouni Malinen
2013-06-05  7:10                   ` Vladimir Kondratiev [this message]
2013-06-05  7:53                     ` Johannes Berg
2013-06-05 13:30                       ` Vladimir Kondratiev
2013-06-11 12:12                         ` Johannes Berg
2013-06-05  7:46               ` Johannes Berg
2013-06-05  8:10                 ` Arend van Spriel
2013-06-05  8:18                   ` Johannes Berg
2013-06-05  8:38                     ` Arend van Spriel
2013-06-05 16:26                       ` Vladimir Kondratiev
2013-06-05  8:12                 ` Jouni Malinen
2013-06-04 12:10       ` Peer, Ilan
2013-06-04 10:43   ` Johannes Berg
2013-06-04  6:51 ` [PATCH v8] " Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2109265.XIVW7kjjZK@lx-vladimir \
    --to=qca_vkondrat@qca.qualcomm.com \
    --cc=ilan.peer@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=jouni@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=rodrigue@qca.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.