diff mbox

P2P: Fix for multi channel concurrency

Message ID 20130912124930.GA29850@sreenath-Precision-M4700
State Superseded
Headers show

Commit Message

Sreenath Sept. 12, 2013, 12:49 p.m. UTC 
In case of GO-NEGOTIATION, the connected STA channel is set as the forced
frequency even though the device is multi channel concurrent capable.
This will cause only that channel getting added in the channel list of
GO-NEGOTIATION request packet. So if both the peers try to force their
receptive STA channels and if both are different, there will be
failure - "no common channel" (7).

Ideally in case of multi channel concurrency, the connected STA channel
should not be set as forced channel and should only be set as preferred
channel. This will cause full channel list getting updated in the
GO-NEGOTIATION request packet, so that there can be channel intersection
if the peer's proposed channel is different.

This is a regression from commit 0d08efa447a5c5fb20bbed18a2ced36a8afe9221.

Signed-hostap: Sreenath Sharma <sreenats@broadcom.com>
---
 wpa_supplicant/p2p_supplicant.c |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

Comments

eMyListsDDg Sept. 13, 2013, 4:02 a.m. UTC | #1 
have a couple of questions please:


1) i have these lines in my hostapd.conf and want to know which is more secure:

   wpa_pairwise=TKIP or wpa_pairwise=CCMP ?

i'm also using:

    rsn_pairwise=CCMP


i'm not fully understanding which group cipher gets used when i have wpa_pairwise set to TKIP and rsn_pairwise set to CCMP.
trying to batten down my configs as best i can. this is home network but i want it as secure as i can.



2) also, is it more secure to use a "wpa_passphrase= " entry or putting a passphrase in a "wpa_psk_file= " file ?

that is to say "wpa_passphrase=" versus "wpa_psk_file= " as in which is more secure?




note: i emailed this to this group on 9.9 but i don't see it so i repost

thanks
Jouni Malinen Nov. 22, 2013, 3:58 p.m. UTC | #2 
On Thu, Sep 12, 2013 at 06:19:30PM +0530, Sreenath Sharma wrote:
> In case of GO-NEGOTIATION, the connected STA channel is set as the forced
> frequency even though the device is multi channel concurrent capable.
> This will cause only that channel getting added in the channel list of
> GO-NEGOTIATION request packet. So if both the peers try to force their
> receptive STA channels and if both are different, there will be
> failure - "no common channel" (7).
> 
> Ideally in case of multi channel concurrency, the connected STA channel
> should not be set as forced channel and should only be set as preferred
> channel. This will cause full channel list getting updated in the
> GO-NEGOTIATION request packet, so that there can be channel intersection
> if the peer's proposed channel is different.
> 
> This is a regression from commit 0d08efa447a5c5fb20bbed18a2ced36a8afe9221.

Sorry, I somehow missed this in the queue and just noticed it now that I
went through some fixes in AOSP. The changes here look fine in general,
but the debug prints were a bit off. I fixed this in equivalent way
functionality, but with the debug messages modified to make more sense.
diff mbox

Patch

diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c
index 9338ad5..c6b3c8e 100644
--- a/wpa_supplicant/p2p_supplicant.c
+++ b/wpa_supplicant/p2p_supplicant.c
@@ -3964,14 +3964,14 @@  static int wpas_p2p_setup_freqs(struct wpa_supplicant *wpa_s, int freq,
 		if (!p2p_supported_freq(wpa_s->global->p2p, freqs[i]))
 			continue;
 
-		wpa_printf(MSG_DEBUG, "P2P: Try to force us to use frequency (%u MHz) which is already in use",
-			   *force_freq);
-		*force_freq = freqs[i];
-
-		if (*pref_freq == 0 && num < wpa_s->num_multichan_concurrent) {
-			wpa_printf(MSG_DEBUG, "P2P: Try to prefer a frequency we are already using");
-			*pref_freq = *force_freq;
-		}
+		if (num < wpa_s->num_multichan_concurrent) {
+ 			wpa_printf(MSG_DEBUG, "P2P: Try to prefer a frequency we are already using");
+			*pref_freq = freqs[i];
+		} else {
+			wpa_printf(MSG_DEBUG, "P2P: Try to force us to use frequency (%u MHz) which is already in use",
+				   *force_freq);
+			*force_freq = freqs[i];
+ 		}
 		break;
 	}