From Matt.Caron  Fri Oct  1 05:28:00 2010
From: Matt.Caron (Matthew Caron)
Date: Fri, 01 Oct 2010 08:28:00 -0400
Subject: Possible EAP bugs
Message-ID: <4CA5D3D0.4030907@sixnet.com>

Hello list,

I'm a bit new to hostapd/EAP/802.1X/etc. to please bear with me. I'm 
asking the list because I'm not certain if these are *actually* bugs or 
of I'm wrong. If these are bug, I'm happy to add them, and I have patches.

Most of what I'm speaking about here is in eap_server.c.

This is in a passthrough configuration (authenticator using a separate 
RADIUS server)

(1) I believe that the identity is not being correctly cleared.

Firstly, if you successfully authenticate, but then reject the 
certificate, then attempt to reauthenticate, you go into the INITIALIZE 
state, sm->currentId is set to -1 (NONE), but sm->identity is left 
alone. When getDecision then fires, it leads to a bad decision in a 
PASSTHROUGH case, where it should CONTINUE (send an identity request 
packet, etc.) rather than just drop to INITIALIZE_PASSTHROUGH. If it 
goes to INITIALIZE_PASSTHROUGH, since currentId is NONE (because that 
WAS cleared in INITIALIZE), it then goes to AAA_IDLE, but will never get 
a response from the AAA sever, because it never saw a packet.

Secondly, if you fail authentication, the same thing happens. You try to 
reauthenticate, hit INITIALIZE, sm->currentId is cleared but 
sm->identity is left alone, and so you never ask for credentials.

Proposed fix: Clear sm->identity along with sm->currentId in INITIALIZE

(2) Given the above, you can never get out of AAA_IDLE, because 
aaaTimeout is never set.

I presume this is a "to be implemented", correct? As in, we need to add 
a configuration parameter for timeout values talking to the AAA server, 
etc.?

-- 
Matthew Caron
Build Engineer
Sixnet | www.sixnet.com
O +1 518 877 5173 Ext. 138
F +1 518 602 9209
matt.caron at sixnet.com


From andreas.fenkart  Fri Oct  1 06:04:11 2010
From: andreas.fenkart (Andreas Fenkart)
Date: Fri, 1 Oct 2010 15:04:11 +0200
Subject: QNX / libpcap / wpa_supplicant -- packet loss
Message-ID: <20101001130411.GA20952@biggy>

Hi

I observed a problem, when bpf queues 3 packages for
wpa_supplicant.  Only the first package is received, then
wpa_supplicant blocks in select without reading the other 2
packages.

The is what I debugged so far:

   wpa_supplicant                 io-pkt
------------------------------------------------------
select:
  -      -      -      -    |  -> bpf_poll
 <-      -      -      -    |  -  <data available
 -> pcap_next       "       |
    -> pcap_dispatch        |
       -> pcap_read_bpf     |
           -    -      -    |  -> bpf_read
          <-    -      -    |  -  <pass all queued data>

      --> libpcap extracts 1 packet queues remaining data <--

    <- 1 packet
 <- 1 packet
..
  process packet
..
do select:
 -      -      -      -     |  -> bpf_poll
 <-      -      -      -    |  -  <no data available
repeat


The problem is that the data is queued in pcap, but the
supplicant not checking this before calling 'select' again. Select
will fail, since it checks for available data in io-pkt which in
my case receives no more data.

Any suggestions, hints and existing patches very welcome.

kind regards

Andreas


---- configuration --------------------------------------------

QNX 6.4.1 / wpa_supplicant 0.6.4 / libpcap 0.9.8

network={
        ssid="MotorolaWPA-EAP"
        scan_ssid=1
        # IEEE 802.1X (i.e., no WPA) with dynamic WEP keys
        key_mgmt=IEEE8021X
        eap=TTLS
        identity="xxxx"
        password="xxxx"
        priority=1
}



From pstew  Fri Oct  1 11:13:21 2010
From: pstew (Paul Stewart)
Date: Fri, 1 Oct 2010 11:13:21 -0700
Subject: [PATCH 0/4] Add more signal quality information in bgscan CQM
Message-ID: <AANLkTikjPZZd=bHLMdaz-gDnMTV43SYtru7Fbp3j9Bd1@mail.gmail.com>

This series has the following patches:


  drivers: update driver.h to add signal quality elements to
signal_change structure
  driver_nl80211: Add new survey retrieval function to nl80211 driver,
and add txrate to station
  events: Add new channel condition parameters to bgscan signal change
event handling
  bgscan: Update all bgscan modules to accept new txrate and noise parameters

It updates nl80211 to pass up more information about the channel's
condition to wpa_supplicant, which in turns passes this information
down to the background scan modules.  Modules can potentially get a
richer feel for the channel condition and make better choices about
scan/no-scan and roam/no-roam.


 src/drivers/driver.h           |    3 +
 src/drivers/driver_nl80211.c   |  116 +++++++++++++++++++++++++++++++++++++---
 wpa_supplicant/bgscan.c        |    7 ++-
 wpa_supplicant/bgscan.h        |   11 +++-
 wpa_supplicant/bgscan_learn.c  |    8 ++-
 wpa_supplicant/bgscan_simple.c |    4 +-
 wpa_supplicant/events.c        |    4 +-
 7 files changed, 137 insertions(+), 16 deletions(-)


From pstew  Fri Oct  1 10:26:42 2010
From: pstew (Paul Stewart)
Date: Fri, 1 Oct 2010 10:26:42 -0700
Subject: [PATCH 1/4] drivers: update driver.h to add signal quality elements
	to signal_change structure
Message-ID: <20101001182023.83015203B2@glenhelen.mtv.corp.google.com>

From: Paul Stewart <pstew at google.com>

Signed-off-by: Paul Stewart <pstew at google.com>
---
 src/drivers/driver.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/drivers/driver.h b/src/drivers/driver.h
index 169f54e..7d57fd2 100644
--- a/src/drivers/driver.h
+++ b/src/drivers/driver.h
@@ -2435,8 +2435,11 @@ union wpa_event_data {
 	 * struct signal_change - Data for EVENT_SIGNAL_CHANGE events
 	 */
 	struct signal_change {
+		u32 frequency;
 		int above_threshold;
 		int current_signal;
+		int current_noise;
+		int current_txrate;
 	} signal_change;
 };
 
-- 
1.7.1



From pstew  Fri Oct  1 10:29:39 2010
From: pstew (Paul Stewart)
Date: Fri, 1 Oct 2010 10:29:39 -0700
Subject: [PATCH 2/4] driver_nl80211: Add new survey retrieval function to
	nl80211 driver, and add txrate to station
Message-ID: <20101001182032.22703203B2@glenhelen.mtv.corp.google.com>

From: Paul Stewart <pstew at google.com>

Signed-off-by: Paul Stewart <pstew at google.com>
---
 src/drivers/driver_nl80211.c |  116 +++++++++++++++++++++++++++++++++++++++---
 1 files changed, 109 insertions(+), 7 deletions(-)

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index c5a3078..6be8cc9 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -938,7 +938,14 @@ static int get_link_signal(struct nl_msg *msg, void *arg)
 	static struct nla_policy policy[NL80211_STA_INFO_MAX + 1] = {
 		[NL80211_STA_INFO_SIGNAL] = { .type = NLA_U8 },
 	};
-	int *sig = arg;
+	struct nlattr *rinfo[NL80211_RATE_INFO_MAX + 1];
+	static struct nla_policy rate_policy[NL80211_RATE_INFO_MAX + 1] = {
+		[NL80211_RATE_INFO_BITRATE] = { .type = NLA_U16 },
+		[NL80211_RATE_INFO_MCS] = { .type = NLA_U8 },
+		[NL80211_RATE_INFO_40_MHZ_WIDTH] = { .type = NLA_FLAG },
+		[NL80211_RATE_INFO_SHORT_GI] = { .type = NLA_FLAG },
+	};
+	struct signal_change *sig_change = arg;
 
 	nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
 		  genlmsg_attrlen(gnlh, 0), NULL);
@@ -949,17 +956,34 @@ static int get_link_signal(struct nl_msg *msg, void *arg)
 	if (!sinfo[NL80211_STA_INFO_SIGNAL])
 		return NL_SKIP;
 
-	*sig = (s8) nla_get_u8(sinfo[NL80211_STA_INFO_SIGNAL]);
+	sig_change->current_signal =
+		(s8) nla_get_u8(sinfo[NL80211_STA_INFO_SIGNAL]);
+
+	if (sinfo[NL80211_STA_INFO_TX_BITRATE]) {
+		if (nla_parse_nested(rinfo, NL80211_RATE_INFO_MAX,
+				     sinfo[NL80211_STA_INFO_TX_BITRATE],
+				     rate_policy)) {
+			sig_change->current_txrate = 0;
+		} else {
+			if (rinfo[NL80211_RATE_INFO_BITRATE]) {
+				sig_change->current_txrate =
+					nla_get_u16(rinfo[
+					     NL80211_RATE_INFO_BITRATE]) * 100;
+			}
+		}
+	}
+
 	return NL_SKIP;
 }
 
 
 static int nl80211_get_link_signal(struct wpa_driver_nl80211_data *drv,
-				   int *sig)
+				   struct signal_change *sig)
 {
 	struct nl_msg *msg;
 
-	*sig = -9999;
+	sig->current_signal = -9999;
+	sig->current_txrate = 0;
 
 	msg = nlmsg_alloc();
 	if (!msg)
@@ -977,6 +1001,73 @@ static int nl80211_get_link_signal(struct wpa_driver_nl80211_data *drv,
 }
 
 
+static int get_link_noise(struct nl_msg *msg, void *arg)
+{
+	struct nlattr *tb[NL80211_ATTR_MAX + 1];
+	struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+	struct nlattr *sinfo[NL80211_SURVEY_INFO_MAX + 1];
+	static struct nla_policy survey_policy[NL80211_SURVEY_INFO_MAX + 1] = {
+		[NL80211_SURVEY_INFO_FREQUENCY] = { .type = NLA_U32 },
+		[NL80211_SURVEY_INFO_NOISE] = { .type = NLA_U8 },
+	};
+	struct signal_change *sig_change = arg;
+
+	nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+		  genlmsg_attrlen(gnlh, 0), NULL);
+
+	if (!tb[NL80211_ATTR_SURVEY_INFO]) {
+		wpa_printf(MSG_DEBUG, "nl80211: survey data missing!");
+		return NL_SKIP;
+	}
+
+	if (nla_parse_nested(sinfo, NL80211_SURVEY_INFO_MAX,
+			     tb[NL80211_ATTR_SURVEY_INFO],
+			     survey_policy)) {
+		wpa_printf(MSG_DEBUG, "nl80211: failed to parse nested "
+			   "attributes!");
+		return NL_SKIP;
+	}
+
+	if (!sinfo[NL80211_SURVEY_INFO_FREQUENCY])
+		return NL_SKIP;
+
+	if (nla_get_u32(sinfo[NL80211_SURVEY_INFO_FREQUENCY]) !=
+	    sig_change->frequency)
+		return NL_SKIP;
+
+	if (!sinfo[NL80211_SURVEY_INFO_NOISE])
+		return NL_SKIP;
+
+	sig_change->current_noise =
+		(s8)nla_get_u8(sinfo[NL80211_SURVEY_INFO_NOISE]);
+
+	return NL_SKIP;
+}
+
+
+static int nl80211_get_link_noise(struct wpa_driver_nl80211_data *drv,
+				  struct signal_change *sig_change)
+{
+	struct nl_msg *msg;
+
+	sig_change->current_noise = 9999;
+	sig_change->frequency = drv->assoc_freq;
+
+	msg = nlmsg_alloc();
+	if (!msg)
+		return -ENOMEM;
+
+	genlmsg_put(msg, 0, 0, genl_family_get_id(drv->nl80211), 0,
+		    NLM_F_DUMP, NL80211_CMD_GET_SURVEY, 0);
+
+	NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, drv->ifindex);
+
+	return send_and_recv_msgs(drv, msg, get_link_noise, sig_change);
+ nla_put_failure:
+	return -ENOBUFS;
+}
+
+
 static void nl80211_cqm_event(struct wpa_driver_nl80211_data *drv,
 			      struct nlattr *tb[])
 {
@@ -988,7 +1079,8 @@ static void nl80211_cqm_event(struct wpa_driver_nl80211_data *drv,
 	struct nlattr *cqm[NL80211_ATTR_CQM_MAX + 1];
 	enum nl80211_cqm_rssi_threshold_event event;
 	union wpa_event_data ed;
-	int sig, res;
+	struct signal_change sig;
+	int res;
 
 	if (tb[NL80211_ATTR_CQM] == NULL ||
 	    nla_parse_nested(cqm, NL80211_ATTR_CQM_MAX, tb[NL80211_ATTR_CQM],
@@ -1016,10 +1108,20 @@ static void nl80211_cqm_event(struct wpa_driver_nl80211_data *drv,
 
 	res = nl80211_get_link_signal(drv, &sig);
 	if (res == 0) {
-		ed.signal_change.current_signal = sig;
-		wpa_printf(MSG_DEBUG, "nl80211: Signal: %d dBm", sig);
+		ed.signal_change.current_signal = sig.current_signal;
+		ed.signal_change.current_txrate = sig.current_txrate;
+		wpa_printf(MSG_DEBUG, "nl80211: Signal: %d dBm  txrate: %d",
+			   sig.current_signal, sig.current_txrate);
+	}
+
+	res = nl80211_get_link_noise(drv, &sig);
+	if (res == 0) {
+		ed.signal_change.current_noise = sig.current_noise;
+		wpa_printf(MSG_DEBUG, "nl80211: Noise: %d dBm",
+			   sig.current_noise);
 	}
 
+
 	wpa_supplicant_event(drv->ctx, EVENT_SIGNAL_CHANGE, &ed);
 }
 
-- 
1.7.1



From pstew  Fri Oct  1 10:31:22 2010
From: pstew (Paul Stewart)
Date: Fri, 1 Oct 2010 10:31:22 -0700
Subject: [PATCH 3/4] events: Add new channel condition parameters to bgscan
	signal change event handling
Message-ID: <20101001182038.A74E8203B2@glenhelen.mtv.corp.google.com>

From: Paul Stewart <pstew at google.com>

Signed-off-by: Paul Stewart <pstew at google.com>
---
 wpa_supplicant/events.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
index fb4a48e..717b4d3 100644
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -1723,7 +1723,9 @@ void wpa_supplicant_event(void *ctx, enum wpa_event_type event,
 	case EVENT_SIGNAL_CHANGE:
 		bgscan_notify_signal_change(
 			wpa_s, data->signal_change.above_threshold,
-			data->signal_change.current_signal);
+			data->signal_change.current_signal,
+			data->signal_change.current_noise,
+			data->signal_change.current_txrate);
 		break;
 	default:
 		wpa_printf(MSG_INFO, "Unknown event %d", event);
-- 
1.7.1



From pstew  Fri Oct  1 10:32:39 2010
From: pstew (Paul Stewart)
Date: Fri, 1 Oct 2010 10:32:39 -0700
Subject: [PATCH 4/4] bgscan: Update all bgscan modules to accept new txrate
	and noise parameters
Message-ID: <20101001182044.343AA203B2@glenhelen.mtv.corp.google.com>

From: Paul Stewart <pstew at google.com>

Signed-off-by: Paul Stewart <pstew at google.com>
---
 wpa_supplicant/bgscan.c        |    7 +++++--
 wpa_supplicant/bgscan.h        |   11 ++++++++---
 wpa_supplicant/bgscan_learn.c  |    8 ++++++--
 wpa_supplicant/bgscan_simple.c |    4 +++-
 4 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/wpa_supplicant/bgscan.c b/wpa_supplicant/bgscan.c
index e76e954..5661830 100644
--- a/wpa_supplicant/bgscan.c
+++ b/wpa_supplicant/bgscan.c
@@ -112,9 +112,12 @@ void bgscan_notify_beacon_loss(struct wpa_supplicant *wpa_s)
 
 
 void bgscan_notify_signal_change(struct wpa_supplicant *wpa_s, int above,
-				 int current_signal)
+				 int current_signal, int current_noise,
+				 int current_txrate)
 {
 	if (wpa_s->bgscan && wpa_s->bgscan_priv)
 		wpa_s->bgscan->notify_signal_change(wpa_s->bgscan_priv, above,
-						    current_signal);
+						    current_signal,
+						    current_noise,
+						    current_txrate);
 }
diff --git a/wpa_supplicant/bgscan.h b/wpa_supplicant/bgscan.h
index 9f2ba2f..bcd9115 100644
--- a/wpa_supplicant/bgscan.h
+++ b/wpa_supplicant/bgscan.h
@@ -28,7 +28,9 @@ struct bgscan_ops {
 	int (*notify_scan)(void *priv, struct wpa_scan_results *scan_res);
 	void (*notify_beacon_loss)(void *priv);
 	void (*notify_signal_change)(void *priv, int above,
-				     int current_signal);
+				     int current_signal,
+				     int current_noise,
+				     int current_txrate);
 };
 
 #ifdef CONFIG_BGSCAN
@@ -39,7 +41,8 @@ int bgscan_notify_scan(struct wpa_supplicant *wpa_s,
 		       struct wpa_scan_results *scan_res);
 void bgscan_notify_beacon_loss(struct wpa_supplicant *wpa_s);
 void bgscan_notify_signal_change(struct wpa_supplicant *wpa_s, int above,
-				 int current_signal);
+				 int current_signal, int current_noise,
+				 int current_txrate);
 
 #else /* CONFIG_BGSCAN */
 
@@ -64,7 +67,9 @@ static inline void bgscan_notify_beacon_loss(struct wpa_supplicant *wpa_s)
 }
 
 static inline void bgscan_notify_signal_change(struct wpa_supplicant *wpa_s,
-					       int above, int current_signal)
+					       int above, int current_signal,
+					      int current_noise,
+					      int current_txrate)
 {
 }
 
diff --git a/wpa_supplicant/bgscan_learn.c b/wpa_supplicant/bgscan_learn.c
index 492ce38..ee79511 100644
--- a/wpa_supplicant/bgscan_learn.c
+++ b/wpa_supplicant/bgscan_learn.c
@@ -556,7 +556,9 @@ static void bgscan_learn_notify_beacon_loss(void *priv)
 
 
 static void bgscan_learn_notify_signal_change(void *priv, int above,
-					      int current_signal)
+					      int current_signal,
+					      int current_noise,
+					      int current_txrate)
 {
 	struct bgscan_learn_data *data = priv;
 	int scan = 0;
@@ -567,7 +569,9 @@ static void bgscan_learn_notify_signal_change(void *priv, int above,
 		return;
 
 	wpa_printf(MSG_DEBUG, "bgscan learn: signal level changed "
-		   "(above=%d current_signal=%d)", above, current_signal);
+		   "(above=%d current_signal=%d current_noise=%d "
+		   "current_txrate=%d)", above, current_signal,
+		   current_noise, current_txrate);
 	if (data->scan_interval == data->long_interval && !above) {
 		wpa_printf(MSG_DEBUG, "bgscan learn: Start using short bgscan "
 			   "interval");
diff --git a/wpa_supplicant/bgscan_simple.c b/wpa_supplicant/bgscan_simple.c
index 6325d73..0757d57 100644
--- a/wpa_supplicant/bgscan_simple.c
+++ b/wpa_supplicant/bgscan_simple.c
@@ -177,7 +177,9 @@ static void bgscan_simple_notify_beacon_loss(void *priv)
 
 
 static void bgscan_simple_notify_signal_change(void *priv, int above,
-					       int current_signal)
+					       int current_signal,
+					       int current_noise,
+					       int current_txrate)
 {
 	struct bgscan_simple_data *data = priv;
 	int scan = 0;
-- 
1.7.1



From blaise  Fri Oct  1 11:56:26 2010
From: blaise (Blaise Gassend)
Date: Fri, 1 Oct 2010 11:56:26 -0700
Subject: Patch to split roaming out of wpa_supplicant
Message-ID: <AANLkTinf4Xq9UsmE7CHk1r6iRQJFt4a1cDeYQzT9T69F@mail.gmail.com>

Hi folks,

I have a patch that I would be interested in pushing into
wpa_supplicant. Before I get it into a shape that is useable by
others, I would like to gauge whether it has a chance of being
accepted.

I'm currently working on a wireless seamless roaming solution for my
company's robots (willowgarage.com). My general strategy has been to
use wpa_supplicant to handle talking to the driver, and managing
keys/security, and to split out decisions about scanning and what to
associate to to my own code in python for ease of prototyping.

In order to make this happen, I have had to put my own hooks into
wpa_supplicant, and disable all its automated attempts at scanning and
associating: the current wpa_cli API doesn't give me enough control,
and after spending a while trying to determine if the dbus API had
everything I needed, I decided that it would be quicker to put in my
own hooks.

I now have a patch that is starting to work for me, and am wondering
if it could be valuable to others, and how best to make it available.
If I was to provide a patch that adds a build flag that does the items
below, would it have a chance of making it into the upstream
wpa_supplicant? If there is interest, I will do the cleanup needed to
make this easy to use for others (otherwise, my code that interfaces
with ROS is available at
https://code.ros.org/svn/ros-pkg/stacks/linux_networking/trunk/wpa_supplicant_node).

The patch would include:
- Build a .so and .pc file instead of a binary, that you can then link
with your own code.
- Disable all automatic scanning and association.
- The following hooks (which I would rename to make them ROS
agnostic), which get called at appropriate times during startup,
shutdown, and upon association or scanning events.

int ros_init(int *argc, char ***argv);
void ros_init2();
void ros_deinit();
void ros_add_iface(struct wpa_supplicant *wpa_s);
void ros_remove_iface(struct wpa_supplicant *wpa_s);
void ros_scan_completed(struct wpa_supplicant *wpa_s, struct
wpa_scan_results *scan_res);
void ros_assoc_success(struct wpa_supplicant *wpa_s);
void ros_assoc_failed(struct wpa_supplicant *wpa_s, const u8* bssid,
const char *reason);

Thanks,
Blaise


From dave.taht  Fri Oct  1 15:32:42 2010
From: dave.taht (Dave Taht)
Date: Fri, 1 Oct 2010 15:32:42 -0700
Subject: IFF_RUNNING and hostapd
Message-ID: <AANLkTindhPCGcA8PH7GdSy2zwTvj0oD-tJewqUPvsd8F@mail.gmail.com>

I recently configured an openwrt system (a nanostation M) as a pure
router, not bridge, in AP mode.

Neither babeld (with link detection enabled) and radvd work
(preventing ipv6 from working entirely)

ip addr

for wlan0 shows the interface as UP, but with "NO CARRIER".

In poking through the iproute2 code, it showed that the UP bit being
set on the interface and the IFF_RUNNING bit not being set = "NO
CARRIER".


It doesn't look like the hostapd I'm using sets the IFF_RUNNING bit, ever.

So I ask... at what point, and by what, and where should RUNNING be
setup on a AP mode, purely routed, non-bridged interface?

It seems like a good idea to leave it in the NO CARRIER state until
the first client authenticates.

(If you ask why I was not bridging the ethernet and wireless devices
together, it's because this is a set of long haul IPv6 connections.
STA and adhoc mode work fine unbridged for some reason, as does AP
bridged, which makes sense as the ethernet device is up and configured
elsewhere)

I wrote a test proggie to set IFF_RUNNING on wlan0 manually, outside
of hostapd, it didn't work...

so perhaps the problem exists deeper in the stack than hostapd? I'm
certainly willing to hack deeper into hostapd than I have so far, but
perhaps I'm barking up the wrong tree.


-- 
Dave T?ht
SKYPE: davetaht
Nicaragua Tel: (int) 505-8868-4319
US Tel: 1-239-829-5608


From inaky  Sat Oct  2 00:17:52 2010
From: inaky (Inaky Perez-Gonzalez)
Date: Sat, 02 Oct 2010 00:17:52 -0700
Subject: [RFC/PATCH] eap_peer: create a libeap library, with header files
	and pkg-config [v2]
Message-ID: <1286003872.2932.1.camel@localhost.localdomain>


This adds infrastructure in src/eap_peer to make libeap.so and install
the needed header files and pkg-config files.

Now, this is quite dirty and probably not what we want in the long
term, but serves as an starting point:

 - we don't build from the wpa_supplicant directory because the
   objects the .so have to be built with -fPIC. So if you need to
   build both the binary and the library:

   make -C wpa_supplicant
   make -C src/eap_peer clean
   make -C src/eap_peer

   As I said, it's dirty -- we'd need either wpa_supplicant linking
   against the library properly (but that seems not to be desirable)
   or a multiple object build approach ala automake.

 - need to use 'override CFLAGS' in src/eap_peer/Makefile, otherwise
   any CFLAGS setting will kill the build infrastructure. I miss
   AM_CFLAGS.

 - adds 'eap_register_methods()' that will register every compiled in
   method.

Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez at intel.com>
---
 build_release              |   12 +++
 src/eap_peer/Makefile      |  191 ++++++++++++++++++++++++++++++++++++++++++--
 src/eap_peer/eap_methods.c |  114 ++++++++++++++++++++++++++
 src/eap_peer/eap_methods.h |    1 +
 src/eap_peer/libeap0.pc    |   10 +++
 5 files changed, 320 insertions(+), 8 deletions(-)
 create mode 100644 src/eap_peer/libeap0.pc

diff --git a/build_release b/build_release
index 22dcd42..f84a99c 100755
--- a/build_release
+++ b/build_release
@@ -31,6 +31,18 @@ fi
 mkdir $TMP
 mkdir -p $RELDIR
 
+pc_ver=$(awk '/^Version:/  { print $2; }' src/eap_peer/libeap0.pc)
+if [ $pc_ver != $VER ]
+then
+    cat 1>&2 <<EOF
+WARNING! the version in the command line ($VER) differs from
+    the version declared for the pkg-config file for libeap.so in
+    src/eap_peer ($pc_ver).
+
+    Are you sure? [hit Ctrl-C to cancel]
+EOF
+    read
+fi
 git archive --format=tar --prefix=wpa-$VER/ HEAD \
 	README COPYING patches src wpa_supplicant hostapd |
 	gzip > $RELDIR/wpa-$VER.tar.gz
diff --git a/src/eap_peer/Makefile b/src/eap_peer/Makefile
index 3651056..58c067a 100644
--- a/src/eap_peer/Makefile
+++ b/src/eap_peer/Makefile
@@ -1,11 +1,186 @@
-all:
-	@echo Nothing to be made.
+LIBEAP_NAME = libeap
+LIBEAP_CURRENT = 0
+LIBEAP_REVISION = 0
+LIBEAP_AGE = 0
+
+LIBEAP = $(LIBEAP_NAME).so.$(LIBEAP_CURRENT).$(LIBEAP_REVISION).$(LIBEAP_AGE)
+LIBEAP_SO = $(LIBEAP_NAME).so.$(LIBEAP_CURRENT)
+
+.PHONY: all clean install uninstall
+
+all: $(LIBEAP)
+
+ifndef CC
+CC=gcc
+endif
+
+ifndef CFLAGS
+CFLAGS = -MMD -O0 -Wall -g
+endif
+
+CONFIG_TLS=openssl
+
+INCLUDE_INSTALL_DIR=/usr/include/eap_peer
+
+# Got to use override all across the board, otherwise a 'make
+# CFLAGS=XX' will kill us because the command line's CFLAGS will
+# overwrite Make's and we'll loose all the infrastructure it sets.
+override CFLAGS += -I. -I.. -I../crypto -I../utils -I../common
+
+# at least for now, need to include config_ssid.h and config_blob.h from
+# wpa_supplicant directory
+override CFLAGS += -I ../../wpa_supplicant
+
+OBJS_both += ../utils/common.o
+OBJS_both += ../utils/os_unix.o
+OBJS_both += ../utils/wpa_debug.o
+OBJS_both += ../utils/base64.o
+OBJS_both += ../utils/wpabuf.o
+OBJS_both += ../crypto/md5.o
+OBJS_both += ../crypto/sha1.o
+OBJS_both += ../crypto/sha1-tlsprf.o
+OBJS_both += ../crypto/aes-encblock.o
+OBJS_both += ../crypto/aes-wrap.o
+OBJS_both += ../crypto/aes-ctr.o
+OBJS_both += ../crypto/aes-eax.o
+OBJS_both += ../crypto/aes-omac1.o
+OBJS_both += ../crypto/ms_funcs.o
+OBJS_both += ../crypto/sha256.o
+
+
+OBJS_both += ../eap_common/eap_peap_common.o
+OBJS_both += ../eap_common/eap_psk_common.o
+OBJS_both += ../eap_common/eap_pax_common.o
+OBJS_both += ../eap_common/eap_sake_common.o
+OBJS_both += ../eap_common/eap_gpsk_common.o
+OBJS_both += ../eap_common/chap.o
+
+OBJS_peer += ../eap_peer/eap_tls.o
+OBJS_peer += ../eap_peer/eap_peap.o
+OBJS_peer += ../eap_peer/eap_ttls.o
+OBJS_peer += ../eap_peer/eap_md5.o
+OBJS_peer += ../eap_peer/eap_mschapv2.o
+OBJS_peer += ../eap_peer/mschapv2.o
+OBJS_peer += ../eap_peer/eap_otp.o
+OBJS_peer += ../eap_peer/eap_gtc.o
+OBJS_peer += ../eap_peer/eap_leap.o
+OBJS_peer += ../eap_peer/eap_psk.o
+OBJS_peer += ../eap_peer/eap_pax.o
+OBJS_peer += ../eap_peer/eap_sake.o
+OBJS_peer += ../eap_peer/eap_gpsk.o
+OBJS_peer += ../eap_peer/eap.o
+OBJS_peer += ../eap_common/eap_common.o
+OBJS_peer += ../eap_peer/eap_methods.o
+OBJS_peer += ../eap_peer/eap_tls_common.o
+
+override CFLAGS += -DEAP_TLS
+override CFLAGS += -DEAP_PEAP
+override CFLAGS += -DEAP_TTLS
+override CFLAGS += -DEAP_MD5
+override CFLAGS += -DEAP_MSCHAPv2
+override CFLAGS += -DEAP_GTC
+override CFLAGS += -DEAP_OTP
+override CFLAGS += -DEAP_LEAP
+override CFLAGS += -DEAP_PSK
+override CFLAGS += -DEAP_PAX
+override CFLAGS += -DEAP_SAKE
+override CFLAGS += -DEAP_GPSK -DEAP_GPSK_SHA256
+override CFLAGS += -DEAP_TLS_FUNCS
+
+override CFLAGS += -DIEEE8021X_EAPOL
+
+ifeq ($(CONFIG_TLS), openssl)
+override CFLAGS += -DEAP_TLS_OPENSSL
+OBJS_both += ../crypto/tls_openssl.o
+OBJS_both += ../crypto/crypto_openssl.o
+LIBS += -lssl -lcrypto
+override CFLAGS += -DINTERNAL_SHA256
+endif
+
+ifeq ($(CONFIG_TLS), internal)
+OBJS_both += ../crypto/tls_internal.o
+OBJS_both += ../tls/tlsv1_common.o ../../tls/tlsv1_record.o
+OBJS_both += ../tls/tlsv1_cred.o
+OBJS_both += ../tls/asn1.o ../../tls/x509v3.o
+OBJS_both += ../crypto/crypto_internal.o ../../tls/rsa.o ../../tls/bignum.o
+
+OBJS_peer += ../tls/tlsv1_client.o
+OBJS_peer += ../tls/tlsv1_client_write.o ../../tls/tlsv1_client_read.o
+override CFLAGS += -DCONFIG_TLS_INTERNAL_CLIENT
+
+OBJS_server += ../tls/tlsv1_server.o
+OBJS_server += ../tls/tlsv1_server_write.o ../../tls/tlsv1_server_read.o
+override CFLAGS += -DCONFIG_TLS_INTERNAL_SERVER
+
+override CFLAGS += -DCONFIG_TLS_INTERNAL
+override CFLAGS += -DCONFIG_CRYPTO_INTERNAL
+override CFLAGS += -DCONFIG_INTERNAL_X509
+override CFLAGS += -DINTERNAL_AES
+override CFLAGS += -DINTERNAL_SHA1
+override CFLAGS += -DINTERNAL_SHA256
+override CFLAGS += -DINTERNAL_MD5
+override CFLAGS += -DINTERNAL_MD4
+override CFLAGS += -DINTERNAL_DES
+ifdef CONFIG_INTERNAL_LIBTOMMATH
+override CFLAGS += -DCONFIG_INTERNAL_LIBTOMMATH
+else
+LIBS += -ltommath
+endif
+endif
+
+ifndef LDO
+LDO=$(CC)
+endif
+
+
+OBJS_lib=$(OBJS_both) $(OBJS_peer)
+
+ #$(OBJS_server)
+
+override CFLAGS  += -fPIC -DPIC
+LDFLAGS += -shared
+
+$(LIBEAP): $(OBJS_lib)
+	$(LDO) $(LDFLAGS) $(OBJS_lib) -Wl,-soname -Wl,$(LIBEAP_SO) -o $(LIBEAP) $(LIBS)
+
+
+UTIL_HEADERS = ../utils/includes.h ../utils/common.h \
+	../utils/wpabuf.h ../utils/build_config.h \
+	../utils/os.h ../utils/wpa_debug.h
+COMMON_HEADERS = ../common/defs.h 
+EAP_COMMON_HEADERS = ../eap_common/eap_defs.h 
+MAIN_HEADERS = eap.h eap_methods.h eap_config.h
+CRYPTO_HEADERS =  ../crypto/tls.h  
+
+install: 
+
+	mkdir -p $(DESTDIR)/usr/lib
+#	copy the lib file to std lib location
+	cp $(LIBEAP) $(DESTDIR)/usr/lib
+	ln -fs $(LIBEAP_SO) $(DESTDIR)/usr/lib/$(LIBEAP_NAME).so
+
+#	copy the headers reqd by apps using eap peer library in its own subfolder under /usr/include
+	mkdir -p \
+		$(DESTDIR)/$(INCLUDE_INSTALL_DIR)/eap_common \
+		$(DESTDIR)/$(INCLUDE_INSTALL_DIR)/common \
+		$(DESTDIR)/$(INCLUDE_INSTALL_DIR)/util \
+		$(DESTDIR)/$(INCLUDE_INSTALL_DIR)/crypto
+	install -m 0644 $(EAP_COMMON_HEADERS) $(DESTDIR)/$(INCLUDE_INSTALL_DIR)/eap_common
+	install -m 0644 $(COMMON_HEADERS) $(DESTDIR)/$(INCLUDE_INSTALL_DIR)/common
+	install -m 0644 $(CRYPTO_HEADERS) $(DESTDIR)/$(INCLUDE_INSTALL_DIR)/crypto
+	install -m 0644 $(UTIL_HEADERS) $(DESTDIR)/$(INCLUDE_INSTALL_DIR)/util
+	install -m 0644 $(MAIN_HEADERS) $(DESTDIR)/$(INCLUDE_INSTALL_DIR)/
+
+	mkdir -p $(DESTDIR)/usr/lib/pkgconfig
+	cp libeap0.pc $(DESTDIR)/usr/lib/pkgconfig
+
+uninstall: 
+
+	rm $(DESTDIR)/usr/lib/$(LIBEAP)
+	rm -fr $(DESTDIR)/$(INCLUDE_INSTALL_DIR)
+	rm -f $(DESTDIR)/usr/lib/pkgconfig/libeap0.pc
 
 clean:
-	rm -f *~ *.o *.so *.d
+	rm -f *~ *.o *.so *.d libeap.a $(LIBEAP) $(OBJS_lib)
 
-install:
-	if ls *.so >/dev/null 2>&1; then \
-		install -d $(DESTDIR)$(LIBDIR)/wpa_supplicant && \
-		cp *.so $(DESTDIR)$(LIBDIR)/wpa_supplicant \
-	; fi
+-include $(OBJS:%.o=%.d)
diff --git a/src/eap_peer/eap_methods.c b/src/eap_peer/eap_methods.c
index 3b0af05..092f266 100644
--- a/src/eap_peer/eap_methods.c
+++ b/src/eap_peer/eap_methods.c
@@ -340,6 +340,120 @@ int eap_peer_method_register(struct eap_method *method)
 

 /**
+ * eap_peer_register_methods - Register all known EAP peer methods
+ *
+ * This function is called at program start to register all compiled
+ * in EAP peer methods.
+ */
+int eap_peer_register_methods(void)
+{
+	int ret = 0;
+
+#ifdef EAP_MD5
+	if (ret == 0)
+		ret = eap_peer_md5_register();
+#endif /* EAP_MD5 */
+
+#ifdef EAP_TLS
+	if (ret == 0)
+		ret = eap_peer_tls_register();
+#endif /* EAP_TLS */
+
+#ifdef EAP_MSCHAPv2
+	if (ret == 0)
+		ret = eap_peer_mschapv2_register();
+#endif /* EAP_MSCHAPv2 */
+
+#ifdef EAP_PEAP
+	if (ret == 0)
+		ret = eap_peer_peap_register();
+#endif /* EAP_PEAP */
+
+#ifdef EAP_TTLS
+	if (ret == 0)
+		ret = eap_peer_ttls_register();
+#endif /* EAP_TTLS */
+
+#ifdef EAP_GTC
+	if (ret == 0)
+		ret = eap_peer_gtc_register();
+#endif /* EAP_GTC */
+
+#ifdef EAP_OTP
+	if (ret == 0)
+		ret = eap_peer_otp_register();
+#endif /* EAP_OTP */
+
+#ifdef EAP_SIM
+	if (ret == 0)
+		ret = eap_peer_sim_register();
+#endif /* EAP_SIM */
+
+#ifdef EAP_LEAP
+	if (ret == 0)
+		ret = eap_peer_leap_register();
+#endif /* EAP_LEAP */
+
+#ifdef EAP_PSK
+	if (ret == 0)
+		ret = eap_peer_psk_register();
+#endif /* EAP_PSK */
+
+#ifdef EAP_AKA
+	if (ret == 0)
+		ret = eap_peer_aka_register();
+#endif /* EAP_AKA */
+
+#ifdef EAP_AKA_PRIME
+	if (ret == 0)
+		ret = eap_peer_aka_prime_register();
+#endif /* EAP_AKA_PRIME */
+
+#ifdef EAP_FAST
+	if (ret == 0)
+		ret = eap_peer_fast_register();
+#endif /* EAP_FAST */
+
+#ifdef EAP_PAX
+	if (ret == 0)
+		ret = eap_peer_pax_register();
+#endif /* EAP_PAX */
+
+#ifdef EAP_SAKE
+	if (ret == 0)
+		ret = eap_peer_sake_register();
+#endif /* EAP_SAKE */
+
+#ifdef EAP_GPSK
+	if (ret == 0)
+		ret = eap_peer_gpsk_register();
+#endif /* EAP_GPSK */
+
+#ifdef EAP_WSC
+	if (ret == 0)
+		ret = eap_peer_wsc_register();
+#endif /* EAP_WSC */
+
+#ifdef EAP_IKEV2
+	if (ret == 0)
+		ret = eap_peer_ikev2_register();
+#endif /* EAP_IKEV2 */
+
+#ifdef EAP_VENDOR_TEST
+	if (ret == 0)
+		ret = eap_peer_vendor_test_register();
+#endif /* EAP_VENDOR_TEST */
+
+#ifdef EAP_TNC
+	if (ret == 0)
+		ret = eap_peer_tnc_register();
+#endif /* EAP_TNC */
+
+	return ret;
+}
+
+
+/**
  * eap_peer_unregister_methods - Unregister EAP peer methods
  *
  * This function is called at program termination to unregister all EAP peer
diff --git a/src/eap_peer/eap_methods.h b/src/eap_peer/eap_methods.h
index 384c61b..b83a46f 100644
--- a/src/eap_peer/eap_methods.h
+++ b/src/eap_peer/eap_methods.h
@@ -32,6 +32,7 @@ EapType eap_peer_get_type(const char *name, int *vendor);
 const char * eap_get_name(int vendor, EapType type);
 size_t eap_get_names(char *buf, size_t buflen);
 char ** eap_get_names_as_string_array(size_t *num);
+int eap_peer_register_methods(void);
 void eap_peer_unregister_methods(void);
 
 #else /* IEEE8021X_EAPOL */
diff --git a/src/eap_peer/libeap0.pc b/src/eap_peer/libeap0.pc
new file mode 100644
index 0000000..2f8463a
--- /dev/null
+++ b/src/eap_peer/libeap0.pc
@@ -0,0 +1,10 @@
+prefix=/usr
+exec_prefix=/usr
+libdir=${exec_prefix}/lib
+includedir=${prefix}/include/eap_peer
+
+Name: libeap0
+Description: EAP Peer Library API
+Version: 0.7.2
+Libs: -L${libdir} -leap
+Cflags: -I${includedir}
-- 
1.6.6.1





From saurav.barik  Mon Oct  4 11:32:41 2010
From: saurav.barik (saurav barik)
Date: Tue, 5 Oct 2010 00:02:41 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct "private_key_passwd"
Message-ID: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>

Hi,

I am trying to setup EAP-TLS with wpa_supplicant(v0.6.10) and radius
server(in windows server 2008). I generated the certificates and could
authenticate the user successfully. However during my tests I found
that -
After a successful authentication, if I change "private_key_passwd" in
wpa_supplicant.conf and run "RECONFIGURE"(from wpa_cli) - Still the
authentication is successful. Does the wpa_supplicant still use the
old password to authenticate? Or does it ignore the new authentication
request (because of RECONFIGURE), as it is already
authenticated/connected to the AP? Please note that if I stop
wpa_supplicant and run it again(with _wrong_ password in conf file),
it fails to authenticate - which is the right thing.

I searched in the mailing list but could not find any relevant
discussion. Please share some pointers.

Thanks in advance,
Saurav

My wpa_supplicant.conf file -

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=root

network={
     ssid="ENT-TEST"
     key_mgmt=WPA-EAP
     pairwise=CCMP TKIP
     group=CCMP TKIP
     eap=TLS
     identity="saurav at hsradius.com"
     ca_cert="/etc/cert/ca.pem"
     client_cert="/etc/cert/user.pem"
     private_key="/etc/cert/user.prv"
     private_key_passwd="saurav"
     priority=4
}


From blaise  Mon Oct  4 15:28:35 2010
From: blaise (Blaise Gassend)
Date: Mon, 4 Oct 2010 15:28:35 -0700
Subject: Patch to split roaming out of wpa_supplicant
In-Reply-To: <AANLkTinf4Xq9UsmE7CHk1r6iRQJFt4a1cDeYQzT9T69F@mail.gmail.com>
References: <AANLkTinf4Xq9UsmE7CHk1r6iRQJFt4a1cDeYQzT9T69F@mail.gmail.com>
Message-ID: <AANLkTinhNVX9q6rNSi=hKNRWBskte-k9z4zGPcUVg31f@mail.gmail.com>

Hi folks,

Any interest?

Blaise

On Fri, Oct 1, 2010 at 11:56 AM, Blaise Gassend <blaise at willowgarage.com> wrote:
> Hi folks,
>
> I have a patch that I would be interested in pushing into
> wpa_supplicant. Before I get it into a shape that is useable by
> others, I would like to gauge whether it has a chance of being
> accepted.
>
> I'm currently working on a wireless seamless roaming solution for my
> company's robots (willowgarage.com). My general strategy has been to
> use wpa_supplicant to handle talking to the driver, and managing
> keys/security, and to split out decisions about scanning and what to
> associate to to my own code in python for ease of prototyping.
>
> In order to make this happen, I have had to put my own hooks into
> wpa_supplicant, and disable all its automated attempts at scanning and
> associating: the current wpa_cli API doesn't give me enough control,
> and after spending a while trying to determine if the dbus API had
> everything I needed, I decided that it would be quicker to put in my
> own hooks.
>
> I now have a patch that is starting to work for me, and am wondering
> if it could be valuable to others, and how best to make it available.
> If I was to provide a patch that adds a build flag that does the items
> below, would it have a chance of making it into the upstream
> wpa_supplicant? If there is interest, I will do the cleanup needed to
> make this easy to use for others (otherwise, my code that interfaces
> with ROS is available at
> https://code.ros.org/svn/ros-pkg/stacks/linux_networking/trunk/wpa_supplicant_node).
>
> The patch would include:
> - Build a .so and .pc file instead of a binary, that you can then link
> with your own code.
> - Disable all automatic scanning and association.
> - The following hooks (which I would rename to make them ROS
> agnostic), which get called at appropriate times during startup,
> shutdown, and upon association or scanning events.
>
> int ros_init(int *argc, char ***argv);
> void ros_init2();
> void ros_deinit();
> void ros_add_iface(struct wpa_supplicant *wpa_s);
> void ros_remove_iface(struct wpa_supplicant *wpa_s);
> void ros_scan_completed(struct wpa_supplicant *wpa_s, struct
> wpa_scan_results *scan_res);
> void ros_assoc_success(struct wpa_supplicant *wpa_s);
> void ros_assoc_failed(struct wpa_supplicant *wpa_s, const u8* bssid,
> const char *reason);
>
> Thanks,
> Blaise
>


From holgerschurig  Mon Oct  4 23:39:20 2010
From: holgerschurig (Holger Schurig)
Date: Tue, 5 Oct 2010 08:39:20 +0200
Subject: Patch to split roaming out of wpa_supplicant
In-Reply-To: <AANLkTinf4Xq9UsmE7CHk1r6iRQJFt4a1cDeYQzT9T69F@mail.gmail.com>
References: <AANLkTinf4Xq9UsmE7CHk1r6iRQJFt4a1cDeYQzT9T69F@mail.gmail.com>
Message-ID: <201010050839.20605.holgerschurig@gmail.com>

Splitting roaming and the rest into two separate parts could be useful.
However, many of your other things are unrelated to this.

For example,

> - Build a .so and .pc file instead of a binary, that you can then link
> with your own code.


You could divide your patch into several patches, each doing one (and only 
one) thing. One patch for your libraryzation. Probably no one else needs that. 
Then maybe several patches that single out all the roaming code, e.g. by 
centralizing it to one file. Then a patch that allows to completely disable 
roaming, either as config variable or as CONFIG define.

I personally would like such an option, and use it well.



> - The following hooks (which I would rename to make them ROS
> agnostic), which get called at appropriate times during startup,
> shutdown, and upon association or scanning events.

Are this hooks just an interface from the librarified wpa_supplicant into your 
main program, which now uses wpa_supplicant?   Or vica versa?  Whatever it is, 
this should also be one patch, and is probably the one that has the least 
chance of getting in, because it's not entirely clear how this patch would be 
a win for wpa_supplicant as-is.

-- 
Homepage: http://www.holgerschurig.de


From wpa  Tue Oct  5 05:13:10 2010
From: wpa (Berend Dekens)
Date: Tue, 05 Oct 2010 14:13:10 +0200
Subject: Problem authenticating WPA2 network: OpenSSL rejects certificate
Message-ID: <4CAB1656.7040408@cyberwizzard.nl>

 I am using a university network called Eduroam which is a WPA2 network
with EAP and TTLS and PAP inner authentication. When I provide the
ca_cert (and/or ca_cert2) option, WPA supplicant fails:

Trying to associate with 00:1c:58:f1:52:02 (SSID='eduroam' freq=2437 MHz)
Associated with 00:1c:58:f1:52:02
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
TLS: Certificate verification failed, error 19 (self signed certificate
in certificate chain) depth 2 for '/C=US/O=GTE Corporation/OU=GTE
CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root'
CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=2 subject='/C=US/O=GTE
Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global
Root' err='self signed certificate in certificate chain'
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
CTRL-EVENT-EAP-FAILURE EAP authentication failed

When I ommit the option, authentication works as expected:
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GTE Corporation/OU=GTE
CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root'
CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GTE Corporation/OU=GTE
CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root'
CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/O=Cybertrust
Inc/CN=Cybertrust SureServer Standard Validation CA'
CTRL-EVENT-EAP-PEER-CERT depth=0
subject='/C=NL/ST=OV/L=Enschede/O=University of
Twente/OU=ICTS/emailAddress=radius-certificate at utwente.nl/CN=radius.utwente.nl'
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
WPA: Key negotiation completed with 00:07:0e:15:a7:41 [PTK=CCMP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to 00:07:0e:15:a7:41 completed (auth)
[id=4 id_str=]

The problem is that the GUI always inserts the ca_cert value so I am
currently forced to set up my wifi by hand.

I am confused as to what is failing, according to the manual, the
ca_cert should point to a folder or file holding the trusted CA. So why
is wpa_supplicant complaining about not being able to validate the
certificate? It *is* the CA...

I tried setting the ca_cert value to the system cert folder, the
explicit certificate (GTE_CyberTrust_Global_Root.pem) or any of the CA
bundles I could find on my computer. Nothing works.

Is this a bug in wpa_supplicant or am I setting it up wrong?

FYI: The GUI I would otherwise use is the NetworkManager applet from KDE
4.5.1.

Regards,
Berend Dekens



From j  Tue Oct  5 05:32:31 2010
From: j (Jouni Malinen)
Date: Tue, 5 Oct 2010 15:32:31 +0300
Subject: Problem authenticating WPA2 network: OpenSSL rejects certificate
In-Reply-To: <4CAB1656.7040408@cyberwizzard.nl>
References: <4CAB1656.7040408@cyberwizzard.nl>
Message-ID: <20101005123231.GA6749@jm.kir.nu>

On Tue, Oct 05, 2010 at 02:13:10PM +0200, Berend Dekens wrote:
>  I am using a university network called Eduroam which is a WPA2 network
> with EAP and TTLS and PAP inner authentication. When I provide the
> ca_cert (and/or ca_cert2) option, WPA supplicant fails:

ca_cert2 would not be applicable for EAP-TTLS/PAP.

> SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
> OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL

Are you use the certificate you configured is the correct one for the
chain used for the authentication server certificate?

> The problem is that the GUI always inserts the ca_cert value so I am
> currently forced to set up my wifi by hand.

Well, that is not the problem.. Not setting ca_cert would be a problem
since with that, the server would not get authenticated at all and you
could as well be sending out your username/password in clear to anyone
who asks..

> I am confused as to what is failing, according to the manual, the
> ca_cert should point to a folder or file holding the trusted CA. So why
> is wpa_supplicant complaining about not being able to validate the
> certificate? It *is* the CA...

It sounds like the certificate file you are using may not match with the
certificate chain provided by the authentication server. Without seeing
the actual certificates, it is difficult to say whether that is indeed
the case, though.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Tue Oct  5 05:35:55 2010
From: j (Jouni Malinen)
Date: Tue, 5 Oct 2010 15:35:55 +0300
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
Message-ID: <20101005123555.GB6749@jm.kir.nu>

On Tue, Oct 05, 2010 at 12:02:41AM +0530, saurav barik wrote:

> After a successful authentication, if I change "private_key_passwd" in
> wpa_supplicant.conf and run "RECONFIGURE"(from wpa_cli) - Still the
> authentication is successful. Does the wpa_supplicant still use the
> old password to authenticate? Or does it ignore the new authentication
> request (because of RECONFIGURE), as it is already
> authenticated/connected to the AP? Please note that if I stop
> wpa_supplicant and run it again(with _wrong_ password in conf file),
> it fails to authenticate - which is the right thing.

The new configuration is not used unless there is new authentication..
RECONFIGURE by itself may not end up triggering that.

-- 
Jouni Malinen                                            PGP id EFC895FA


From saurav.barik  Tue Oct  5 06:10:59 2010
From: saurav.barik (saurav barik)
Date: Tue, 5 Oct 2010 18:40:59 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <20101005123555.GB6749@jm.kir.nu>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
Message-ID: <AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>

Thanks very much Jouni.
Is there any way to trigger a forced reauthentication from a running
wpa_supplicant? wpa_cli config options does not have it.

Regards,
Saurav

On Tue, Oct 5, 2010 at 6:05 PM, Jouni Malinen <j at w1.fi> wrote:
> On Tue, Oct 05, 2010 at 12:02:41AM +0530, saurav barik wrote:
>
>> After a successful authentication, if I change "private_key_passwd" in
>> wpa_supplicant.conf and run "RECONFIGURE"(from wpa_cli) - Still the
>> authentication is successful. Does the wpa_supplicant still use the
>> old password to authenticate? Or does it ignore the new authentication
>> request (because of RECONFIGURE), as it is already
>> authenticated/connected to the AP? Please note that if I stop
>> wpa_supplicant and run it again(with _wrong_ password in conf file),
>> it fails to authenticate - which is the right thing.
>
> The new configuration is not used unless there is new authentication..
> RECONFIGURE by itself may not end up triggering that.
>
> --
> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>


From wpa  Tue Oct  5 06:17:48 2010
From: wpa (Berend Dekens)
Date: Tue, 05 Oct 2010 15:17:48 +0200
Subject: Problem authenticating WPA2 network: OpenSSL rejects certificate
In-Reply-To: <20101005123231.GA6749@jm.kir.nu>
References: <4CAB1656.7040408@cyberwizzard.nl>
	<20101005123231.GA6749@jm.kir.nu>
Message-ID: <4CAB257C.5050504@cyberwizzard.nl>

 On 05/10/10 14:32, Jouni Malinen wrote:
>> I am confused as to what is failing, according to the manual, the
>> ca_cert should point to a folder or file holding the trusted CA. So why
>> is wpa_supplicant complaining about not being able to validate the
>> certificate? It *is* the CA...
> It sounds like the certificate file you are using may not match with the
> certificate chain provided by the authentication server. Without seeing
> the actual certificates, it is difficult to say whether that is indeed
> the case, though.
The certificate failing is GTE_CyberTrust_Global_Root.pem, which is
installed by default on all computers with OpenSSL I think. But even
without pointing to a specific certificate (so it can search all
available certificates on my system) it fails.

A colleague running Ubuntu provides the same options and he logs in just
fine. I tried downgrading to wpa_supplicant 0.6.10 (same version he
uses) and I compared the PEM file on both systems, both are identical.

So why can he log in with the 'ca_cert' option and I can't? I am using
Gentoo and he is using Ubuntu...


From j  Tue Oct  5 11:28:07 2010
From: j (Jouni Malinen)
Date: Tue, 5 Oct 2010 21:28:07 +0300
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
Message-ID: <20101005182807.GA19004@jm.kir.nu>

On Tue, Oct 05, 2010 at 06:40:59PM +0530, saurav barik wrote:
> Is there any way to trigger a forced reauthentication from a running
> wpa_supplicant? wpa_cli config options does not have it.

When using IEEE 802.1X/EAP, logoff follow by logon would do this without
reassociation and reassociate will do this in all security modes
(though, PMKSA caching may be used to skip EAP authentication in that
case).

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Tue Oct  5 11:31:32 2010
From: j (Jouni Malinen)
Date: Tue, 5 Oct 2010 21:31:32 +0300
Subject: Problem authenticating WPA2 network: OpenSSL rejects certificate
In-Reply-To: <4CAB257C.5050504@cyberwizzard.nl>
References: <4CAB1656.7040408@cyberwizzard.nl>
	<20101005123231.GA6749@jm.kir.nu>
	<4CAB257C.5050504@cyberwizzard.nl>
Message-ID: <20101005183132.GB19004@jm.kir.nu>

On Tue, Oct 05, 2010 at 03:17:48PM +0200, Berend Dekens wrote:
> The certificate failing is GTE_CyberTrust_Global_Root.pem, which is
> installed by default on all computers with OpenSSL I think. But even
> without pointing to a specific certificate (so it can search all
> available certificates on my system) it fails.
> 
> A colleague running Ubuntu provides the same options and he logs in just
> fine. I tried downgrading to wpa_supplicant 0.6.10 (same version he
> uses) and I compared the PEM file on both systems, both are identical.
> 
> So why can he log in with the 'ca_cert' option and I can't? I am using
> Gentoo and he is using Ubuntu...

wpa_supplicant does not have much control on this part when using
OpenSSL.. Maybe your OpenSSL build has some options that disallows this
particular certificate for some reason. For example, disabling use of
MD5 as certificate hash algorithm would be good from security view
point, but it would result in number of interop issues with old root
certificates that are still in use.

-- 
Jouni Malinen                                            PGP id EFC895FA


From pstew  Tue Oct  5 12:07:23 2010
From: pstew (Paul Stewart)
Date: Tue, 5 Oct 2010 12:07:23 -0700
Subject: [PATCH] dbus_new_handlers: Don't send NULL to dbus_message_new_error
Message-ID: <20101005203356.9DE94205A7@glenhelen.mtv.corp.google.com>

From: Paul Stewart <pstew at google.com>

The new DBus API helper function wpas_dbus_error_unknown_error
function can be called as a result of a failure within internal
getter calls, which will call this function with a NULL message
parameter.  However, dbus_message_new_error looks very unkindly
(i.e, abort()) on a NULL message, so in this case, we should not
call it.

I've observed this course of events during a call to
wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
We got here through a call to fill_dict_with_properties which
explicitly calls getters with a NULL message parameter.  Judging
from the way it is called, this could easily occur if an AP sends
out a malformed (or mis-received) probe response.  I usually run
into this problem while driving through San Francisco, so I'm
exposed to any number of base stations along this path.

---
 wpa_supplicant/dbus/dbus_new_handlers.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index 8e87e20..b9f6a8d 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -117,6 +117,16 @@ static char * wpas_dbus_new_decompose_object_path(const char *path,
 DBusMessage * wpas_dbus_error_unknown_error(DBusMessage *message,
 					    const char *arg)
 {
+	/*
+	 * This function can be called as a result of a failure
+	 * within internal getter calls, which will call this function
+	 * with a NULL message parameter.  However, dbus_message_new_error
+	 * looks very unkindly (i.e, abort()) on a NULL message, so
+	 * in this case, we should not call it.
+	 */
+	if (message == NULL)
+		return NULL;
+
 	return dbus_message_new_error(message, WPAS_DBUS_ERROR_UNKNOWN_ERROR,
 				      arg);
 }
-- 
1.7.1



From wpa  Wed Oct  6 04:45:12 2010
From: wpa (Berend Dekens)
Date: Wed, 06 Oct 2010 13:45:12 +0200
Subject: Problem authenticating WPA2 network: OpenSSL rejects certificate
In-Reply-To: <20101005183132.GB19004@jm.kir.nu>
References: <4CAB1656.7040408@cyberwizzard.nl>
	<20101005123231.GA6749@jm.kir.nu> <4CAB257C.5050504@cyberwizzard.nl>
	<20101005183132.GB19004@jm.kir.nu>
Message-ID: <4CAC6148.5070607@cyberwizzard.nl>

 On 05/10/10 20:31, Jouni Malinen wrote:
> wpa_supplicant does not have much control on this part when using
> OpenSSL.. Maybe your OpenSSL build has some options that disallows this
> particular certificate for some reason. For example, disabling use of
> MD5 as certificate hash algorithm would be good from security view
> point, but it would result in number of interop issues with old root
> certificates that are still in use.
I verified the certificate with openssl and rebuild openssl with every
option available (and ofcourse recompiled wpa_supplicant afterwards).
Nothing helped.

This bug is known in Ubuntu as
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/284409
and others have it as well. This italian user found the same 'solution'
as I did: disable the verification altogether by removing the ca_cert
option: http://www.slacky.eu/forum/viewtopic.php?p=232793

Since OpenSSL attempts to verify the certificate itself (which is
impossible as it is the root CA), it looks to me like a bug in
wpa_supplicant or OpenSSL. Afaik it is impossible to verify a root CA
certificate as there is nobody able to 'claim' the certificate as being
signed by them.


From wpa  Wed Oct  6 05:23:30 2010
From: wpa (Berend Dekens)
Date: Wed, 06 Oct 2010 14:23:30 +0200
Subject: Problem authenticating WPA2 network: OpenSSL rejects certificate
In-Reply-To: <4CAC6148.5070607@cyberwizzard.nl>
References: <4CAB1656.7040408@cyberwizzard.nl>	<20101005123231.GA6749@jm.kir.nu>
	<4CAB257C.5050504@cyberwizzard.nl>	<20101005183132.GB19004@jm.kir.nu>
	<4CAC6148.5070607@cyberwizzard.nl>
Message-ID: <4CAC6A42.5030106@cyberwizzard.nl>

 On 06/10/10 13:45, Berend Dekens wrote:
>  On 05/10/10 20:31, Jouni Malinen wrote:
>> wpa_supplicant does not have much control on this part when using
>> OpenSSL.. Maybe your OpenSSL build has some options that disallows this
>> particular certificate for some reason. For example, disabling use of
>> MD5 as certificate hash algorithm would be good from security view
>> point, but it would result in number of interop issues with old root
>> certificates that are still in use.
> I verified the certificate with openssl and rebuild openssl with every
> option available (and ofcourse recompiled wpa_supplicant afterwards).
> Nothing helped.
>
> This bug is known in Ubuntu as
> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/284409
> and others have it as well. This italian user found the same 'solution'
> as I did: disable the verification altogether by removing the ca_cert
> option: http://www.slacky.eu/forum/viewtopic.php?p=232793
>
> Since OpenSSL attempts to verify the certificate itself (which is
> impossible as it is the root CA), it looks to me like a bug in
> wpa_supplicant or OpenSSL. Afaik it is impossible to verify a root CA
> certificate as there is nobody able to 'claim' the certificate as being
> signed by them.
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
I just found a solution after I found out that OpenSSL is preferred over
GnuTLS (when available). Since OpenSSL kept throwing a tantrum, I
decided to disable OpenSSL entirely and include GnuTLS instead.

Lo and behold: it works! So I'd say there is some serious problem in
OpenSSL that prevents root certificates being accepted as such. Is this
a known issue?

Regards,
Berend Dekens


From kalle.valo  Wed Oct  6 05:46:46 2010
From: kalle.valo (Kalle Valo)
Date: Wed, 06 Oct 2010 15:46:46 +0300
Subject: [PATCH] Fix scan retry after a failure
Message-ID: <20101006124646.22215.3237.stgit@potku.valot.fi>

With broadcom's "wl" driver the first scan always fails. (Apparently it also
doesn't send scan results ready signals, but let's forget it for now.) With
connman's five minute scan interval it meant that it would take five minutes
from boot until a wireless connection was established.

The reason is that currently wpasupplicant doesn't handle scan retries
and it goes directly to INACTIVE state:

14:23:09 wpa_supplicant[1046]: Scan timeout - try to get results
14:23:09 wpa_supplicant[1046]: Failed to get scan results
14:23:09 wpa_supplicant[1046]: Failed to get scan results - try scanning again
14:23:09 wpa_supplicant[1046]: State: SCANNING -> INACTIVE

Instead of going to INACTIVE set wpa_s->scan_req to make it explicit
that this is a requested scan and fix check in wpa_supplicant_req_new_scan().

This is based on Michael Terry's patch for wpasupplicant 0.6.x reported here:

http://w1.fi/bugz/show_bug.cgi?id=374
---
 wpa_supplicant/events.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
index 85dcfb2..16373da 100644
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -700,11 +700,12 @@ wpa_supplicant_pick_network(struct wpa_supplicant *wpa_s,
 static void wpa_supplicant_req_new_scan(struct wpa_supplicant *wpa_s,
 					int timeout_sec, int timeout_usec)
 {
-	if (!wpa_supplicant_enabled_networks(wpa_s->conf)) {
+	if (!wpa_supplicant_enabled_networks(wpa_s->conf) &&
+	    !wpa_s->scan_req) {
 		/*
-		 * No networks are enabled; short-circuit request so
-		 * we don't wait timeout seconds before transitioning
-		 * to INACTIVE state.
+		 * No networks are enabled nor explicit scan requests are
+		 * made; short-circuit request so we don't wait timeout
+		 * seconds before transitioning to INACTIVE state.
 		 */
 		wpa_supplicant_set_state(wpa_s, WPA_INACTIVE);
 		return;
@@ -893,6 +894,7 @@ static void wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s,
 			return;
 		wpa_printf(MSG_DEBUG, "Failed to get scan results - try "
 			   "scanning again");
+		wpa_s->scan_req = 2;
 		wpa_supplicant_req_new_scan(wpa_s, 1, 0);
 		return;
 	}



From dcbw  Wed Oct  6 07:02:50 2010
From: dcbw (Dan Williams)
Date: Wed, 06 Oct 2010 09:02:50 -0500
Subject: [PATCH] dbus_new_handlers: Don't send NULL to
	dbus_message_new_error
In-Reply-To: <20101005203356.9DE94205A7@glenhelen.mtv.corp.google.com>
References: <20101005203356.9DE94205A7@glenhelen.mtv.corp.google.com>
Message-ID: <1286373770.2422.3.camel@dcbw.foobar.com>

On Tue, 2010-10-05 at 12:07 -0700, Paul Stewart wrote:
> From: Paul Stewart <pstew at google.com>
> 
> The new DBus API helper function wpas_dbus_error_unknown_error
> function can be called as a result of a failure within internal
> getter calls, which will call this function with a NULL message
> parameter.  However, dbus_message_new_error looks very unkindly
> (i.e, abort()) on a NULL message, so in this case, we should not
> call it.
> 
> I've observed this course of events during a call to
> wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
> We got here through a call to fill_dict_with_properties which
> explicitly calls getters with a NULL message parameter.  Judging
> from the way it is called, this could easily occur if an AP sends
> out a malformed (or mis-received) probe response.  I usually run
> into this problem while driving through San Francisco, so I'm
> exposed to any number of base stations along this path.

I'm thinking that instead, we should just pass the DBusMessage down to
fill_dict_with_properties() so that they can do something intelligent
with the error.  That would probably  mean changing the return type of
fill_dict_with_properties() to a DBusMessage* which would be NULL on
success, and an error message on error.

Dan

> ---
>  wpa_supplicant/dbus/dbus_new_handlers.c |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
> index 8e87e20..b9f6a8d 100644
> --- a/wpa_supplicant/dbus/dbus_new_handlers.c
> +++ b/wpa_supplicant/dbus/dbus_new_handlers.c
> @@ -117,6 +117,16 @@ static char * wpas_dbus_new_decompose_object_path(const char *path,
>  DBusMessage * wpas_dbus_error_unknown_error(DBusMessage *message,
>  					    const char *arg)
>  {
> +	/*
> +	 * This function can be called as a result of a failure
> +	 * within internal getter calls, which will call this function
> +	 * with a NULL message parameter.  However, dbus_message_new_error
> +	 * looks very unkindly (i.e, abort()) on a NULL message, so
> +	 * in this case, we should not call it.
> +	 */
> +	if (message == NULL)
> +		return NULL;
> +
>  	return dbus_message_new_error(message, WPAS_DBUS_ERROR_UNKNOWN_ERROR,
>  				      arg);
>  }




From pstew  Wed Oct  6 08:25:23 2010
From: pstew (Paul Stewart)
Date: Wed, 6 Oct 2010 08:25:23 -0700
Subject: [PATCH] dbus_new_handlers: Don't send NULL to
	dbus_message_new_error
In-Reply-To: <1286373770.2422.3.camel@dcbw.foobar.com>
References: <20101005203356.9DE94205A7@glenhelen.mtv.corp.google.com>
	<1286373770.2422.3.camel@dcbw.foobar.com>
Message-ID: <AANLkTinz=Cx67q222BYr=m4zpfW_AQsow1qfYam7+8te@mail.gmail.com>

On Wed, Oct 6, 2010 at 7:02 AM, Dan Williams <dcbw at redhat.com> wrote:
> On Tue, 2010-10-05 at 12:07 -0700, Paul Stewart wrote:
>> From: Paul Stewart <pstew at google.com>
>>
>> The new DBus API helper function wpas_dbus_error_unknown_error
>> function can be called as a result of a failure within internal
>> getter calls, which will call this function with a NULL message
>> parameter. ?However, dbus_message_new_error looks very unkindly
>> (i.e, abort()) on a NULL message, so in this case, we should not
>> call it.
>>
>> I've observed this course of events during a call to
>> wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
>> We got here through a call to fill_dict_with_properties which
>> explicitly calls getters with a NULL message parameter. ?Judging
>> from the way it is called, this could easily occur if an AP sends
>> out a malformed (or mis-received) probe response. ?I usually run
>> into this problem while driving through San Francisco, so I'm
>> exposed to any number of base stations along this path.
>
> I'm thinking that instead, we should just pass the DBusMessage down to
> fill_dict_with_properties() so that they can do something intelligent
> with the error. ?That would probably ?mean changing the return type of
> fill_dict_with_properties() to a DBusMessage* which would be NULL on
> success, and an error message on error.
>
> Dan
>

The nature of fill_dict_with_properties is that it iterates over the
properties and calls all getters.  The current behavior is tolerant of
returned errors (continues if they occur) so that if there are any
successfully retrieved properties, they are returned to the callers.
Callers currently return their own error ("No readable properties in
this interface") if no properties are returned.  I don't think
immediately replying to the caller with an error about a single
property element in an iteration makes sense in this case.

Also, there are times, such as the case where I ran into this problem,
when there wasn't actually an incoming message to respond to, and
instead, this was an outgoing signal:

wpas_dbus_getter_bss_wpa <- fill_dict_with_properties  <-
wpa_dbus_get_object_properties <- wpas_dbus_signal_bss

so, I believe that even if we resolved the first issue above, there
are still legitimate cases where the reply_to would be NULL.

--
Paul

>> ---
>> ?wpa_supplicant/dbus/dbus_new_handlers.c | ? 10 ++++++++++
>> ?1 files changed, 10 insertions(+), 0 deletions(-)
>>
>> diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
>> index 8e87e20..b9f6a8d 100644
>> --- a/wpa_supplicant/dbus/dbus_new_handlers.c
>> +++ b/wpa_supplicant/dbus/dbus_new_handlers.c
>> @@ -117,6 +117,16 @@ static char * wpas_dbus_new_decompose_object_path(const char *path,
>> ?DBusMessage * wpas_dbus_error_unknown_error(DBusMessage *message,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? const char *arg)
>> ?{
>> + ? ? /*
>> + ? ? ?* This function can be called as a result of a failure
>> + ? ? ?* within internal getter calls, which will call this function
>> + ? ? ?* with a NULL message parameter. ?However, dbus_message_new_error
>> + ? ? ?* looks very unkindly (i.e, abort()) on a NULL message, so
>> + ? ? ?* in this case, we should not call it.
>> + ? ? ?*/
>> + ? ? if (message == NULL)
>> + ? ? ? ? ? ? return NULL;
>> +
>> ? ? ? return dbus_message_new_error(message, WPAS_DBUS_ERROR_UNKNOWN_ERROR,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? arg);
>> ?}
>
>
>


From blaise  Wed Oct  6 10:56:01 2010
From: blaise (Blaise Gassend)
Date: Wed, 6 Oct 2010 10:56:01 -0700
Subject: Patch to split roaming out of wpa_supplicant
In-Reply-To: <201010050839.20605.holgerschurig@gmail.com>
References: <AANLkTinf4Xq9UsmE7CHk1r6iRQJFt4a1cDeYQzT9T69F@mail.gmail.com>
	<201010050839.20605.holgerschurig@gmail.com>
Message-ID: <AANLkTimtHVrpHNQhW=mO7mQqyNyfGpNS16OQDBxhFAe5@mail.gmail.com>

Hi Holger,

Thanks for the feedback. I agree that splitting into the three patches
you describe makes sense.

The key question remains, however. Would the hooks that allow people
writing their own roaming code to be notified of events that concern
roaming be considered for inclusion, or is there no interest? If the
answer is yes then I am willing to work to get a patch that people
find acceptable. But if a priori the answer is no, then there is no
point in my wasting time getting the patch into presentable form. How
is such a decision made? I assume that Jouni Malinen has the main say.

> You could divide your patch into several patches, each doing one (and only
> one) thing. One patch for your libraryzation.

Agreed, the libraryzation does indeed stand alone.

> Probably no one else needs that.
> Then maybe several patches that single out all the roaming code, e.g. by
> centralizing it to one file.

I see moving all the roaming related code to a single file as a pretty
large endeavor that I wouldn't feel comfortable undertaking. To
disable the roaming code, I am mostly disabling all the mechanisms
that kick of a scan, as all the other actions that wpa_supplicant
takes follow from receiving the scan results. This approach is much
less intrusive.

>                           Then a patch that allows to completely disable
> roaming, either as config variable or as CONFIG define.
>
> I personally would like such an option, and use it well.

I don't see that this patch would be useful at all without the hooks,
as when I say roaming, I am talking pretty widely. When the roaming is
off, wpa_supplicant will not do anything on its own, including initial
association. Anybody who wants to get wpa_supplicant doing something
is going to need the hooks.

That being said, the two patches are easy to decouple, so I agree that
I might as well do it.

> Are this hooks just an interface from the librarified wpa_supplicant into your
> main program, which now uses wpa_supplicant? ? Or vica versa? ?Whatever it is,
> this should also be one patch, and is probably the one that has the least
> chance of getting in, because it's not entirely clear how this patch would be
> a win for wpa_supplicant as-is.

These hooks are calls from wpa_supplicant to an external roaming code.
They allow somebody who wants to write their own roaming code to be
notified of events in wpa_supplicant. They are used by wpa_supplicant
to notify the roaming code that an important event has happened.

I do not think that this code would be useful for wpa_supplicant, the
monolithic app that does both roaming and configuring of the radio.
However, this code would help anybody who wants to use wpa_supplicant
to configure the radio without being tied to wpa_supplicant's roaming
strategy.

There are already similar hooks for the dbus API, but they don't do
everything that is needed for an agressive roaming strategy. For
instance, it looks like dbus is notified when a scan succeeds, but not
when a scan fails. If you are writing an aggressive roaming strategy,
you need to be able to trigger a scan on a few frequencies and know
immediately if it fails so that you can potentially try some more
frequencies. (Trying all frequencies at once might not be a good idea
if you know that some frequencies aren't in use and don't want to wait
5 seconds.) As another example, there are currently many places where
association fails but is never reported over dbus.

Blaise


From djkurtz  Wed Oct  6 12:00:25 2010
From: djkurtz (Daniel Kurtz)
Date: Wed, 6 Oct 2010 12:00:25 -0700
Subject: [PATCH] wpa_supplicant DBus API: Update active/passive scan logic
Message-ID: <20101006193010.EB5181323B7@visitor-1950-352d.mtv.corp.google.com>

Currently the DBus Interface.Scan API is counter-intuitive.
It issues ProbeRequests when doing passive scans when channels are specified,
and does not issue probes for active scan.

This patch updates DBus API Scan logic per the 7 test cases listed below:

  1) Request:     Passive scan (all channels)
     Should be:   No ProbeRequests; Passive Scan results for all channels
     Previous:    1 ProbeRequest on all channels for both broadcast SSID and selected network (scan_ssid=1)
     This Patch:  1 ProbeRequest on all channels for both broadcast SSID and selected network (scan_ssid=1)

  2) Request:     Passive scan (1 channel)
     Should be:   No ProbeRequests; Passive Scan results for 1 channel (plus overlapping channels)
     Previous:    1 broadcast ProbeRequest on specified channel
     This Patch:  --Fixed--: No ProbeRequests; Passive Scan results for 1 channel (plus overlapping channels)

  3) Request:     Active scan with no SSIDs (all channels)
     Should be:   1 broadcast ProbeRequest on all channels
     Previous:    No ProbeRequests;  passive scan results for all channels
     This Patch:  --Fixed--: 1 broadcast ProbeRequest on all channels

  4) Request:     Active scan with no SSIDs (1 channel)
     Should be:   1 broadcast ProbeRequest on specified channel (plus overlapping channels)
     Previous:    No ProbeRequests; Passive scan results for specified channel (plus overlapping channels)
     This Patch:  --Fixed--: 1 broadcast ProbeRequest on specified channel (plus overlapping channels)

---
 wpa_supplicant/dbus/dbus_new_handlers.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index b9f6a8d..765a158 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -1278,14 +1278,16 @@ DBusMessage * wpas_dbus_handler_scan(DBusMessage *message,
 				"passive scan");
 			goto out;
 		} else if (params.freqs && params.freqs[0]) {
-			/* wildcard ssid */
-			params.num_ssids++;
 			wpa_supplicant_trigger_scan(wpa_s, &params);
 		} else {
 			wpa_s->scan_req = 2;
 			wpa_supplicant_req_scan(wpa_s, 0, 0);
 		}
 	} else if (!os_strcmp(type, "active")) {
+		if (!params.num_ssids) {
+			/* Add wildcard ssid */
+			params.num_ssids++;
+		}
 		wpa_supplicant_trigger_scan(wpa_s, &params);
 	} else {
 		wpa_printf(MSG_DEBUG, "wpas_dbus_handler_scan[dbus]: "
-- 
1.7.1



From djkurtz  Wed Oct  6 12:53:04 2010
From: djkurtz (Daniel Kurtz)
Date: Wed, 6 Oct 2010 12:53:04 -0700
Subject: [PATCH] wpa_supplicant DBus API: Update active/passive scan logic
In-Reply-To: <20101006192851.97FDC1323B6@visitor-1950-352d.mtv.corp.google.com>
References: <20101006192851.97FDC1323B6@visitor-1950-352d.mtv.corp.google.com>
Message-ID: <AANLkTi=kYmrCaUa7e6=ZY8qE_7AGwVxqggOBxZWWkbUF@mail.gmail.com>

Oops.  Sorry, this patches to the wrong git repo.
Will sync with upstream and resubmit.

On Wed, Oct 6, 2010 at 12:00 PM, Daniel Kurtz <djkurtz at google.com> wrote:

> Currently the DBus Interface.Scan API is counter-intuitive.
> It issues ProbeRequests when doing passive scans when channels are
> specified,
> and does not issue probes for active scan.
>
> This patch updates DBus API Scan logic per the 7 test cases listed below:
>
>  1) Request:     Passive scan (all channels)
>     Should be:   No ProbeRequests; Passive Scan results for all channels
>     Previous:    1 ProbeRequest on all channels for both broadcast SSID and
> selected network (scan_ssid=1)
>     This Patch:  1 ProbeRequest on all channels for both broadcast SSID and
> selected network (scan_ssid=1)
>
>  2) Request:     Passive scan (1 channel)
>     Should be:   No ProbeRequests; Passive Scan results for 1 channel (plus
> overlapping channels)
>     Previous:    1 broadcast ProbeRequest on specified channel
>     This Patch:  --Fixed--: No ProbeRequests; Passive Scan results for 1
> channel (plus overlapping channels)
>
>  3) Request:     Active scan with no SSIDs (all channels)
>     Should be:   1 broadcast ProbeRequest on all channels
>     Previous:    No ProbeRequests;  passive scan results for all channels
>     This Patch:  --Fixed--: 1 broadcast ProbeRequest on all channels
>
>  4) Request:     Active scan with no SSIDs (1 channel)
>     Should be:   1 broadcast ProbeRequest on specified channel (plus
> overlapping channels)
>     Previous:    No ProbeRequests; Passive scan results for specified
> channel (plus overlapping channels)
>     This Patch:  --Fixed--: 1 broadcast ProbeRequest on specified channel
> (plus overlapping channels)
>
> ---
>  wpa_supplicant/dbus/dbus_new_handlers.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c
> b/wpa_supplicant/dbus/dbus_new_handlers.c
> index b9f6a8d..765a158 100644
> --- a/wpa_supplicant/dbus/dbus_new_handlers.c
> +++ b/wpa_supplicant/dbus/dbus_new_handlers.c
> @@ -1278,14 +1278,16 @@ DBusMessage * wpas_dbus_handler_scan(DBusMessage
> *message,
>                                "passive scan");
>                        goto out;
>                } else if (params.freqs && params.freqs[0]) {
> -                       /* wildcard ssid */
> -                       params.num_ssids++;
>                        wpa_supplicant_trigger_scan(wpa_s, &params);
>                } else {
>                        wpa_s->scan_req = 2;
>                        wpa_supplicant_req_scan(wpa_s, 0, 0);
>                }
>        } else if (!os_strcmp(type, "active")) {
> +               if (!params.num_ssids) {
> +                       /* Add wildcard ssid */
> +                       params.num_ssids++;
> +               }
>                wpa_supplicant_trigger_scan(wpa_s, &params);
>        } else {
>                wpa_printf(MSG_DEBUG, "wpas_dbus_handler_scan[dbus]: "
> --
> 1.7.1
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101006/4ee9d2b4/attachment.htm 


From hollunder  Wed Oct  6 13:23:42 2010
From: hollunder (Philipp)
Date: Wed, 06 Oct 2010 22:23:42 +0200
Subject: authentication issues - understanding reason numbers
Message-ID: <1286394208-sup-777@eris>

Hi,
I try to use wpa_supplicant but have trouble getting a connection.
I tried multiple frontends, wicd, wifi-radar, netcfg, but to no avail,
and now I try since some time to use wpa_supplicant directly in order to
figure out what's wrong.
I'm trying at two different networks, a home router with WPA-PSK and my
university network (eduroam) with WPA-EAP (well, it's with
identity/password for each user but without cert).

I guess the home example should be simpler, so I'll start with that.
I tried the simple home network example and the catch-all example from
the config manpage: http://linux.die.net/man/5/wpa_supplicant.conf
Both configurations lead to the same output, here with the nl80211 and
wext driver respectively:

$ sudo wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0
Trying to authenticate with 00:1f:33:b6:24:42 (SSID='effe' freq=2437
MHz)
Trying to associate with 00:1f:33:b6:24:42 (SSID='effe' freq=2437 MHz)
Associated with 00:1f:33:b6:24:42
CTRL-EVENT-DISCONNECTED bssid=00:1f:33:b6:24:42 reason=15

$ sudo wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf                                                                            
Trying to associate with 00:1f:33:b6:24:42 (SSID='effe' freq=2437 MHz)
Associated with 00:1f:33:b6:24:42
CTRL-EVENT-DISCONNECTED bssid=00:1f:33:b6:24:42 reason=0

I couldn't figure out what the magic numbers reason=15 and reason=0
mean, and the -d or -dd output didn't tell me what's wrong either. I'm
pretty much out of ideas at this point.

Here's some information about my system:
Arch Linux, kernel 2.6.35.7
wpa_supplicant 0.7.3
BCM4312 14e4:4315
b43-firmware-4.178.10.4 (4.174.64.19)
b43-fwcutter 013


I'd really appreciate any help.

Best regards,
Philipp



From dcbw  Wed Oct  6 15:31:14 2010
From: dcbw (Dan Williams)
Date: Wed, 06 Oct 2010 17:31:14 -0500
Subject: authentication issues - understanding reason numbers
In-Reply-To: <1286394208-sup-777@eris>
References: <1286394208-sup-777@eris>
Message-ID: <1286404274.25512.13.camel@dcbw.foobar.com>

On Wed, 2010-10-06 at 22:23 +0200, Philipp wrote:
> Hi,
> I try to use wpa_supplicant but have trouble getting a connection.
> I tried multiple frontends, wicd, wifi-radar, netcfg, but to no avail,
> and now I try since some time to use wpa_supplicant directly in order to
> figure out what's wrong.
> I'm trying at two different networks, a home router with WPA-PSK and my
> university network (eduroam) with WPA-EAP (well, it's with
> identity/password for each user but without cert).
> 
> I guess the home example should be simpler, so I'll start with that.
> I tried the simple home network example and the catch-all example from
> the config manpage: http://linux.die.net/man/5/wpa_supplicant.conf
> Both configurations lead to the same output, here with the nl80211 and
> wext driver respectively:
> 
> $ sudo wpa_supplicant -Dnl80211 -c/etc/wpa_supplicant.conf -iwlan0
> Trying to authenticate with 00:1f:33:b6:24:42 (SSID='effe' freq=2437
> MHz)
> Trying to associate with 00:1f:33:b6:24:42 (SSID='effe' freq=2437 MHz)
> Associated with 00:1f:33:b6:24:42
> CTRL-EVENT-DISCONNECTED bssid=00:1f:33:b6:24:42 reason=15
> 
> $ sudo wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf                                                                            
> Trying to associate with 00:1f:33:b6:24:42 (SSID='effe' freq=2437 MHz)
> Associated with 00:1f:33:b6:24:42
> CTRL-EVENT-DISCONNECTED bssid=00:1f:33:b6:24:42 reason=0
> 
> I couldn't figure out what the magic numbers reason=15 and reason=0
> mean, and the -d or -dd output didn't tell me what's wrong either. I'm
> pretty much out of ideas at this point.

Reason=0 means "no information given", or really that the driver didn't
pass up enough information for the supplicant to give you a reason code.
Looks like only the nl80211 driver actually has the *capability* to
provide reason codes, but that capability depends on whether you're
using nl80211 and whether the kernel you have provides those codes too.

The reason code that nl80211 provides comes directly from the 802.11
management frames.  This means that your "reason 15" would be:

4-Way handshake timed out

We'd need much more verbose debug logs to figure that out (use -dddt on
the supplicant's command line).

Dan


> Here's some information about my system:
> Arch Linux, kernel 2.6.35.7
> wpa_supplicant 0.7.3
> BCM4312 14e4:4315
> b43-firmware-4.178.10.4 (4.174.64.19)
> b43-fwcutter 013
> 
> 
> I'd really appreciate any help.
> 
> Best regards,
> Philipp
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap




From djkurtz  Wed Oct  6 15:26:52 2010
From: djkurtz (Daniel Kurtz)
Date: Wed, 6 Oct 2010 15:26:52 -0700
Subject: [PATCH] Currently the DBus Interface.Scan API is counter-intuitive.
	It issues ProbeRequests when doing passive scans when channels are
	specified, 
	and does not issue ProbeRequests for broadcast active scans.
Message-ID: <20101006223017.129D71323B7@visitor-1950-352d.mtv.corp.google.com>

This patch updates DBus API .Scan() logic per the test cases listed below:

 1) Interface.Scan({'Type':'passive'})
    Request:     Passive scan (all channels)
    Should be:   No ProbeRequests; Passive Scan results for all channels
    Previous:    1 ProbeRequest on all channels for both broadcast SSID and selected network (scan_ssid=1)
    This Patch:  --No change--: 1 ProbeRequest on all channels for both broadcast SSID and selected network (scan_ssid=1)

 2) Interface.Scan({'Type':'passive', 'Channel':(2412, 20)})
    Request:     Passive scan (1 channel)
    Should be:   No ProbeRequests; Passive Scan results for 1 channel (plus overlapping channels)
    Previous:    1 broadcast ProbeRequest on specified channel
    This Patch:  --Fixed--: No ProbeRequests; Passive Scan results for 1 channel (plus overlapping channels)

 3) Interface.Scan({'Type':'active'})
    Request:     Active scan with no SSIDs (all channels)
    Should be:   1 broadcast ProbeRequest on all channels
    Previous:    No ProbeRequests;  passive scan results for all channels
    This Patch:  --Fixed--: 1 broadcast ProbeRequest on all channels

 4) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
    Request:     Active scan with no SSIDs (1 channel)
    Should be:   1 broadcast ProbeRequest on specified channel
    Previous:    No ProbeRequests; Passive scan results for specified channel (plus overlapping channels)
    This Patch:  --Fixed--: 1 broadcast ProbeRequest on specified channel
---
 wpa_supplicant/dbus/dbus_new_handlers.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index e2b5e50..da39fa1 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -1260,14 +1260,16 @@ DBusMessage * wpas_dbus_handler_scan(DBusMessage *message,
 				"passive scan");
 			goto out;
 		} else if (params.freqs && params.freqs[0]) {
-			/* wildcard ssid */
-			params.num_ssids++;
 			wpa_supplicant_trigger_scan(wpa_s, &params);
 		} else {
 			wpa_s->scan_req = 2;
 			wpa_supplicant_req_scan(wpa_s, 0, 0);
 		}
 	} else if (!os_strcmp(type, "active")) {
+		if (!params.num_ssids) {
+			/* Add wildcard ssid */
+			params.num_ssids++;
+		}
 		wpa_supplicant_trigger_scan(wpa_s, &params);
 	} else {
 		wpa_printf(MSG_DEBUG, "wpas_dbus_handler_scan[dbus]: "
-- 
1.7.1



From dcbw  Wed Oct  6 15:53:22 2010
From: dcbw (Dan Williams)
Date: Wed, 06 Oct 2010 17:53:22 -0500
Subject: [PATCH] Currently the DBus Interface.Scan API is
	counter-intuitive. It issues ProbeRequests when doing passive scans
	when
	channels are specified, and does not issue ProbeRequests for broadcast
	active scans.
In-Reply-To: <20101006223017.129D71323B7@visitor-1950-352d.mtv.corp.google.com>
References: <20101006223017.129D71323B7@visitor-1950-352d.mtv.corp.google.com>
Message-ID: <1286405602.25512.26.camel@dcbw.foobar.com>

On Wed, 2010-10-06 at 15:26 -0700, Daniel Kurtz wrote:
> This patch updates DBus API .Scan() logic per the test cases listed below:

Yeah, that patch looks like the right thing to do.

Dan

>  1) Interface.Scan({'Type':'passive'})
>     Request:     Passive scan (all channels)
>     Should be:   No ProbeRequests; Passive Scan results for all channels
>     Previous:    1 ProbeRequest on all channels for both broadcast SSID and selected network (scan_ssid=1)
>     This Patch:  --No change--: 1 ProbeRequest on all channels for both broadcast SSID and selected network (scan_ssid=1)
> 
>  2) Interface.Scan({'Type':'passive', 'Channel':(2412, 20)})
>     Request:     Passive scan (1 channel)
>     Should be:   No ProbeRequests; Passive Scan results for 1 channel (plus overlapping channels)
>     Previous:    1 broadcast ProbeRequest on specified channel
>     This Patch:  --Fixed--: No ProbeRequests; Passive Scan results for 1 channel (plus overlapping channels)
> 
>  3) Interface.Scan({'Type':'active'})
>     Request:     Active scan with no SSIDs (all channels)
>     Should be:   1 broadcast ProbeRequest on all channels
>     Previous:    No ProbeRequests;  passive scan results for all channels
>     This Patch:  --Fixed--: 1 broadcast ProbeRequest on all channels
> 
>  4) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
>     Request:     Active scan with no SSIDs (1 channel)
>     Should be:   1 broadcast ProbeRequest on specified channel
>     Previous:    No ProbeRequests; Passive scan results for specified channel (plus overlapping channels)
>     This Patch:  --Fixed--: 1 broadcast ProbeRequest on specified channel
> ---
>  wpa_supplicant/dbus/dbus_new_handlers.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
> index e2b5e50..da39fa1 100644
> --- a/wpa_supplicant/dbus/dbus_new_handlers.c
> +++ b/wpa_supplicant/dbus/dbus_new_handlers.c
> @@ -1260,14 +1260,16 @@ DBusMessage * wpas_dbus_handler_scan(DBusMessage *message,
>  				"passive scan");
>  			goto out;
>  		} else if (params.freqs && params.freqs[0]) {
> -			/* wildcard ssid */
> -			params.num_ssids++;
>  			wpa_supplicant_trigger_scan(wpa_s, &params);
>  		} else {
>  			wpa_s->scan_req = 2;
>  			wpa_supplicant_req_scan(wpa_s, 0, 0);
>  		}
>  	} else if (!os_strcmp(type, "active")) {
> +		if (!params.num_ssids) {
> +			/* Add wildcard ssid */
> +			params.num_ssids++;
> +		}
>  		wpa_supplicant_trigger_scan(wpa_s, &params);
>  	} else {
>  		wpa_printf(MSG_DEBUG, "wpas_dbus_handler_scan[dbus]: "




From djkurtz  Wed Oct  6 15:46:20 2010
From: djkurtz (Daniel Kurtz)
Date: Wed, 6 Oct 2010 15:46:20 -0700
Subject: [PATCH] Treat '' in SSIDs param of DBus Interface.Scan as a request
	for braodcast scan.
Message-ID: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>

This patch changes wpa_supplicant policy for handling '' in SSIDs field of Interface.SSID DBus message.
It treats '' (zero-length) SSID as a request for a broadcast scan, instead of ignoring it.

This patch updates DBus API .Scan() logic per the test cases listed below:

1) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
   Request:     Active scan with only '' SSID (1 channel)
   Should be:   1 broadcast ProbeRequest on specified channel
   Previous:    1 broadcast ProbeRequest on specified channel
   This Patch:  1 broadcast ProbeRequest on specified channel

2) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['']})
   Request:     Active scan with only '' SSID (1 channel)
   Should be:   1 broadcast ProbeRequest on specified channel
   Previous:    No ProbeRequests; passive scan results for specified channel
   This Patch:  FIXED: 1 broadcast ProbeRequest on specified channel

3) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['MySSID']})
   Request:     Active scan with only non-'' SSIDs (1 channel)
   Should be:   1 directed ProbeRequest for each SSID on specified channel, no broadcast ProbeRequest
   Previous:    1 directed ProbeRequest for each SSID on specified channel, no broadcast ProbeRequest
   This Patch:  1 directed ProbeRequest for each SSID on specified channel, no broadcast ProbeRequest

4) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['', 'MySSID']})
   Request:     Active scan with SSIDs, including 1 '' SSID (1 channel)
   Should be:   1 broadcast ProbeRequest, 1 directed ProbeRequest for each non-'' SSID on specified channel
   Previous:    1 directed ProbeRequest for each non-'' SSID on specified channel
   This Patch:  FIXED: 1 broadcast ProbeRequest, 1 directed ProbeRequest for each non-'' SSID on specified channel
---
 wpa_supplicant/dbus/dbus_new_handlers.c |   30 +++++++++++++++++-------------
 1 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index e2b5e50..36eb917 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -987,21 +987,25 @@ static int wpas_dbus_get_scan_ssids(DBusMessage *message, DBusMessageIter *var,
 		dbus_message_iter_recurse(&array_iter, &sub_array_iter);
 
 		dbus_message_iter_get_fixed_array(&sub_array_iter, &val, &len);
-		if (len == 0) {
-			dbus_message_iter_next(&array_iter);
-			continue;
-		}
 
-		ssid = os_malloc(len);
-		if (ssid == NULL) {
-			wpa_printf(MSG_DEBUG, "wpas_dbus_handler_scan[dbus]: "
-				   "out of memory. Cannot allocate memory for "
-				   "SSID");
-			*reply = dbus_message_new_error(
-				message, DBUS_ERROR_NO_MEMORY, NULL);
-			return -1;
+		if (len != 0) {
+			ssid = os_malloc(len);
+			if (ssid == NULL) {
+				wpa_printf(MSG_DEBUG,
+					   "wpas_dbus_handler_scan[dbus]: "
+					   "out of memory. Cannot allocate "
+					   "memory for SSID");
+				*reply = dbus_message_new_error(
+						message, DBUS_ERROR_NO_MEMORY,
+						NULL);
+				return -1;
+			}
+			os_memcpy(ssid, val, len);
+		} else {
+			/* Allow zero-length SSIDs */
+			ssid = NULL;
 		}
-		os_memcpy(ssid, val, len);
+
 		ssids[ssids_num].ssid = ssid;
 		ssids[ssids_num].ssid_len = len;
 
-- 
1.7.1



From dcbw  Wed Oct  6 23:06:31 2010
From: dcbw (Dan Williams)
Date: Thu, 07 Oct 2010 01:06:31 -0500
Subject: [PATCH] Treat '' in SSIDs param of DBus Interface.Scan as a
	request for braodcast scan.
In-Reply-To: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>
References: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>
Message-ID: <1286431591.24578.1.camel@dcbw.foobar.com>

On Wed, 2010-10-06 at 15:46 -0700, Daniel Kurtz wrote:
> This patch changes wpa_supplicant policy for handling '' in SSIDs field of Interface.SSID DBus message.
> It treats '' (zero-length) SSID as a request for a broadcast scan, instead of ignoring it.

Does not sending any SSIDs somehow not work?  This seems like a pretty
big kludge.  The behavior should be that if no SSID property is sent,
then no specific scan is performed.  A zero-length SSID should actually
be rejected with an error.

Dan

> This patch updates DBus API .Scan() logic per the test cases listed below:
> 
> 1) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
>    Request:     Active scan with only '' SSID (1 channel)
>    Should be:   1 broadcast ProbeRequest on specified channel
>    Previous:    1 broadcast ProbeRequest on specified channel
>    This Patch:  1 broadcast ProbeRequest on specified channel
> 
> 2) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['']})
>    Request:     Active scan with only '' SSID (1 channel)
>    Should be:   1 broadcast ProbeRequest on specified channel
>    Previous:    No ProbeRequests; passive scan results for specified channel
>    This Patch:  FIXED: 1 broadcast ProbeRequest on specified channel
> 
> 3) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['MySSID']})
>    Request:     Active scan with only non-'' SSIDs (1 channel)
>    Should be:   1 directed ProbeRequest for each SSID on specified channel, no broadcast ProbeRequest
>    Previous:    1 directed ProbeRequest for each SSID on specified channel, no broadcast ProbeRequest
>    This Patch:  1 directed ProbeRequest for each SSID on specified channel, no broadcast ProbeRequest
> 
> 4) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['', 'MySSID']})
>    Request:     Active scan with SSIDs, including 1 '' SSID (1 channel)
>    Should be:   1 broadcast ProbeRequest, 1 directed ProbeRequest for each non-'' SSID on specified channel
>    Previous:    1 directed ProbeRequest for each non-'' SSID on specified channel
>    This Patch:  FIXED: 1 broadcast ProbeRequest, 1 directed ProbeRequest for each non-'' SSID on specified channel
> ---
>  wpa_supplicant/dbus/dbus_new_handlers.c |   30 +++++++++++++++++-------------
>  1 files changed, 17 insertions(+), 13 deletions(-)
> 
> diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
> index e2b5e50..36eb917 100644
> --- a/wpa_supplicant/dbus/dbus_new_handlers.c
> +++ b/wpa_supplicant/dbus/dbus_new_handlers.c
> @@ -987,21 +987,25 @@ static int wpas_dbus_get_scan_ssids(DBusMessage *message, DBusMessageIter *var,
>  		dbus_message_iter_recurse(&array_iter, &sub_array_iter);
>  
>  		dbus_message_iter_get_fixed_array(&sub_array_iter, &val, &len);
> -		if (len == 0) {
> -			dbus_message_iter_next(&array_iter);
> -			continue;
> -		}
>  
> -		ssid = os_malloc(len);
> -		if (ssid == NULL) {
> -			wpa_printf(MSG_DEBUG, "wpas_dbus_handler_scan[dbus]: "
> -				   "out of memory. Cannot allocate memory for "
> -				   "SSID");
> -			*reply = dbus_message_new_error(
> -				message, DBUS_ERROR_NO_MEMORY, NULL);
> -			return -1;
> +		if (len != 0) {
> +			ssid = os_malloc(len);
> +			if (ssid == NULL) {
> +				wpa_printf(MSG_DEBUG,
> +					   "wpas_dbus_handler_scan[dbus]: "
> +					   "out of memory. Cannot allocate "
> +					   "memory for SSID");
> +				*reply = dbus_message_new_error(
> +						message, DBUS_ERROR_NO_MEMORY,
> +						NULL);
> +				return -1;
> +			}
> +			os_memcpy(ssid, val, len);
> +		} else {
> +			/* Allow zero-length SSIDs */
> +			ssid = NULL;
>  		}
> -		os_memcpy(ssid, val, len);
> +
>  		ssids[ssids_num].ssid = ssid;
>  		ssids[ssids_num].ssid_len = len;
>  




From djkurtz  Wed Oct  6 23:29:38 2010
From: djkurtz (Daniel Kurtz)
Date: Wed, 6 Oct 2010 23:29:38 -0700
Subject: [PATCH] Treat '' in SSIDs param of DBus Interface.Scan as a
	request for braodcast scan.
In-Reply-To: <1286431591.24578.1.camel@dcbw.foobar.com>
References: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>
	<1286431591.24578.1.camel@dcbw.foobar.com>
Message-ID: <AANLkTinyg83g0B7TbEo686yvFX3yZrJAk+3Nvtksoij4@mail.gmail.com>

How do you perform both Broadcast and directed scan over channels at the
same time?
For example, when looking for a network to join, including some hidden
SSIDs.

-Dan

On Wed, Oct 6, 2010 at 11:06 PM, Dan Williams <dcbw at redhat.com> wrote:

> On Wed, 2010-10-06 at 15:46 -0700, Daniel Kurtz wrote:
> > This patch changes wpa_supplicant policy for handling '' in SSIDs field
> of Interface.SSID DBus message.
> > It treats '' (zero-length) SSID as a request for a broadcast scan,
> instead of ignoring it.
>
> Does not sending any SSIDs somehow not work?  This seems like a pretty
> big kludge.  The behavior should be that if no SSID property is sent,
> then no specific scan is performed.  A zero-length SSID should actually
> be rejected with an error.
>
> Dan
>
> > This patch updates DBus API .Scan() logic per the test cases listed
> below:
> >
> > 1) Interface.Scan({'Type':'active', 'Channel':(2412, 20)})
> >    Request:     Active scan with only '' SSID (1 channel)
> >    Should be:   1 broadcast ProbeRequest on specified channel
> >    Previous:    1 broadcast ProbeRequest on specified channel
> >    This Patch:  1 broadcast ProbeRequest on specified channel
> >
> > 2) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['']})
> >    Request:     Active scan with only '' SSID (1 channel)
> >    Should be:   1 broadcast ProbeRequest on specified channel
> >    Previous:    No ProbeRequests; passive scan results for specified
> channel
> >    This Patch:  FIXED: 1 broadcast ProbeRequest on specified channel
> >
> > 3) Interface.Scan({'Type':'active', 'Channel':(2412, 20),
> 'SSIDs':['MySSID']})
> >    Request:     Active scan with only non-'' SSIDs (1 channel)
> >    Should be:   1 directed ProbeRequest for each SSID on specified
> channel, no broadcast ProbeRequest
> >    Previous:    1 directed ProbeRequest for each SSID on specified
> channel, no broadcast ProbeRequest
> >    This Patch:  1 directed ProbeRequest for each SSID on specified
> channel, no broadcast ProbeRequest
> >
> > 4) Interface.Scan({'Type':'active', 'Channel':(2412, 20), 'SSIDs':['',
> 'MySSID']})
> >    Request:     Active scan with SSIDs, including 1 '' SSID (1 channel)
> >    Should be:   1 broadcast ProbeRequest, 1 directed ProbeRequest for
> each non-'' SSID on specified channel
> >    Previous:    1 directed ProbeRequest for each non-'' SSID on specified
> channel
> >    This Patch:  FIXED: 1 broadcast ProbeRequest, 1 directed ProbeRequest
> for each non-'' SSID on specified channel
> > ---
> >  wpa_supplicant/dbus/dbus_new_handlers.c |   30
> +++++++++++++++++-------------
> >  1 files changed, 17 insertions(+), 13 deletions(-)
> >
> > diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c
> b/wpa_supplicant/dbus/dbus_new_handlers.c
> > index e2b5e50..36eb917 100644
> > --- a/wpa_supplicant/dbus/dbus_new_handlers.c
> > +++ b/wpa_supplicant/dbus/dbus_new_handlers.c
> > @@ -987,21 +987,25 @@ static int wpas_dbus_get_scan_ssids(DBusMessage
> *message, DBusMessageIter *var,
> >               dbus_message_iter_recurse(&array_iter, &sub_array_iter);
> >
> >               dbus_message_iter_get_fixed_array(&sub_array_iter, &val,
> &len);
> > -             if (len == 0) {
> > -                     dbus_message_iter_next(&array_iter);
> > -                     continue;
> > -             }
> >
> > -             ssid = os_malloc(len);
> > -             if (ssid == NULL) {
> > -                     wpa_printf(MSG_DEBUG,
> "wpas_dbus_handler_scan[dbus]: "
> > -                                "out of memory. Cannot allocate memory
> for "
> > -                                "SSID");
> > -                     *reply = dbus_message_new_error(
> > -                             message, DBUS_ERROR_NO_MEMORY, NULL);
> > -                     return -1;
> > +             if (len != 0) {
> > +                     ssid = os_malloc(len);
> > +                     if (ssid == NULL) {
> > +                             wpa_printf(MSG_DEBUG,
> > +                                        "wpas_dbus_handler_scan[dbus]: "
> > +                                        "out of memory. Cannot allocate
> "
> > +                                        "memory for SSID");
> > +                             *reply = dbus_message_new_error(
> > +                                             message,
> DBUS_ERROR_NO_MEMORY,
> > +                                             NULL);
> > +                             return -1;
> > +                     }
> > +                     os_memcpy(ssid, val, len);
> > +             } else {
> > +                     /* Allow zero-length SSIDs */
> > +                     ssid = NULL;
> >               }
> > -             os_memcpy(ssid, val, len);
> > +
> >               ssids[ssids_num].ssid = ssid;
> >               ssids[ssids_num].ssid_len = len;
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101006/071218f9/attachment-0001.htm 


From witold.sowa  Thu Oct  7 04:11:36 2010
From: witold.sowa (Witold Sowa)
Date: Thu, 7 Oct 2010 13:11:36 +0200
Subject: [PATCH] dbus_new_handlers: Don't send NULL to
	dbus_message_new_error
In-Reply-To: <AANLkTinz=Cx67q222BYr=m4zpfW_AQsow1qfYam7+8te@mail.gmail.com>
References: <20101005203356.9DE94205A7@glenhelen.mtv.corp.google.com>
	<1286373770.2422.3.camel@dcbw.foobar.com>
	<AANLkTinz=Cx67q222BYr=m4zpfW_AQsow1qfYam7+8te@mail.gmail.com>
Message-ID: <AANLkTima+DcGxcjKT42+769NhDMXFGKxzo5U=pav4x6R@mail.gmail.com>

2010/10/6 Paul Stewart <pstew at google.com>

> On Wed, Oct 6, 2010 at 7:02 AM, Dan Williams <dcbw at redhat.com> wrote:
> > On Tue, 2010-10-05 at 12:07 -0700, Paul Stewart wrote:
> >> From: Paul Stewart <pstew at google.com>
> >>
> >> The new DBus API helper function wpas_dbus_error_unknown_error
> >> function can be called as a result of a failure within internal
> >> getter calls, which will call this function with a NULL message
> >> parameter.  However, dbus_message_new_error looks very unkindly
> >> (i.e, abort()) on a NULL message, so in this case, we should not
> >> call it.
> >>
> >> I've observed this course of events during a call to
> >> wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
> >> We got here through a call to fill_dict_with_properties which
> >> explicitly calls getters with a NULL message parameter.  Judging
> >> from the way it is called, this could easily occur if an AP sends
> >> out a malformed (or mis-received) probe response.  I usually run
> >> into this problem while driving through San Francisco, so I'm
> >> exposed to any number of base stations along this path.
> >
> > I'm thinking that instead, we should just pass the DBusMessage down to
> > fill_dict_with_properties() so that they can do something intelligent
> > with the error.  That would probably  mean changing the return type of
> > fill_dict_with_properties() to a DBusMessage* which would be NULL on
> > success, and an error message on error.
> >
> > Dan
> >
>
> The nature of fill_dict_with_properties is that it iterates over the
> properties and calls all getters.  The current behavior is tolerant of
> returned errors (continues if they occur) so that if there are any
> successfully retrieved properties, they are returned to the callers.
> Callers currently return their own error ("No readable properties in
> this interface") if no properties are returned.  I don't think
> immediately replying to the caller with an error about a single
> property element in an iteration makes sense in this case.
>
> Also, there are times, such as the case where I ran into this problem,
> when there wasn't actually an incoming message to respond to, and
> instead, this was an outgoing signal:
>
> wpas_dbus_getter_bss_wpa <- fill_dict_with_properties  <-
> wpa_dbus_get_object_properties <- wpas_dbus_signal_bss
>
> so, I believe that even if we resolved the first issue above, there
> are still legitimate cases where the reply_to would be NULL.
>
> --
> Paul
>

I believe that the approach in that patch is fine but I would log the
message coming in arg argument in case of NULL message so there would be any
trace of the error left in logs.

Witek


> >> ---
> >>  wpa_supplicant/dbus/dbus_new_handlers.c |   10 ++++++++++
> >>  1 files changed, 10 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c
> b/wpa_supplicant/dbus/dbus_new_handlers.c
> >> index 8e87e20..b9f6a8d 100644
> >> --- a/wpa_supplicant/dbus/dbus_new_handlers.c
> >> +++ b/wpa_supplicant/dbus/dbus_new_handlers.c
> >> @@ -117,6 +117,16 @@ static char *
> wpas_dbus_new_decompose_object_path(const char *path,
> >>  DBusMessage * wpas_dbus_error_unknown_error(DBusMessage *message,
> >>                                           const char *arg)
> >>  {
> >> +     /*
> >> +      * This function can be called as a result of a failure
> >> +      * within internal getter calls, which will call this function
> >> +      * with a NULL message parameter.  However, dbus_message_new_error
> >> +      * looks very unkindly (i.e, abort()) on a NULL message, so
> >> +      * in this case, we should not call it.
> >> +      */
> >> +     if (message == NULL)
> >> +             return NULL;
> >> +
> >>       return dbus_message_new_error(message,
> WPAS_DBUS_ERROR_UNKNOWN_ERROR,
> >>                                     arg);
> >>  }
> >
> >
> >
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101007/0b980815/attachment.htm 


From blaise  Thu Oct  7 09:15:49 2010
From: blaise (Blaise Gassend)
Date: Thu, 7 Oct 2010 09:15:49 -0700
Subject: [PATCH] Treat '' in SSIDs param of DBus Interface.Scan as a
	request for braodcast scan.
In-Reply-To: <1286431591.24578.1.camel@dcbw.foobar.com>
References: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>
	<1286431591.24578.1.camel@dcbw.foobar.com>
Message-ID: <AANLkTikG46ngqc5HAd9zXwTthsM6R-CVhnvESouRDBxb@mail.gmail.com>

On Wed, Oct 6, 2010 at 11:06 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Wed, 2010-10-06 at 15:46 -0700, Daniel Kurtz wrote:
>> This patch changes wpa_supplicant policy for handling '' in SSIDs field of Interface.SSID DBus message.
>> It treats '' (zero-length) SSID as a request for a broadcast scan, instead of ignoring it.
>
> Does not sending any SSIDs somehow not work? ?This seems like a pretty
> big kludge. ?The behavior should be that if no SSID property is sent,
> then no specific scan is performed. ?A zero-length SSID should actually
> be rejected with an error.

If I recall, iw's scan command sends an empty SSID when no ssid is
explicitely specified. A while ago iwlagn was not doing the broadcast
scan if the empty ssid wasn't there. However, I believe that was a
bug, and it has been corrected in recent versions of iwlagn.


From saurav.barik  Thu Oct  7 11:59:35 2010
From: saurav.barik (saurav barik)
Date: Fri, 8 Oct 2010 00:29:35 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <20101005182807.GA19004@jm.kir.nu>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
Message-ID: <AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>

Yes, logoff followed by logon also skips reauth. I tried forcing a
reauth using eapol_sm_request_reauth() in "logon" path. Still it does
not reauth. I am wandering whether it should be considered as a
known-issue in wpa_supplicant or is this behavior acceptable. I
believe wpa_supplicant should reauthenticate if there is a change in
EAP-TLS related config. Should I flush PMKSA caching in logon path as
well? Is there any command-line config option(from wpa_cli) for it?

Please advise.

Thanks,
Saurav

On Tue, Oct 5, 2010 at 11:58 PM, Jouni Malinen <j at w1.fi> wrote:
> On Tue, Oct 05, 2010 at 06:40:59PM +0530, saurav barik wrote:
>> Is there any way to trigger a forced reauthentication from a running
>> wpa_supplicant? wpa_cli config options does not have it.
>
> When using IEEE 802.1X/EAP, logoff follow by logon would do this without
> reassociation and reassociate will do this in all security modes
> (though, PMKSA caching may be used to skip EAP authentication in that
> case).
>
> --
> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>


From aarcane  Thu Oct  7 12:03:10 2010
From: aarcane (Christ Schlacta)
Date: Thu, 07 Oct 2010 12:03:10 -0700
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>	<20101005123555.GB6749@jm.kir.nu>	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
Message-ID: <4CAE196E.7000409@gmail.com>

  An inability to break a working config is hardly a bug.  PMKSA should 
never flush unless it's failed, and flushing any sooner, or forcing 
re-authentication sooner is wasteful of bandwidth and other resources.  
This should be classified as a feature, not as a bug.

On 10/7/2010 11:59 AM, saurav barik wrote:
> Yes, logoff followed by logon also skips reauth. I tried forcing a
> reauth using eapol_sm_request_reauth() in "logon" path. Still it does
> not reauth. I am wandering whether it should be considered as a
> known-issue in wpa_supplicant or is this behavior acceptable. I
> believe wpa_supplicant should reauthenticate if there is a change in
> EAP-TLS related config. Should I flush PMKSA caching in logon path as
> well? Is there any command-line config option(from wpa_cli) for it?
>
> Please advise.
>
> Thanks,
> Saurav
>
> On Tue, Oct 5, 2010 at 11:58 PM, Jouni Malinen<j at w1.fi>  wrote:
>> On Tue, Oct 05, 2010 at 06:40:59PM +0530, saurav barik wrote:
>>> Is there any way to trigger a forced reauthentication from a running
>>> wpa_supplicant? wpa_cli config options does not have it.
>> When using IEEE 802.1X/EAP, logoff follow by logon would do this without
>> reassociation and reassociate will do this in all security modes
>> (though, PMKSA caching may be used to skip EAP authentication in that
>> case).
>>
>> --
>> Jouni Malinen                                            PGP id EFC895FA
>> _______________________________________________
>> HostAP mailing list
>> HostAP at lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap
>>
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap



From saurav.barik  Thu Oct  7 12:22:24 2010
From: saurav.barik (saurav barik)
Date: Fri, 8 Oct 2010 00:52:24 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <4CAE196E.7000409@gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<4CAE196E.7000409@gmail.com>
Message-ID: <AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>

I agree - PMKSA caching is a good feature. But it should not force to
skip the need for a reauth. A user might try to change his TLS
certificates/password at the run-time and edit the wpa_supplicant.conf
for the new configs. In this case, wpa_supplicant should have a
provision to start a reauth session because the certificates are
changed. In this case user is not breaking a working config - he just
wants to use new configuration. As of now, the only way the new config
can take effect is by restarting the running wpa_supplicant. Would not
it be better, if we can have a similar mechanism with a running
wpa_supplicant?

If we need to re-run wpa_supplicant every time TLS certs are changed,
then logon/logoff options from wpa_cli is redundant. Please correct me
if I am wrong.

Thanks,
Saurav

On Fri, Oct 8, 2010 at 12:33 AM, Christ Schlacta <aarcane at gmail.com> wrote:
> ?An inability to break a working config is hardly a bug. ?PMKSA should
> never flush unless it's failed, and flushing any sooner, or forcing
> re-authentication sooner is wasteful of bandwidth and other resources.
> This should be classified as a feature, not as a bug.
>
> On 10/7/2010 11:59 AM, saurav barik wrote:
>> Yes, logoff followed by logon also skips reauth. I tried forcing a
>> reauth using eapol_sm_request_reauth() in "logon" path. Still it does
>> not reauth. I am wandering whether it should be considered as a
>> known-issue in wpa_supplicant or is this behavior acceptable. I
>> believe wpa_supplicant should reauthenticate if there is a change in
>> EAP-TLS related config. Should I flush PMKSA caching in logon path as
>> well? Is there any command-line config option(from wpa_cli) for it?
>>
>> Please advise.
>>
>> Thanks,
>> Saurav
>>
>> On Tue, Oct 5, 2010 at 11:58 PM, Jouni Malinen<j at w1.fi> ?wrote:
>>> On Tue, Oct 05, 2010 at 06:40:59PM +0530, saurav barik wrote:
>>>> Is there any way to trigger a forced reauthentication from a running
>>>> wpa_supplicant? wpa_cli config options does not have it.
>>> When using IEEE 802.1X/EAP, logoff follow by logon would do this without
>>> reassociation and reassociate will do this in all security modes
>>> (though, PMKSA caching may be used to skip EAP authentication in that
>>> case).
>>>
>>> --
>>> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
>>> _______________________________________________
>>> HostAP mailing list
>>> HostAP at lists.shmoo.com
>>> http://lists.shmoo.com/mailman/listinfo/hostap
>>>
>> _______________________________________________
>> HostAP mailing list
>> HostAP at lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap
>
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>


From saurav.barik  Thu Oct  7 12:22:24 2010
From: saurav.barik (saurav barik)
Date: Fri, 8 Oct 2010 00:52:24 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <4CAE196E.7000409@gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<4CAE196E.7000409@gmail.com>
Message-ID: <AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>

I agree - PMKSA caching is a good feature. But it should not force to
skip the need for a reauth. A user might try to change his TLS
certificates/password at the run-time and edit the wpa_supplicant.conf
for the new configs. In this case, wpa_supplicant should have a
provision to start a reauth session because the certificates are
changed. In this case user is not breaking a working config - he just
wants to use new configuration. As of now, the only way the new config
can take effect is by restarting the running wpa_supplicant. Would not
it be better, if we can have a similar mechanism with a running
wpa_supplicant?

If we need to re-run wpa_supplicant every time TLS certs are changed,
then logon/logoff options from wpa_cli is redundant. Please correct me
if I am wrong.

Thanks,
Saurav

On Fri, Oct 8, 2010 at 12:33 AM, Christ Schlacta <aarcane at gmail.com> wrote:
> ?An inability to break a working config is hardly a bug. ?PMKSA should
> never flush unless it's failed, and flushing any sooner, or forcing
> re-authentication sooner is wasteful of bandwidth and other resources.
> This should be classified as a feature, not as a bug.
>
> On 10/7/2010 11:59 AM, saurav barik wrote:
>> Yes, logoff followed by logon also skips reauth. I tried forcing a
>> reauth using eapol_sm_request_reauth() in "logon" path. Still it does
>> not reauth. I am wandering whether it should be considered as a
>> known-issue in wpa_supplicant or is this behavior acceptable. I
>> believe wpa_supplicant should reauthenticate if there is a change in
>> EAP-TLS related config. Should I flush PMKSA caching in logon path as
>> well? Is there any command-line config option(from wpa_cli) for it?
>>
>> Please advise.
>>
>> Thanks,
>> Saurav
>>
>> On Tue, Oct 5, 2010 at 11:58 PM, Jouni Malinen<j at w1.fi> ?wrote:
>>> On Tue, Oct 05, 2010 at 06:40:59PM +0530, saurav barik wrote:
>>>> Is there any way to trigger a forced reauthentication from a running
>>>> wpa_supplicant? wpa_cli config options does not have it.
>>> When using IEEE 802.1X/EAP, logoff follow by logon would do this without
>>> reassociation and reassociate will do this in all security modes
>>> (though, PMKSA caching may be used to skip EAP authentication in that
>>> case).
>>>
>>> --
>>> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
>>> _______________________________________________
>>> HostAP mailing list
>>> HostAP at lists.shmoo.com
>>> http://lists.shmoo.com/mailman/listinfo/hostap
>>>
>> _______________________________________________
>> HostAP mailing list
>> HostAP at lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap
>
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>


From saurav.barik  Thu Oct  7 12:22:24 2010
From: saurav.barik (saurav barik)
Date: Fri, 8 Oct 2010 00:52:24 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <4CAE196E.7000409@gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<4CAE196E.7000409@gmail.com>
Message-ID: <AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>

I agree - PMKSA caching is a good feature. But it should not force to
skip the need for a reauth. A user might try to change his TLS
certificates/password at the run-time and edit the wpa_supplicant.conf
for the new configs. In this case, wpa_supplicant should have a
provision to start a reauth session because the certificates are
changed. In this case user is not breaking a working config - he just
wants to use new configuration. As of now, the only way the new config
can take effect is by restarting the running wpa_supplicant. Would not
it be better, if we can have a similar mechanism with a running
wpa_supplicant?

If we need to re-run wpa_supplicant every time TLS certs are changed,
then logon/logoff options from wpa_cli is redundant. Please correct me
if I am wrong.

Thanks,
Saurav

On Fri, Oct 8, 2010 at 12:33 AM, Christ Schlacta <aarcane at gmail.com> wrote:
> ?An inability to break a working config is hardly a bug. ?PMKSA should
> never flush unless it's failed, and flushing any sooner, or forcing
> re-authentication sooner is wasteful of bandwidth and other resources.
> This should be classified as a feature, not as a bug.
>
> On 10/7/2010 11:59 AM, saurav barik wrote:
>> Yes, logoff followed by logon also skips reauth. I tried forcing a
>> reauth using eapol_sm_request_reauth() in "logon" path. Still it does
>> not reauth. I am wandering whether it should be considered as a
>> known-issue in wpa_supplicant or is this behavior acceptable. I
>> believe wpa_supplicant should reauthenticate if there is a change in
>> EAP-TLS related config. Should I flush PMKSA caching in logon path as
>> well? Is there any command-line config option(from wpa_cli) for it?
>>
>> Please advise.
>>
>> Thanks,
>> Saurav
>>
>> On Tue, Oct 5, 2010 at 11:58 PM, Jouni Malinen<j at w1.fi> ?wrote:
>>> On Tue, Oct 05, 2010 at 06:40:59PM +0530, saurav barik wrote:
>>>> Is there any way to trigger a forced reauthentication from a running
>>>> wpa_supplicant? wpa_cli config options does not have it.
>>> When using IEEE 802.1X/EAP, logoff follow by logon would do this without
>>> reassociation and reassociate will do this in all security modes
>>> (though, PMKSA caching may be used to skip EAP authentication in that
>>> case).
>>>
>>> --
>>> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
>>> _______________________________________________
>>> HostAP mailing list
>>> HostAP at lists.shmoo.com
>>> http://lists.shmoo.com/mailman/listinfo/hostap
>>>
>> _______________________________________________
>> HostAP mailing list
>> HostAP at lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap
>
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>


From aarcane  Thu Oct  7 16:41:06 2010
From: aarcane (Christ Schlacta)
Date: Thu, 7 Oct 2010 16:41:06 -0700
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<4CAE196E.7000409@gmail.com>
	<AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>
Message-ID: <1C68A848-FE0E-4288-9595-7CCCF53167CD@gmail.com>

If a cert is changed it almost always means a cert has been installed  
to the wrong place and must now be revoked. The revocation of the old  
cert will trigger a failure and a proper reauthentication.  For the  
other 1 percent or less of the time restarting the supplicant is  
sufficient.  Also, can we mov the pmksa cache onto disk to speed up  
restarting and rebooting ?

Sent from my iPhone

On Oct 7, 2010, at 12:22, saurav barik <saurav.barik at gmail.com> wrote:

> I agree - PMKSA caching is a good feature. But it should not force to
> skip the need for a reauth. A user might try to change his TLS
> certificates/password at the run-time and edit the wpa_supplicant.conf
> for the new configs. In this case, wpa_supplicant should have a
> provision to start a reauth session because the certificates are
> changed. In this case user is not breaking a working config - he just
> wants to use new configuration. As of now, the only way the new config
> can take effect is by restarting the running wpa_supplicant. Would not
> it be better, if we can have a similar mechanism with a running
> wpa_supplicant?
>
> If we need to re-run wpa_supplicant every time TLS certs are changed,
> then logon/logoff options from wpa_cli is redundant. Please correct me
> if I am wrong.
>
> Thanks,
> Saurav
>
> On Fri, Oct 8, 2010 at 12:33 AM, Christ Schlacta <aarcane at gmail.com>  
> wrote:
>>  An inability to break a working config is hardly a bug.  PMKSA  
>> should
>> never flush unless it's failed, and flushing any sooner, or forcing
>> re-authentication sooner is wasteful of bandwidth and other  
>> resources.
>> This should be classified as a feature, not as a bug.
>>
>> On 10/7/2010 11:59 AM, saurav barik wrote:
>>> Yes, logoff followed by logon also skips reauth. I tried forcing a
>>> reauth using eapol_sm_request_reauth() in "logon" path. Still it  
>>> does
>>> not reauth. I am wandering whether it should be considered as a
>>> known-issue in wpa_supplicant or is this behavior acceptable. I
>>> believe wpa_supplicant should reauthenticate if there is a change in
>>> EAP-TLS related config. Should I flush PMKSA caching in logon path  
>>> as
>>> well? Is there any command-line config option(from wpa_cli) for it?
>>>
>>> Please advise.
>>>
>>> Thanks,
>>> Saurav
>>>
>>> On Tue, Oct 5, 2010 at 11:58 PM, Jouni Malinen<j at w1.fi>  wrote:
>>>> On Tue, Oct 05, 2010 at 06:40:59PM +0530, saurav barik wrote:
>>>>> Is there any way to trigger a forced reauthentication from a  
>>>>> running
>>>>> wpa_supplicant? wpa_cli config options does not have it.
>>>> When using IEEE 802.1X/EAP, logoff follow by logon would do this  
>>>> without
>>>> reassociation and reassociate will do this in all security modes
>>>> (though, PMKSA caching may be used to skip EAP authentication in  
>>>> that
>>>> case).
>>>>
>>>> --
>>>> Jouni Malinen                                            PGP id  
>>>> EFC895FA
>>>> _______________________________________________
>>>> HostAP mailing list
>>>> HostAP at lists.shmoo.com
>>>> http://lists.shmoo.com/mailman/listinfo/hostap
>>>>
>>> _______________________________________________
>>> HostAP mailing list
>>> HostAP at lists.shmoo.com
>>> http://lists.shmoo.com/mailman/listinfo/hostap
>>
>> _______________________________________________
>> HostAP mailing list
>> HostAP at lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap
>>


From panos  Fri Oct  8 02:16:29 2010
From: panos (Panagiotis Georgopoulos)
Date: Fri, 8 Oct 2010 10:16:29 +0100
Subject: EAP-TLS - Authentication succeeds with
	in-correct	"private_key_passwd"
In-Reply-To: <AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>	<20101005123555.GB6749@jm.kir.nu>	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>	<20101005182807.GA19004@jm.kir.nu>	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>	<4CAE196E.7000409@gmail.com>
	<AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>
Message-ID: <007d01cb66c9$7db1e020$7915a060$@lancs.ac.uk>

Hello Saurav,

	Please see inile...


> I agree - PMKSA caching is a good feature. But it should not force to
> skip the need for a reauth. A user might try to change his TLS
> certificates/password at the run-time and edit the wpa_supplicant.conf
> for the new configs. In this case, wpa_supplicant should have a
> provision to start a reauth session because the certificates are
> changed. In this case user is not breaking a working config - he just
> wants to use new configuration. As of now, the only way the new config
> can take effect is by restarting the running wpa_supplicant. Would not
> it be better, if we can have a similar mechanism with a running
> wpa_supplicant?

As far as I know, you can use wpa_cli and force wpa_supplicant to read the
new configuration (that the user changed) by running 'reconfigure'. That
will read the new configuration and use the new certificates and password
(if the user changed them). I am not sure if this flushes PMKSA caching or
how it affects reauth, but it is worth a try if that is what you need.

Cheers,
Panos


> 
> If we need to re-run wpa_supplicant every time TLS certs are changed,
> then logon/logoff options from wpa_cli is redundant. Please correct me
> if I am wrong.
> 
> Thanks,
> Saurav




From wlfw  Fri Oct  8 03:50:08 2010
From: wlfw (Bjoern Czybik)
Date: Fri, 8 Oct 2010 12:50:08 +0200
Subject: Vendor specific data within a beacon frame
In-Reply-To: <1286476522.20974.27.camel@jlt3.sipsolutions.net>
References: <4CAD9368.70608@gmx.com>	
	<AANLkTimTLEShJ3HcBqHaU5U5nFq1UywczC=G7oiHx=as@mail.gmail.com>	
	<1286475342.20974.23.camel@jlt3.sipsolutions.net>	
	<AANLkTimzwhBCVKFnx1vhM4A939_kgixEpw5RLTe8JJb0@mail.gmail.com>
	<1286476522.20974.27.camel@jlt3.sipsolutions.net>
Message-ID: <4CAEF760.5040204@gmx.com>

Ok, I'm sorry I didn't epress myself well.

There is the struct 80211_gmt in the ieee80211_mgmt module in the 
ieeee80211_defs.h, but there is no field for vendor specific data (of 
course it will be set by the hostapd).

 From the hostapd the function ieee802_11_set_beacon(...) calls the 
wpa_driver_nl80211_set_beacon function in driver_nl80211.c (we are using 
the hostapd-0.7.3).
In wpa_driver_nl80211_set_beacon fct. the macro NLA_PUT and NLA_PUT_32 
is used to set the header and tail of a mgmt frame.

If I am right, I have to use the attribute NL80211_ATTR_IE to set 
information elements data with %NL80211_CMD_SET_MGMT_EXTRA_IE (in 
nl80211.h). But in the enum nl80211_commands is written:
     NL80211_CMD_SET_MGMT_EXTRA_IE /* reserved; not used */,

Does somebody knows how to fix it?

Bj?rn

On 07.10.2010 20:35, Johannes Berg wrote:
> On Thu, 2010-10-07 at 11:31 -0700, Luis R. Rodriguez wrote:
>    
>> On Thu, Oct 7, 2010 at 11:15 AM, Johannes Berg
>> <johannes at sipsolutions.net>  wrote:
>>      
>>> On Thu, 2010-10-07 at 11:11 -0700, Luis R. Rodriguez wrote:
>>>
>>> Let me quote what you wrote, but just partially:
>>>
>>>        
>>>> This can be done from userspace. This is from nl80211.h:
>>>>          
>>>        
>>>>   *      Note: This command has been removed and it is only reserved at this
>>>>   *      point to avoid re-using existing command number. The functionality this
>>>>   *      command was planned for has been provided with cleaner design with the
>>>>   *      option to specify additional IEs in NL80211_CMD_TRIGGER_SCAN,
>>>>   *      NL80211_CMD_AUTHENTICATE, NL80211_CMD_ASSOCIATE,
>>>>   *      NL80211_CMD_DEAUTHENTICATE, and NL80211_CMD_DISASSOCIATE.
>>>>          
>>> :P
>>>        
>> Yeah just noticed *after* I pasted it and sent it. Does hostapd use
>> this currently?
>>      
> No, hostapd transmits frames via injection and the data it puts into the
> beacon is conveyed with the beacon cmd -- it has never used this
> command.
>
> Really, what the OP is looking for is the annotated hostapd
> configuration file or the hostapd source code -- he should be able to
> figure that out for himself.
>
> johannes
>    



From djkurtz  Fri Oct  8 08:39:43 2010
From: djkurtz (Daniel Kurtz)
Date: Fri, 8 Oct 2010 08:39:43 -0700
Subject: [PATCH] Treat '' in SSIDs param of DBus Interface.Scan as a
	request for braodcast scan.
In-Reply-To: <AANLkTikG46ngqc5HAd9zXwTthsM6R-CVhnvESouRDBxb@mail.gmail.com>
References: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>
	<1286431591.24578.1.camel@dcbw.foobar.com>
	<AANLkTikG46ngqc5HAd9zXwTthsM6R-CVhnvESouRDBxb@mail.gmail.com>
Message-ID: <AANLkTimF-22UaXEZDKvwhkzni0WO_E3GsH=shewfo-WB@mail.gmail.com>

Dan:
To put it another way, this patch adds a feature that allows simultaneous
active scanning for both broadcast SSID, and a list of specific SSIDs.  This
is useful when searching for available networks, including some known hidden
SSIDs, that only respond to directed ProbeRequests.

Not sending an explicit SSIDs field with a Scan request is merely a shortcut
for requesting a ProbeRequests with SSID=''.  This patch allows the caller
to request this explicitly.

Blaise:
Thanks for the info.  I guess you are literally answering Dan's question:
"Does not sending any SSIDs somehow not work?"

-Dan

On Thu, Oct 7, 2010 at 9:15 AM, Blaise Gassend <blaise at willowgarage.com>wrote:

> On Wed, Oct 6, 2010 at 11:06 PM, Dan Williams <dcbw at redhat.com> wrote:
> > On Wed, 2010-10-06 at 15:46 -0700, Daniel Kurtz wrote:
> >> This patch changes wpa_supplicant policy for handling '' in SSIDs field
> of Interface.SSID DBus message.
> >> It treats '' (zero-length) SSID as a request for a broadcast scan,
> instead of ignoring it.
> >
> > Does not sending any SSIDs somehow not work?  This seems like a pretty
> > big kludge.  The behavior should be that if no SSID property is sent,
> > then no specific scan is performed.  A zero-length SSID should actually
> > be rejected with an error.
>
> If I recall, iw's scan command sends an empty SSID when no ssid is
> explicitely specified. A while ago iwlagn was not doing the broadcast
> scan if the empty ssid wasn't there. However, I believe that was a
> bug, and it has been corrected in recent versions of iwlagn.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101008/66e6c96c/attachment.htm 


From fabienx.marotte  Fri Oct  8 09:26:35 2010
From: fabienx.marotte (Fabien Marotte)
Date: Fri, 08 Oct 2010 18:26:35 +0200
Subject: P2P connect doesn't work
Message-ID: <4CAF463B.8090903@linux.intel.com>

Hi,

I put in place a setup to try to use P2P.
I have two netbooks with Atheros AR9285 wifi cards. I followed the 
instructions on wireless.kernel.org (get linux-next tree, modified ath9k 
code and get latest wpa_supplicant)

My setup is working correctly and I am able to discover P2P devices with 
p2p_find on each p2p client.

However, when I do "p2p_connect <mac adddr> pin" or even "p2p_connect 
<mac adddr> pbc", the P2P GO negotiation fails.

I sniffed the bus on a third wifi PC using wireshark, and I saw the 
following packets:

- The probe request
- The probe response
- The GO negotiation request
- The GO negotiation response

I decoded the GO negotiation response and saw that STATUS ATTRIBUTE 
contains 0x1: From the p2p spec, 0x1 is "FAILED; Information is 
currently unavailable"

After looking into the code, I saw that this packet is sent when 
p2p_device->wps_method is set to WPS_NOT_READY.

Can you tell me the correct way to connect two P2P devices together.

If the commands I send are ok, what could be the root cause of the error ?

Regards,

Fabien



From saurav.barik  Fri Oct  8 13:07:16 2010
From: saurav.barik (saurav barik)
Date: Sat, 9 Oct 2010 01:37:16 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <007d01cb66c9$7db1e020$7915a060$@lancs.ac.uk>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<4CAE196E.7000409@gmail.com>
	<AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>
	<007d01cb66c9$7db1e020$7915a060$@lancs.ac.uk>
Message-ID: <AANLkTi=cfDibdG0dwUr4TV-cf5d9hJAtAcWMH-5pQ98v@mail.gmail.com>

Thanks Panos. Reconfigure does not trigger a reauth as confirmed by
Jouni. I also tried but it did not help.

On Fri, Oct 8, 2010 at 2:46 PM, Panagiotis Georgopoulos
<panos at comp.lancs.ac.uk> wrote:
> Hello Saurav,
>
> ? ? ? ?Please see inile...
>
>
>> I agree - PMKSA caching is a good feature. But it should not force to
>> skip the need for a reauth. A user might try to change his TLS
>> certificates/password at the run-time and edit the wpa_supplicant.conf
>> for the new configs. In this case, wpa_supplicant should have a
>> provision to start a reauth session because the certificates are
>> changed. In this case user is not breaking a working config - he just
>> wants to use new configuration. As of now, the only way the new config
>> can take effect is by restarting the running wpa_supplicant. Would not
>> it be better, if we can have a similar mechanism with a running
>> wpa_supplicant?
>
> As far as I know, you can use wpa_cli and force wpa_supplicant to read the
> new configuration (that the user changed) by running 'reconfigure'. That
> will read the new configuration and use the new certificates and password
> (if the user changed them). I am not sure if this flushes PMKSA caching or
> how it affects reauth, but it is worth a try if that is what you need.
>
> Cheers,
> Panos
>
>
>>
>> If we need to re-run wpa_supplicant every time TLS certs are changed,
>> then logon/logoff options from wpa_cli is redundant. Please correct me
>> if I am wrong.
>>
>> Thanks,
>> Saurav
>
>
>


From dcbw  Fri Oct  8 14:27:54 2010
From: dcbw (Dan Williams)
Date: Fri, 08 Oct 2010 16:27:54 -0500
Subject: [PATCH] Treat '' in SSIDs param of DBus Interface.Scan as a
	request for braodcast scan.
In-Reply-To: <AANLkTimF-22UaXEZDKvwhkzni0WO_E3GsH=shewfo-WB@mail.gmail.com>
References: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>
	<1286431591.24578.1.camel@dcbw.foobar.com>
	<AANLkTikG46ngqc5HAd9zXwTthsM6R-CVhnvESouRDBxb@mail.gmail.com>
	<AANLkTimF-22UaXEZDKvwhkzni0WO_E3GsH=shewfo-WB@mail.gmail.com>
Message-ID: <1286573274.32287.5.camel@dcbw.foobar.com>

On Fri, 2010-10-08 at 08:39 -0700, Daniel Kurtz wrote:
> Dan:
> To put it another way, this patch adds a feature that allows
> simultaneous active scanning for both broadcast SSID, and a list of
> specific SSIDs.  This is useful when searching for available networks,
> including some known hidden SSIDs, that only respond to directed
> ProbeRequests.
> 
> 
> Not sending an explicit SSIDs field with a Scan request is merely a
> shortcut for requesting a ProbeRequests with SSID=''.  This patch
> allows the caller to request this explicitly.

Fair enough.

Dan

> 
> Blaise:
> Thanks for the info.  I guess you are literally answering Dan's
> question: "Does not sending any SSIDs somehow not work?"
> 
> 
> -Dan
> 
> On Thu, Oct 7, 2010 at 9:15 AM, Blaise Gassend
> <blaise at willowgarage.com> wrote:
>         On Wed, Oct 6, 2010 at 11:06 PM, Dan Williams
>         <dcbw at redhat.com> wrote:
>         
>         > On Wed, 2010-10-06 at 15:46 -0700, Daniel Kurtz wrote:
>         >> This patch changes wpa_supplicant policy for handling '' in
>         SSIDs field of Interface.SSID DBus message.
>         >> It treats '' (zero-length) SSID as a request for a
>         broadcast scan, instead of ignoring it.
>         >
>         > Does not sending any SSIDs somehow not work?  This seems
>         like a pretty
>         > big kludge.  The behavior should be that if no SSID property
>         is sent,
>         > then no specific scan is performed.  A zero-length SSID
>         should actually
>         > be rejected with an error.
>         
>         
>         If I recall, iw's scan command sends an empty SSID when no
>         ssid is
>         explicitely specified. A while ago iwlagn was not doing the
>         broadcast
>         scan if the empty ssid wasn't there. However, I believe that
>         was a
>         bug, and it has been corrected in recent versions of iwlagn.




From j  Fri Oct  8 21:39:30 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 07:39:30 +0300
Subject: P2P connect doesn't work
In-Reply-To: <4CAF463B.8090903@linux.intel.com>
References: <4CAF463B.8090903@linux.intel.com>
Message-ID: <20101009043930.GA22525@jm.kir.nu>

On Fri, Oct 08, 2010 at 06:26:35PM +0200, Fabien Marotte wrote:

> However, when I do "p2p_connect <mac adddr> pin" or even "p2p_connect 
> <mac adddr> pbc", the P2P GO negotiation fails.

> I decoded the GO negotiation response and saw that STATUS ATTRIBUTE 
> contains 0x1: From the p2p spec, 0x1 is "FAILED; Information is 
> currently unavailable"

Did you run p2p_connect command on both devices? This code 1 is expected
behavior when you have not accepted the connection on the recipient.
Once you enter matching p2p_connect on that device, the connection
should be formed (i.e., you will see another GO Negotiation going
through at that point).

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Fri Oct  8 22:49:01 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 08:49:01 +0300
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
Message-ID: <20101009054901.GB22525@jm.kir.nu>

On Fri, Oct 08, 2010 at 12:29:35AM +0530, saurav barik wrote:
> Yes, logoff followed by logon also skips reauth. I tried forcing a
> reauth using eapol_sm_request_reauth() in "logon" path. Still it does
> not reauth.

What exactly do you mean with "reauth" in this context? In my tests,
logoff followed by logon goes through EAPOL authentication and EAP
authentication. However, if fast reauthentication is enabled, EAP-TLS
may actually skip certificate-based authentication (but still, this is a
new EAP authentication).

> I am wandering whether it should be considered as a
> known-issue in wpa_supplicant or is this behavior acceptable. I
> believe wpa_supplicant should reauthenticate if there is a change in
> EAP-TLS related config. Should I flush PMKSA caching in logon path as
> well? Is there any command-line config option(from wpa_cli) for it?

It should be possible to tricker EAP reauthentication with logoff/logon,
but there is currently no way to forcefully remove PMKSA cache entries.
I don't think EAPOL logon path should do anything about PMKSA cache
entries, but it is debatable if there are some changes that should
delete a PMKSA cache entry.

In theory, PMKSA cache entry remains valid as long as the PMK is valid
(and in many cases, no explicit validity period is communicated during
full authentication). As such, even local configuration changes would
not necessarily invalidate PMKSA cache entries.

There is currently no wpa_cli command for removing a PMKSA cache entry.
Though, I would be open to adding such a comment to allow manual removal
of these entries.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Fri Oct  8 22:53:05 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 08:53:05 +0300
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <1C68A848-FE0E-4288-9595-7CCCF53167CD@gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<4CAE196E.7000409@gmail.com>
	<AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>
	<1C68A848-FE0E-4288-9595-7CCCF53167CD@gmail.com>
Message-ID: <20101009055305.GC22525@jm.kir.nu>

On Thu, Oct 07, 2010 at 04:41:06PM -0700, Christ Schlacta wrote:
> sufficient.  Also, can we mov the pmksa cache onto disk to speed up  
> restarting and rebooting ?

It would be possible to store the PMKSA cache entries to a file and read
them back whenever wpa_supplicant is started. Though, I'm not sure
whether this is sufficient enough benefit from this to justify the extra
complexity.. In most cases, I would assume that wpa_supplicant is
running constantly and rebooting is not that frequent.

-- 
Jouni Malinen                                            PGP id EFC895FA


From aarcane  Fri Oct  8 22:55:16 2010
From: aarcane (Christ Schlacta)
Date: Fri, 08 Oct 2010 22:55:16 -0700
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <20101009055305.GC22525@jm.kir.nu>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>	<20101005123555.GB6749@jm.kir.nu>	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>	<20101005182807.GA19004@jm.kir.nu>	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>	<4CAE196E.7000409@gmail.com>	<AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>	<1C68A848-FE0E-4288-9595-7CCCF53167CD@gmail.com>
	<20101009055305.GC22525@jm.kir.nu>
Message-ID: <4CB003C4.4040201@gmail.com>

  On 10/8/2010 10:53 PM, Jouni Malinen wrote:
> In most cases, I would assume that wpa_supplicant is
> running constantly and rebooting is not that frequent.
in most cases, wpa_supplicant is on a laptop, and in most cases laptops 
are shut down between uses (most people don't realize you can put them 
to sleep for fast resume, and many linux laptops you can't for some 
reason), so this assumption would be incorrect.


From j  Fri Oct  8 23:10:25 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 09:10:25 +0300
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <4CB003C4.4040201@gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<4CAE196E.7000409@gmail.com>
	<AANLkTikeRvvrwWU8M+693=Yw8RAaODa57MdffzdFJAjL@mail.gmail.com>
	<1C68A848-FE0E-4288-9595-7CCCF53167CD@gmail.com>
	<20101009055305.GC22525@jm.kir.nu> <4CB003C4.4040201@gmail.com>
Message-ID: <20101009061025.GA7997@jm.kir.nu>

On Fri, Oct 08, 2010 at 10:55:16PM -0700, Christ Schlacta wrote:
>   On 10/8/2010 10:53 PM, Jouni Malinen wrote:
> > In most cases, I would assume that wpa_supplicant is
> > running constantly and rebooting is not that frequent.
> in most cases, wpa_supplicant is on a laptop, and in most cases laptops 
> are shut down between uses (most people don't realize you can put them 
> to sleep for fast resume, and many linux laptops you can't for some 
> reason), so this assumption would be incorrect.

Well, it depends.. I don't even remember when I last rebooted by
laptop.. ;-)  If you are willing to go through the full reboot, the
extra second or two to connect is unlikely to be that large a
difference. Anyway, if someone wants to work on this, I'm willing to
accept a submission to store the PMKSA cache to a file (as an optional,
configurable feature that is disabled by default).

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sat Oct  9 06:25:11 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 16:25:11 +0300
Subject: [PATCH] Currently the DBus Interface.Scan API is
	counter-intuitive. It issues ProbeRequests when doing passive scans
	when
	channels are specified, and does not issue ProbeRequests for broadcast
	active scans.
In-Reply-To: <20101006223017.129D71323B7@visitor-1950-352d.mtv.corp.google.com>
References: <20101006223017.129D71323B7@visitor-1950-352d.mtv.corp.google.com>
Message-ID: <20101009132511.GB721@jm.kir.nu>

On Wed, Oct 06, 2010 at 03:26:52PM -0700, Daniel Kurtz wrote:
> This patch updates DBus API .Scan() logic per the test cases listed below:

Thanks! Applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sat Oct  9 06:29:55 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 16:29:55 +0300
Subject: [PATCH] Treat '' in SSIDs param of DBus Interface.Scan as a
	request for braodcast scan.
In-Reply-To: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>
References: <20101007013657.8C8741323B7@visitor-1950-352d.mtv.corp.google.com>
Message-ID: <20101009132955.GC721@jm.kir.nu>

On Wed, Oct 06, 2010 at 03:46:20PM -0700, Daniel Kurtz wrote:
> This patch changes wpa_supplicant policy for handling '' in SSIDs field of Interface.SSID DBus message.
> It treats '' (zero-length) SSID as a request for a broadcast scan, instead of ignoring it.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sat Oct  9 07:19:40 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 17:19:40 +0300
Subject: Problem authenticating WPA2 network: OpenSSL rejects certificate
In-Reply-To: <4CAC6A42.5030106@cyberwizzard.nl>
References: <4CAB1656.7040408@cyberwizzard.nl>
	<20101005123231.GA6749@jm.kir.nu>
	<4CAB257C.5050504@cyberwizzard.nl>
	<20101005183132.GB19004@jm.kir.nu>
	<4CAC6148.5070607@cyberwizzard.nl>
	<4CAC6A42.5030106@cyberwizzard.nl>
Message-ID: <20101009141940.GD721@jm.kir.nu>

On Wed, Oct 06, 2010 at 02:23:30PM +0200, Berend Dekens wrote:
>  On 06/10/10 13:45, Berend Dekens wrote:
> > I verified the certificate with openssl and rebuild openssl with every
> > option available (and ofcourse recompiled wpa_supplicant afterwards).
> > Nothing helped.

Would you be able to send me the full certificate chain that the
authentication server is advertising, i.e., radius.utwente.nl and both
of the CyberTrust CA certificates? I don't think I have access to
anything that would allow me to test that authentication server easily
(well, apart from driving somewhere that has eduroam network and trying
a random @utwente.nl user name, I guess ;-). I was unable to reproduce
this with my own test certificates that I tried to make look like the
CyberTrust chain at least as far as the root CA is concerned.

> > Since OpenSSL attempts to verify the certificate itself (which is
> > impossible as it is the root CA), it looks to me like a bug in
> > wpa_supplicant or OpenSSL. Afaik it is impossible to verify a root CA
> > certificate as there is nobody able to 'claim' the certificate as being
> > signed by them.

Well, you can verify that the root CA meets whatever criteria is placed
on CA certificates, but yes, OpenSSL should figure out that the CA cert
is the trusted one and not try to find an issuer. I do not think there
is anything in wpa_supplicant that would cause this behavior, so this
would require OpenSSL debugging with the particular certificate chain.

> I just found a solution after I found out that OpenSSL is preferred over
> GnuTLS (when available). Since OpenSSL kept throwing a tantrum, I
> decided to disable OpenSSL entirely and include GnuTLS instead.
> 
> Lo and behold: it works! So I'd say there is some serious problem in
> OpenSSL that prevents root certificates being accepted as such. Is this
> a known issue?

Interesting.. I don't know whether this is a known issue or whether it
would be even considered an issue, i.e., OpenSSL may have good reasons
to not accept that root CA certificate.. MD5 protected certificate from
1998 is not exactly what I would consider to be of that good security
nowadays.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sat Oct  9 07:31:04 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 17:31:04 +0300
Subject: [PATCH] dbus_new_handlers: Don't send NULL to
	dbus_message_new_error
In-Reply-To: <20101005203356.9DE94205A7@glenhelen.mtv.corp.google.com>
References: <20101005203356.9DE94205A7@glenhelen.mtv.corp.google.com>
Message-ID: <20101009143104.GE721@jm.kir.nu>

On Tue, Oct 05, 2010 at 12:07:23PM -0700, Paul Stewart wrote:
> The new DBus API helper function wpas_dbus_error_unknown_error
> function can be called as a result of a failure within internal
> getter calls, which will call this function with a NULL message
> parameter.  However, dbus_message_new_error looks very unkindly
> (i.e, abort()) on a NULL message, so in this case, we should not
> call it.
> 
> I've observed this course of events during a call to
> wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
> We got here through a call to fill_dict_with_properties which
> explicitly calls getters with a NULL message parameter.  Judging
> from the way it is called, this could easily occur if an AP sends
> out a malformed (or mis-received) probe response.  I usually run
> into this problem while driving through San Francisco, so I'm
> exposed to any number of base stations along this path.

Thanks! Applied (with a debug print showing that this has happened).

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sat Oct  9 07:47:11 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 17:47:11 +0300
Subject: [PATCH] Fix scan retry after a failure
In-Reply-To: <20101006124646.22215.3237.stgit@potku.valot.fi>
References: <20101006124646.22215.3237.stgit@potku.valot.fi>
Message-ID: <20101009144711.GF721@jm.kir.nu>

On Wed, Oct 06, 2010 at 03:46:46PM +0300, Kalle Valo wrote:
> With broadcom's "wl" driver the first scan always fails. (Apparently it also
> doesn't send scan results ready signals, but let's forget it for now.) With
> connman's five minute scan interval it meant that it would take five minutes
> from boot until a wireless connection was established.
> 
> The reason is that currently wpasupplicant doesn't handle scan retries
> and it goes directly to INACTIVE state:
> 
> 14:23:09 wpa_supplicant[1046]: Scan timeout - try to get results
> 14:23:09 wpa_supplicant[1046]: Failed to get scan results
> 14:23:09 wpa_supplicant[1046]: Failed to get scan results - try scanning again
> 14:23:09 wpa_supplicant[1046]: State: SCANNING -> INACTIVE
> 
> Instead of going to INACTIVE set wpa_s->scan_req to make it explicit
> that this is a requested scan and fix check in wpa_supplicant_req_new_scan().

I would be fine with this for the case where the initial scan is
failing. However, I'm not sure I would really like to see this hitting
for other possible error cases, i.e., I don't want this to have a
possibility of hitting a look where a new scan is requested one second
after failure to get scan results regardless of the current state..

> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> index 85dcfb2..16373da 100644
> --- a/wpa_supplicant/events.c
> +++ b/wpa_supplicant/events.c
> @@ -700,11 +700,12 @@ wpa_supplicant_pick_network(struct wpa_supplicant *wpa_s,
>  static void wpa_supplicant_req_new_scan(struct wpa_supplicant *wpa_s,
>  					int timeout_sec, int timeout_usec)
>  {
> -	if (!wpa_supplicant_enabled_networks(wpa_s->conf)) {
> +	if (!wpa_supplicant_enabled_networks(wpa_s->conf) &&
> +	    !wpa_s->scan_req) {

This is fine.

> @@ -893,6 +894,7 @@ static void wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s,
>  			return;
>  		wpa_printf(MSG_DEBUG, "Failed to get scan results - try "
>  			   "scanning again");
> +		wpa_s->scan_req = 2;
>  		wpa_supplicant_req_new_scan(wpa_s, 1, 0);
>  		return;
>  	}

This, I would hope to be done only if the failure happened on the
initial scan attempt and in that case, wpa_s->scan_req = 1 may be better
option here since that matches with the value used in the initial scan.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sat Oct  9 07:59:52 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 17:59:52 +0300
Subject: [RFC/PATCH] eap_peer: create a libeap library, with header
	files and pkg-config [v2]
In-Reply-To: <1286003872.2932.1.camel@localhost.localdomain>
References: <1286003872.2932.1.camel@localhost.localdomain>
Message-ID: <20101009145952.GG721@jm.kir.nu>

On Sat, Oct 02, 2010 at 12:17:52AM -0700, Inaky Perez-Gonzalez wrote:
> This adds infrastructure in src/eap_peer to make libeap.so and install
> the needed header files and pkg-config files.

How does this differ from eap_example/Makefile for building libeap.so
and why not extend that instead if you need something more? In addition,
since there already are ways of building src/{utils,crypto,tls}
libraries, I would also prefer to use those instead of adding yet another
set of Makefile rules..

> diff --git a/src/eap_peer/Makefile b/src/eap_peer/Makefile

> +# at least for now, need to include config_ssid.h and config_blob.h from
> +# wpa_supplicant directory
> +override CFLAGS += -I ../../wpa_supplicant

Uh.. For what? "make -C src/eap_peer" goes through just fine without
this.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sat Oct  9 08:10:03 2010
From: j (Jouni Malinen)
Date: Sat, 9 Oct 2010 18:10:03 +0300
Subject: Patch to split roaming out of wpa_supplicant
In-Reply-To: <AANLkTimtHVrpHNQhW=mO7mQqyNyfGpNS16OQDBxhFAe5@mail.gmail.com>
References: <AANLkTinf4Xq9UsmE7CHk1r6iRQJFt4a1cDeYQzT9T69F@mail.gmail.com>
	<201010050839.20605.holgerschurig@gmail.com>
	<AANLkTimtHVrpHNQhW=mO7mQqyNyfGpNS16OQDBxhFAe5@mail.gmail.com>
Message-ID: <20101009151003.GH721@jm.kir.nu>

On Wed, Oct 06, 2010 at 10:56:01AM -0700, Blaise Gassend wrote:
> The key question remains, however. Would the hooks that allow people
> writing their own roaming code to be notified of events that concern
> roaming be considered for inclusion, or is there no interest? If the
> answer is yes then I am willing to work to get a patch that people
> find acceptable. But if a priori the answer is no, then there is no
> point in my wasting time getting the patch into presentable form.

This is somewhat of a difficult question to answer without seeing the
patch first, so you may not get a clear yes/no answer to that before
such a patch exist.. ;-)

There has been interest in making it easier to extend wpa_supplicant
operations in this area, so I think it would be fair to say there is
some interest.

> These hooks are calls from wpa_supplicant to an external roaming code.
> They allow somebody who wants to write their own roaming code to be
> notified of events in wpa_supplicant. They are used by wpa_supplicant
> to notify the roaming code that an important event has happened.

> There are already similar hooks for the dbus API, but they don't do
> everything that is needed for an agressive roaming strategy. For
> instance, it looks like dbus is notified when a scan succeeds, but not
> when a scan fails. If you are writing an aggressive roaming strategy,
> you need to be able to trigger a scan on a few frequencies and know
> immediately if it fails so that you can potentially try some more
> frequencies. (Trying all frequencies at once might not be a good idea
> if you know that some frequencies aren't in use and don't want to wait
> 5 seconds.) As another example, there are currently many places where
> association fails but is never reported over dbus.

I cannot really say that I have taken a closer look at the hooks you are
using (is there a patch file somewhere showing those without having to
go through a svn repository of files?), but I would expect that an
easier first step in getting this included would have indeed been to
extend D-Bus or wpa_cli interface (you mentioned that in the previous
message).

-- 
Jouni Malinen                                            PGP id EFC895FA


From saurav.barik  Sat Oct  9 11:49:15 2010
From: saurav.barik (saurav barik)
Date: Sun, 10 Oct 2010 00:19:15 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <20101009054901.GB22525@jm.kir.nu>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<20101009054901.GB22525@jm.kir.nu>
Message-ID: <AANLkTin3sHEGTxX=wUSuM_Lv=hB0OPivCzgPo7m2=GT3@mail.gmail.com>

I disabled fast_reauth in my conf file(fast_reauth=0). Then I changed
wpa_supplicant conf file with wrong certificates and triggerred logoff
followed by logon from wpa_cli. Immediately I could ping the AP
successfully(with wrong certificates). So I am not too sure whether
the reauthentication really happened. I also tried doing a reassociate
after logon. But in all the cases the ping to the AP was successful
with wrong certs. If logoff/logon causes a reauth then why should the
port get enabled with wrong certs? If PMKSA does not have anything to
do with this behavior, I really don't have any issues with it. I am
just concerned about the station still able to successfully connect to
the AP (via wpa-eap) with wrong credentials.

On Sat, Oct 9, 2010 at 11:19 AM, Jouni Malinen <j at w1.fi> wrote:
> On Fri, Oct 08, 2010 at 12:29:35AM +0530, saurav barik wrote:
>> Yes, logoff followed by logon also skips reauth. I tried forcing a
>> reauth using eapol_sm_request_reauth() in "logon" path. Still it does
>> not reauth.
>
> What exactly do you mean with "reauth" in this context? In my tests,
> logoff followed by logon goes through EAPOL authentication and EAP
> authentication. However, if fast reauthentication is enabled, EAP-TLS
> may actually skip certificate-based authentication (but still, this is a
> new EAP authentication).
>
>> I am wandering whether it should be considered as a
>> known-issue in wpa_supplicant or is this behavior acceptable. I
>> believe wpa_supplicant should reauthenticate if there is a change in
>> EAP-TLS related config. Should I flush PMKSA caching in logon path as
>> well? Is there any command-line config option(from wpa_cli) for it?
>
> It should be possible to tricker EAP reauthentication with logoff/logon,
> but there is currently no way to forcefully remove PMKSA cache entries.
> I don't think EAPOL logon path should do anything about PMKSA cache
> entries, but it is debatable if there are some changes that should
> delete a PMKSA cache entry.
>
> In theory, PMKSA cache entry remains valid as long as the PMK is valid
> (and in many cases, no explicit validity period is communicated during
> full authentication). As such, even local configuration changes would
> not necessarily invalidate PMKSA cache entries.
>
> There is currently no wpa_cli command for removing a PMKSA cache entry.
> Though, I would be open to adding such a comment to allow manual removal
> of these entries.
>
> --
> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>


From alexey.klimenok  Sat Oct  9 14:23:52 2010
From: alexey.klimenok (Alexey Klimenok)
Date: Sun, 10 Oct 2010 01:23:52 +0400
Subject: can not build hostapd with nl80211 support
Message-ID: <AANLkTi=XLJcqAiUp_Y6fdB+LJWXwsifJ1-jRjHpU+4h=@mail.gmail.com>

Hi,

Im experiencing a problem with building hostapd with nl80211 support. I've
tried to build it as described here:

http://acx100.erley.org/git.html#libnl

I've got the latest versions of hostapd and libnl from git:

git://w1.fi/srv/git/hostap.git
git://git.kernel.org/pub/scm/libs/netlink/libnl.git

There are no erros when i build it without nl80211 support. Additional info:

System: CentOS 5.5 x32
Kernel: 2.6.18-194.11.3.el5

Here is a part of .config file i modified:

# Driver interface for drivers using the nl80211 kernel interface
CONFIG_DRIVER_NL80211=y
# driver_nl80211.c requires a rather new libnl (version 1.1) which may not
be
# shipped with your distribution yet. If that is the case, you need to build
# newer libnl version and point the hostapd build to use it.
LIBNL=/usr/src/libnl
CFLAGS += -I$(LIBNL)/include
LIBS += -L$(LIBNL)/lib

Here is the error im getting:

  CC  main.c
  CC  config_file.c
  CC  ../src/ap/hostapd.c
  CC  ../src/ap/wpa_auth_glue.c
  CC  ../src/ap/drv_callbacks.c
  CC  ../src/ap/ap_drv_ops.c
  CC  ../src/ap/utils.c
  CC  ../src/ap/authsrv.c
  CC  ../src/ap/ieee802_1x.c
  CC  ../src/ap/ap_config.c
  CC  ../src/ap/ieee802_11_auth.c
  CC  ../src/ap/sta_info.c
  CC  ../src/ap/wpa_auth.c
  CC  ../src/ap/tkip_countermeasures.c
  CC  ../src/ap/ap_mlme.c
  CC  ../src/ap/wpa_auth_ie.c
  CC  ../src/ap/preauth_auth.c
  CC  ../src/ap/pmksa_cache_auth.c
  CC  ../src/drivers/drivers.c
  CC  ../src/utils/eloop.c
  CC  ../src/utils/common.c
  CC  ../src/utils/wpa_debug.c
  CC  ../src/utils/wpabuf.c
  CC  ../src/utils/os_unix.c
  CC  ../src/utils/ip_addr.c
  CC  ../src/common/ieee802_11_common.c
  CC  ../src/common/wpa_common.c
  CC  ../src/eapol_auth/eapol_auth_sm.c
  CC  dump_state.c
  CC  ../src/eapol_auth/eapol_auth_dump.c
  CC  ../src/radius/radius.c
  CC  ../src/radius/radius_client.c
  CC  ../src/ap/accounting.c
  CC  ../src/ap/vlan_init.c
  CC  ctrl_iface.c
  CC  ../src/ap/ctrl_iface_ap.c
  CC  ../src/crypto/md5.c
  CC  ../src/ap/iapp.c
  CC  ../src/ap/peerkey_auth.c
  CC  ../src/drivers/driver_hostap.c
../src/drivers/driver_nl80211.c: In function send_and_recv:
../src/drivers/driver_nl80211.c:206: warning: passing argument 1 of
nl_send_auto_complete from incompatible pointer type
../src/drivers/driver_nl80211.c:221: warning: passing argument 1 of
nl_recvmsgs from incompatible pointer type
../src/drivers/driver_nl80211.c: In function family_handler:
../src/drivers/driver_nl80211.c:255: error: CTRL_ATTR_MCAST_GROUPS
undeclared (first use in this function)
../src/drivers/driver_nl80211.c:255: error: (Each undeclared identifier is
reported only once
../src/drivers/driver_nl80211.c:255: error: for each function it appears
in.)
../src/drivers/driver_nl80211.c:259: error: CTRL_ATTR_MCAST_GRP_MAX
undeclared (first use in this function)
../src/drivers/driver_nl80211.c:262: error: CTRL_ATTR_MCAST_GRP_NAME
undeclared (first use in this function)
../src/drivers/driver_nl80211.c:263: error: CTRL_ATTR_MCAST_GRP_ID
undeclared (first use in this function)
../src/drivers/driver_nl80211.c:259: warning: unused variable tb2
../src/drivers/driver_nl80211.c: In function nl_get_multicast_id:
../src/drivers/driver_nl80211.c:286: warning: passing argument 1 of
genl_ctrl_resolve from incompatible pointer type
../src/drivers/driver_nl80211.c: In function
wpa_driver_nl80211_event_receive:
../src/drivers/driver_nl80211.c:1177: warning: passing argument 1 of
nl_recvmsgs from incompatible pointer type
../src/drivers/driver_nl80211.c: In function wpa_driver_nl80211_init_nl:
../src/drivers/driver_nl80211.c:1347: warning: implicit declaration of
function nl_handle_alloc_cb
../src/drivers/driver_nl80211.c:1347: warning: assignment makes pointer from
integer without a cast
../src/drivers/driver_nl80211.c:1354: warning: assignment makes pointer from
integer without a cast
../src/drivers/driver_nl80211.c:1361: warning: passing argument 1 of
genl_connect from incompatible pointer type
../src/drivers/driver_nl80211.c:1367: warning: passing argument 1 of
genl_connect from incompatible pointer type
../src/drivers/driver_nl80211.c:1386: warning: passing argument 1 of
genl_ctrl_alloc_cache from incompatible pointer type
../src/drivers/driver_nl80211.c:1386: error: too few arguments to function
genl_ctrl_alloc_cache
../src/drivers/driver_nl80211.c:1392: warning: passing argument 1 of
genl_ctrl_alloc_cache from incompatible pointer type
../src/drivers/driver_nl80211.c:1392: error: too few arguments to function
genl_ctrl_alloc_cache
../src/drivers/driver_nl80211.c:1409: warning: passing argument 1 of
nl_socket_add_membership from incompatible pointer type
../src/drivers/driver_nl80211.c:1419: warning: passing argument 1 of
nl_socket_add_membership from incompatible pointer type
../src/drivers/driver_nl80211.c:1427: warning: passing argument 1 of
nl_socket_get_fd from incompatible pointer type
../src/drivers/driver_nl80211.c:1437: warning: implicit declaration of
function nl_handle_destroy
../src/drivers/driver_nl80211.c: In function wpa_driver_nl80211_init:
../src/drivers/driver_nl80211.c:1546: warning: passing argument 1 of
nl_socket_get_fd from incompatible pointer type
../src/drivers/driver_nl80211.c: In function wpa_driver_nl80211_deinit:
../src/drivers/driver_nl80211.c:1766: warning: passing argument 1 of
nl_socket_get_fd from incompatible pointer type
make: *** [../src/drivers/driver_nl80211.o] Error 1


Im not a programmer, so i have no ideas what causes the problem. Any
suggestions from your side will be appreciated.

Thanks in advance
-----
Alexey Klimenok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101010/d5885709/attachment.htm 


From j  Sat Oct  9 23:47:14 2010
From: j (Jouni Malinen)
Date: Sun, 10 Oct 2010 09:47:14 +0300
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <AANLkTin3sHEGTxX=wUSuM_Lv=hB0OPivCzgPo7m2=GT3@mail.gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<20101009054901.GB22525@jm.kir.nu>
	<AANLkTin3sHEGTxX=wUSuM_Lv=hB0OPivCzgPo7m2=GT3@mail.gmail.com>
Message-ID: <20101010064714.GA7107@jm.kir.nu>

On Sun, Oct 10, 2010 at 12:19:15AM +0530, saurav barik wrote:
> I disabled fast_reauth in my conf file(fast_reauth=0). Then I changed
> wpa_supplicant conf file with wrong certificates and triggerred logoff
> followed by logon from wpa_cli. Immediately I could ping the AP
> successfully(with wrong certificates). So I am not too sure whether
> the reauthentication really happened. I also tried doing a reassociate
> after logon. But in all the cases the ping to the AP was successful
> with wrong certs. If logoff/logon causes a reauth then why should the
> port get enabled with wrong certs? If PMKSA does not have anything to
> do with this behavior, I really don't have any issues with it. I am
> just concerned about the station still able to successfully connect to
> the AP (via wpa-eap) with wrong credentials.

Please take a look at wpa_supplicant debug log (run it with -dd on
command line) and see what happens between logoff and logon. Please also
keep in mind that the station may not actually have any IEEE 802.1X port
control, so this behavior may depend on the AP side only (i.e., if it
does not implement 802.1X correctly, the connection could still
continue).

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sat Oct  9 23:50:00 2010
From: j (Jouni Malinen)
Date: Sun, 10 Oct 2010 09:50:00 +0300
Subject: can not build hostapd with nl80211 support
In-Reply-To: <AANLkTi=XLJcqAiUp_Y6fdB+LJWXwsifJ1-jRjHpU+4h=@mail.gmail.com>
References: <AANLkTi=XLJcqAiUp_Y6fdB+LJWXwsifJ1-jRjHpU+4h=@mail.gmail.com>
Message-ID: <20101010065000.GB7107@jm.kir.nu>

On Sun, Oct 10, 2010 at 01:23:52AM +0400, Alexey Klimenok wrote:

> Im experiencing a problem with building hostapd with nl80211 support. I've
> tried to build it as described here:
> 
> http://acx100.erley.org/git.html#libnl
> 
> I've got the latest versions of hostapd and libnl from git:
> 
> git://w1.fi/srv/git/hostap.git
> git://git.kernel.org/pub/scm/libs/netlink/libnl.git

I would recommend using the latest libnl release 1.1 instead of a
snapshot from git. libnl is not exactly good at maintaining compatible
API in development snapshots..

-- 
Jouni Malinen                                            PGP id EFC895FA


From wpa  Sun Oct 10 03:09:36 2010
From: wpa (Berend Dekens)
Date: Sun, 10 Oct 2010 12:09:36 +0200
Subject: Problem authenticating WPA2 network: OpenSSL rejects certificate
In-Reply-To: <20101009141940.GD721@jm.kir.nu>
References: <4CAB1656.7040408@cyberwizzard.nl>
	<20101005123231.GA6749@jm.kir.nu> <4CAB257C.5050504@cyberwizzard.nl>
	<20101005183132.GB19004@jm.kir.nu> <4CAC6148.5070607@cyberwizzard.nl>
	<4CAC6A42.5030106@cyberwizzard.nl> <20101009141940.GD721@jm.kir.nu>
Message-ID: <4CB190E0.2030206@cyberwizzard.nl>

  Op 9-10-2010 16:19, Jouni Malinen schreef:
> On Wed, Oct 06, 2010 at 02:23:30PM +0200, Berend Dekens wrote:
>>   On 06/10/10 13:45, Berend Dekens wrote:
>>> I verified the certificate with openssl and rebuild openssl with every
>>> option available (and ofcourse recompiled wpa_supplicant afterwards).
>>> Nothing helped.
> Would you be able to send me the full certificate chain that the
> authentication server is advertising, i.e., radius.utwente.nl and both
> of the CyberTrust CA certificates? I don't think I have access to
> anything that would allow me to test that authentication server easily
> (well, apart from driving somewhere that has eduroam network and trying
> a random @utwente.nl user name, I guess ;-). I was unable to reproduce
> this with my own test certificates that I tried to make look like the
> CyberTrust chain at least as far as the root CA is concerned.
I don't mind but how to I get the certificates? I think they are sent to 
wpa_supplicant during the authentication, does it have a way to somehow 
store them?

Regards,
Berend Dekens


From j  Sun Oct 10 08:20:45 2010
From: j (Jouni Malinen)
Date: Sun, 10 Oct 2010 18:20:45 +0300
Subject: [PATCH 0/6] supplicant p2p updates
In-Reply-To: <1284642196-23161-1-git-send-email-johannes@sipsolutions.net>
References: <1284642196-23161-1-git-send-email-johannes@sipsolutions.net>
Message-ID: <20101010152045.GA18034@jm.kir.nu>

On Thu, Sep 16, 2010 at 03:03:10PM +0200, Johannes Berg wrote:
> This series has the following patches:
>  update nl80211_copy.h
>  driver_nl80211: use new frame registration API
>  driver_nl80211: refactor action frame TX
>  driver_nl80211: work around libnl bug
>  driver_nl80211: use nl80211 for probe req/resp
>  driver_nl80211: use p2p interface types
> 
> It updates the supplicant to use the new p2p interface
> types as well as using nl80211 for probe request and
> response frames, which will aid implementing filters
> in the kernel and removes the need for the monitor
> interface for discovery/in p2p-client mode.

Thanks! I applied all but last one. Lets have some more discussion on
the P2P iftype use before getting that change in.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sun Oct 10 08:21:57 2010
From: j (Jouni Malinen)
Date: Sun, 10 Oct 2010 18:21:57 +0300
Subject: [PATCH] driver_nl80211: support intra-BSS configuration
In-Reply-To: <1284646810-29019-1-git-send-email-johannes.berg@intel.com>
References: <1284646810-29019-1-git-send-email-johannes.berg@intel.com>
Message-ID: <20101010152157.GB18034@jm.kir.nu>

On Thu, Sep 16, 2010 at 04:20:10PM +0200, Johannes Berg wrote:
> Using the AP_ISOLATE nl80211 option, we can
> support intra-BSS distribution configuration.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From kalle.valo  Sun Oct 10 23:44:36 2010
From: kalle.valo (Kalle Valo)
Date: Mon, 11 Oct 2010 09:44:36 +0300
Subject: [PATCH] Fix scan retry after a failure
In-Reply-To: <20101009144711.GF721@jm.kir.nu> (Jouni Malinen's message of
	"Sat, 9 Oct 2010 17:47:11 +0300")
References: <20101006124646.22215.3237.stgit@potku.valot.fi>
	<20101009144711.GF721@jm.kir.nu>
Message-ID: <8739sdgre3.fsf@potku.valot.fi>

Jouni Malinen <j at w1.fi> writes:

> On Wed, Oct 06, 2010 at 03:46:46PM +0300, Kalle Valo wrote:
>> With broadcom's "wl" driver the first scan always fails. (Apparently it also
>> doesn't send scan results ready signals, but let's forget it for now.) With
>> connman's five minute scan interval it meant that it would take five minutes
>> from boot until a wireless connection was established.
>> 
>> The reason is that currently wpasupplicant doesn't handle scan retries
>> and it goes directly to INACTIVE state:
>> 
>> 14:23:09 wpa_supplicant[1046]: Scan timeout - try to get results
>> 14:23:09 wpa_supplicant[1046]: Failed to get scan results
>> 14:23:09 wpa_supplicant[1046]: Failed to get scan results - try scanning again
>> 14:23:09 wpa_supplicant[1046]: State: SCANNING -> INACTIVE
>> 
>> Instead of going to INACTIVE set wpa_s->scan_req to make it explicit
>> that this is a requested scan and fix check in wpa_supplicant_req_new_scan().
>
> I would be fine with this for the case where the initial scan is
> failing. However, I'm not sure I would really like to see this hitting
> for other possible error cases, i.e., I don't want this to have a
> possibility of hitting a look where a new scan is requested one second
> after failure to get scan results regardless of the current state..

Makes sense. I'll try to come up with something and send v2.

>> @@ -893,6 +894,7 @@ static void wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s,
>>  			return;
>>  		wpa_printf(MSG_DEBUG, "Failed to get scan results - try "
>>  			   "scanning again");
>> +		wpa_s->scan_req = 2;
>>  		wpa_supplicant_req_new_scan(wpa_s, 1, 0);
>>  		return;
>>  	}
>
> This, I would hope to be done only if the failure happened on the
> initial scan attempt and in that case, wpa_s->scan_req = 1 may be better
> option here since that matches with the value used in the initial scan.

Ok, I'll change it.

Thanks for the review.

-- 
Kalle Valo


From inaky  Mon Oct 11 10:04:36 2010
From: inaky (Inaky Perez-Gonzalez)
Date: Mon, 11 Oct 2010 10:04:36 -0700
Subject: [RFC/PATCH] eap_peer: create a libeap library, with header
	files and pkg-config [v2]
In-Reply-To: <20101009145952.GG721@jm.kir.nu>
References: <1286003872.2932.1.camel@localhost.localdomain>
	<20101009145952.GG721@jm.kir.nu>
Message-ID: <1286816676.21592.19.camel@localhost.localdomain>

Hi Jouni

On Sat, 2010-10-09 at 17:59 +0300, Jouni Malinen wrote: 
> On Sat, Oct 02, 2010 at 12:17:52AM -0700, Inaky Perez-Gonzalez wrote:
> > This adds infrastructure in src/eap_peer to make libeap.so and install
> > the needed header files and pkg-config files.
> 
> How does this differ from eap_example/Makefile for building libeap.so
> and why not extend that instead if you need something more? In addition,

Good call -- the rationale (or my excuse) behind that is that I didn't
do the initial patch. I've just nursed and cleaned it up as needed to
get it to the current shape.

So you would rather have me modify eap_example/Makefile to generate
libeap.so?

> since there already are ways of building src/{utils,crypto,tls}
> libraries, I would also prefer to use those instead of adding yet another
> set of Makefile rules..

Here is my problem with this one: they need to be built with different
flags (namely -fPIC).

I ran into two set of issues when doing this and then putting it into
different build systems (Meego's, opensuse's, etc):

- CFLAGS get overriden from the environment, Make takes those, CFLAGS
from the makefile get forgotten.

- Different arches react to CFLAGS combination for shared libraries with
different levels of happiness. Whereas x86* takes a normal .o and makes
a .so out of it (albeit non very relocatable), ARM flat out refuses to
take it (rightly so), hence the need to build the stuff for the .so with
-fPIC --

However, I didn't want to force things like wpa_supplicant, to use
libeap.so or objects built for it unless you guys agree with it. Then I
would be able to collapse all in a single compile 'loop' -- but I'd like
to also ask for your advice on how you'd rather have that done.

> > diff --git a/src/eap_peer/Makefile b/src/eap_peer/Makefile
> 
> > +# at least for now, need to include config_ssid.h and config_blob.h from
> > +# wpa_supplicant directory
> > +override CFLAGS += -I ../../wpa_supplicant
> 
> Uh.. For what? "make -C src/eap_peer" goes through just fine without
> this.

Missed clean up, thanks for the catch.




From blaise  Mon Oct 11 12:45:22 2010
From: blaise (Blaise Gassend)
Date: Mon, 11 Oct 2010 12:45:22 -0700
Subject: Patch to split roaming out of wpa_supplicant
In-Reply-To: <20101009151003.GH721@jm.kir.nu>
References: <AANLkTinf4Xq9UsmE7CHk1r6iRQJFt4a1cDeYQzT9T69F@mail.gmail.com>
	<201010050839.20605.holgerschurig@gmail.com>
	<AANLkTimtHVrpHNQhW=mO7mQqyNyfGpNS16OQDBxhFAe5@mail.gmail.com>
	<20101009151003.GH721@jm.kir.nu>
Message-ID: <AANLkTimoXX6CW4Q0=y-xs2nVdoUqnNxm5fvahA8-GQ+p@mail.gmail.com>

Hi Jouni,

Thanks for the reply.

> On Wed, Oct 06, 2010 at 10:56:01AM -0700, Blaise Gassend wrote:
>> The key question remains, however. Would the hooks that allow people
>> writing their own roaming code to be notified of events that concern
>> roaming be considered for inclusion, or is there no interest? If the
>> answer is yes then I am willing to work to get a patch that people
>> find acceptable. But if a priori the answer is no, then there is no
>> point in my wasting time getting the patch into presentable form.
>
> This is somewhat of a difficult question to answer without seeing the
> patch first, so you may not get a clear yes/no answer to that before
> such a patch exist.. ;-)

I understand. I have put together a wiki page that should give a much
more precise idea of what this patch is:
http://pr.willowgarage.com/wiki/BlaiseGassend/WpaSupplicantPatch

This is just a diff of my current tree with the upstream tree. Since
that would be pretty difficult to wade through, I have commented the
patch. I think that it should give a good feel for what I am proposing
to provide with minimal effort on my part. I'll do cleanup once I have
a better idea of whether these patches would get accepted upstream.

The best case scenario for me is of course to be able to get hooks
added upstream that will allow me to track upstream without having to
maintain a patch of my own.

> There has been interest in making it easier to extend wpa_supplicant
> operations in this area, so I think it would be fair to say there is
> some interest.

Cool, that was my hope. :)

> I cannot really say that I have taken a closer look at the hooks you are
> using (is there a patch file somewhere showing those without having to
> go through a svn repository of files?),

Now there is.

>                 but I would expect that an
> easier first step in getting this included would have indeed been to
> extend D-Bus or wpa_cli interface (you mentioned that in the previous
> message).

My suspicion is that extending D-Bus or wpa_cli would be a much more
intrusive patch, and I would be worried about breaking existing code.
Anyhow, have a look at the page I put up, and we can discuss more in
depth at that point.

Cheers,
Blaise


From proski  Mon Oct 11 15:03:10 2010
From: proski (Pavel Roskin)
Date: Mon, 11 Oct 2010 18:03:10 -0400
Subject: can not build hostapd with nl80211 support
In-Reply-To: <20101010065000.GB7107@jm.kir.nu>
References: <AANLkTi=XLJcqAiUp_Y6fdB+LJWXwsifJ1-jRjHpU+4h=@mail.gmail.com>
	<20101010065000.GB7107@jm.kir.nu>
Message-ID: <4CB3899E.3070200@gnu.org>

On 10/10/2010 02:50 AM, Jouni Malinen wrote:
> On Sun, Oct 10, 2010 at 01:23:52AM +0400, Alexey Klimenok wrote:
>
>> Im experiencing a problem with building hostapd with nl80211 support. I've
>> tried to build it as described here:
>>
>> http://acx100.erley.org/git.html#libnl
>>
>> I've got the latest versions of hostapd and libnl from git:
>>
>> git://w1.fi/srv/git/hostap.git
>> git://git.kernel.org/pub/scm/libs/netlink/libnl.git
>
> I would recommend using the latest libnl release 1.1 instead of a
> snapshot from git. libnl is not exactly good at maintaining compatible
> API in development snapshots..

I think CONFIG_LIBNL20 wasn't specified.  It needs to be specified 
manually for now.  libnl is not changing much these days.

-- 
Regards,
Pavel Roskin


From shuangfeiyu  Mon Oct 11 19:33:50 2010
From: shuangfeiyu (Jue Yang)
Date: Tue, 12 Oct 2010 02:33:50 +0000
Subject: where to download last wpa_supplicant which support p2p_connect?
Message-ID: <BAY157-w58B35CAACD486B198C5B5BAF540@phx.gbl>


Hi,
  I wonder where to get last wpa_supplicant which support p2p_connect. I download 0.7.3 but do not find p2p_connect cli or p2p protocol codes.
  Thanks.
 
Best regards,
Jeanne
 
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101012/83183866/attachment.htm 


From poonam2.gupta  Mon Oct 11 20:49:45 2010
From: poonam2.gupta (Poonam2 Gupta)
Date: Tue, 12 Oct 2010 09:19:45 +0530
Subject: Query regarding Rx Filter
Message-ID: <83384A1A88530941AE1CBE822EC86B840131DE388E@GUREXMB01.ASIAN.AD.ARICENT.COM>

Hi,

we are not able to capture management frames like authentication request/ assocation request if Rx Filter on AP interface is set to accept all Unicast/Multicast/broadcast frames/beacon frames/Probe request/

we receive all the packets if we set the rx filter to promiscuous mode. But that doesnt seem to be a nice idea.

can anyone give some pointers for the same?

Regards
Poonam

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101012/432f2f8e/attachment.htm 


From j  Mon Oct 11 23:01:47 2010
From: j (Jouni Malinen)
Date: Tue, 12 Oct 2010 09:01:47 +0300
Subject: where to download last wpa_supplicant which support p2p_connect?
In-Reply-To: <BAY157-w58B35CAACD486B198C5B5BAF540@phx.gbl>
References: <BAY157-w58B35CAACD486B198C5B5BAF540@phx.gbl>
Message-ID: <20101012060147.GA17821@jm.kir.nu>

On Tue, Oct 12, 2010 at 02:33:50AM +0000, Jue Yang wrote:

>   I wonder where to get last wpa_supplicant which support p2p_connect. I download 0.7.3 but do not find p2p_connect cli or p2p protocol codes.

P2P support is being added in the current development branch (0.8.x).
You can get it from the git repository as described here:
http://w1.fi/cvs.html

-- 
Jouni Malinen                                            PGP id EFC895FA


From igalc  Tue Oct 12 01:26:16 2010
From: igalc (Chernobelsky, Igal)
Date: Tue, 12 Oct 2010 10:26:16 +0200
Subject: Multi Role Support
Message-ID: <855422D8691CFB4E95601370ED4102C5FEC02635@dnce02.ent.ti.com>

Hi,

As per the latest version of hostap/supplicant in GIT I have a few questions regarding ability to support multiple roles by the same wpa_supplicant process: p2p device, Client, GO, legacy STA and AP.
I would like to verify with you whether my understanding is correct.
The current code includes CONFIG_P2P compilation flag which is to be defined to support p2p device, Client and Go. This flag is to be turned off to build another executable to create a supplicant for legacy STA. Additional hostapd executable is to be built to create management/authenticator process for legacy AP.

Does the project include development task to support multiple roles by single process?


Best regards
Igal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101012/8511a1cd/attachment-0001.htm 


From proski  Tue Oct 12 08:05:17 2010
From: proski (Pavel Roskin)
Date: Tue, 12 Oct 2010 11:05:17 -0400
Subject: Query regarding Rx Filter
In-Reply-To: <83384A1A88530941AE1CBE822EC86B840131DE388E@GUREXMB01.ASIAN.AD.ARICENT.COM>
References: <83384A1A88530941AE1CBE822EC86B840131DE388E@GUREXMB01.ASIAN.AD.ARICENT.COM>
Message-ID: <4CB4792D.1020807@gnu.org>

On 10/11/2010 11:49 PM, Poonam2 Gupta wrote:
> Hi,
>
> we are not able to capture management frames like authentication request/ assocation request if Rx Filter on AP interface is set to accept all Unicast/Multicast/broadcast frames/beacon frames/Probe request/
>
> we receive all the packets if we set the rx filter to promiscuous mode. But that doesnt seem to be a nice idea.

You didn't explain why.  If it's because too many packets are received, 
you can limit them to specific packets by using layer 2 multicast. 
Google for PACKET_ADD_MEMBERSHIP to see code examples.

-- 
Regards,
Pavel Roskin


From j  Tue Oct 12 10:04:55 2010
From: j (Jouni Malinen)
Date: Tue, 12 Oct 2010 20:04:55 +0300
Subject: [PATCH 0/4] Add more signal quality information in bgscan CQM
In-Reply-To: <AANLkTikjPZZd=bHLMdaz-gDnMTV43SYtru7Fbp3j9Bd1@mail.gmail.com>
References: <AANLkTikjPZZd=bHLMdaz-gDnMTV43SYtru7Fbp3j9Bd1@mail.gmail.com>
Message-ID: <20101012170455.GA19562@jm.kir.nu>

On Fri, Oct 01, 2010 at 11:13:21AM -0700, Paul Stewart wrote:
> This series has the following patches:
>   drivers: update driver.h to add signal quality elements to
> signal_change structure
>   driver_nl80211: Add new survey retrieval function to nl80211 driver,
> and add txrate to station
>   events: Add new channel condition parameters to bgscan signal change
> event handling
>   bgscan: Update all bgscan modules to accept new txrate and noise parameters

Thanks! Applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Tue Oct 12 10:14:39 2010
From: j (Jouni Malinen)
Date: Tue, 12 Oct 2010 20:14:39 +0300
Subject: IFF_RUNNING and hostapd
In-Reply-To: <AANLkTindhPCGcA8PH7GdSy2zwTvj0oD-tJewqUPvsd8F@mail.gmail.com>
References: <AANLkTindhPCGcA8PH7GdSy2zwTvj0oD-tJewqUPvsd8F@mail.gmail.com>
Message-ID: <20101012171439.GA20698@jm.kir.nu>

On Fri, Oct 01, 2010 at 03:32:42PM -0700, Dave Taht wrote:
> I recently configured an openwrt system (a nanostation M) as a pure
> router, not bridge, in AP mode.

Which driver are you using for wlan0?

> ip addr
> 
> for wlan0 shows the interface as UP, but with "NO CARRIER".

I don't see that happening in my tests with ath9k..

> It doesn't look like the hostapd I'm using sets the IFF_RUNNING bit, ever.
> 
> So I ask... at what point, and by what, and where should RUNNING be
> setup on a AP mode, purely routed, non-bridged interface?
> 
> It seems like a good idea to leave it in the NO CARRIER state until
> the first client authenticates.

hostapd does not control this and the exact behavior is likely to depend
on which driver is being used.

-- 
Jouni Malinen                                            PGP id EFC895FA


From dave.taht  Tue Oct 12 13:24:00 2010
From: dave.taht (Dave Taht)
Date: Tue, 12 Oct 2010 13:24:00 -0700
Subject: IFF_RUNNING and hostapd
In-Reply-To: <20101012171439.GA20698@jm.kir.nu>
References: <AANLkTindhPCGcA8PH7GdSy2zwTvj0oD-tJewqUPvsd8F@mail.gmail.com>
	<20101012171439.GA20698@jm.kir.nu>
Message-ID: <AANLkTikF14qsDwtQ9_2w2Erg5SB7WHoCsox6HqK_KBhu@mail.gmail.com>

On Tue, Oct 12, 2010 at 10:14 AM, Jouni Malinen <j at w1.fi> wrote:
> On Fri, Oct 01, 2010 at 03:32:42PM -0700, Dave Taht wrote:
>> I recently configured an openwrt system (a nanostation M) as a pure
>> router, not bridge, in AP mode.
>
> Which driver are you using for wlan0?

ath9k with nl80211
>
>> ip addr
>>
>> for wlan0 shows the interface as UP, but with "NO CARRIER".
>
> I don't see that happening in my tests with ath9k..

Are you using it in unbridged mode?

>
>> It doesn't look like the hostapd I'm using sets the IFF_RUNNING bit, ever.
>>
>> So I ask... at what point, and by what, and where should RUNNING be
>> setup on a AP mode, purely routed, non-bridged interface?
>>
>> It seems like a good idea to leave it in the NO CARRIER state until
>> the first client authenticates.
>
> hostapd does not control this and the exact behavior is likely to depend
> on which driver is being used.

What does? My thought was basically IFF_RUNNING should be set
somewhere between these steps on a non-bridged AP, for the first
client that comes online - and unset after the last client goes
offline.

[  223.058446] wlan0: authenticated
[  223.058485] wlan0: associate with AP 00:18:39:e7:9c:f7 (try 1)
[  223.060904] wlan0: RX AssocResp from 00:18:39:e7:9c:f7 (capab=0x411 status=0
aid=2)
[  223.060906] wlan0: associated


>
> --
> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>



-- 
Dave T?ht
CEO, Teklibre
SKYPE: davetaht
Nicaragua Tel: (int) 505-8868-4319

US Tel: 1-239-829-5608


From fabienx.marotte  Wed Oct 13 05:58:07 2010
From: fabienx.marotte (Fabien Marotte)
Date: Wed, 13 Oct 2010 14:58:07 +0200
Subject: P2P connect doesn't work
In-Reply-To: <20101009043930.GA22525@jm.kir.nu>
References: <4CAF463B.8090903@linux.intel.com>
	<20101009043930.GA22525@jm.kir.nu>
Message-ID: <4CB5ACDF.4070206@linux.intel.com>

Hi Jouni,

On 10/09/2010 06:39 AM, Jouni Malinen wrote:
> On Fri, Oct 08, 2010 at 06:26:35PM +0200, Fabien Marotte wrote:
>
>> However, when I do "p2p_connect<mac adddr>  pin" or even "p2p_connect
>> <mac adddr>  pbc", the P2P GO negotiation fails.
>
>> I decoded the GO negotiation response and saw that STATUS ATTRIBUTE
>> contains 0x1: From the p2p spec, 0x1 is "FAILED; Information is
>> currently unavailable"
>
> Did you run p2p_connect command on both devices? This code 1 is expected
> behavior when you have not accepted the connection on the recipient.
> Once you enter matching p2p_connect on that device, the connection
> should be formed (i.e., you will see another GO Negotiation going
> through at that point).
>
Ok, I tested on my setup and p2p_connect on both side works. However is 
there a way to configure wpa_supplicant in order to accept connections 
without any user interaction? For example in a context where 
wpa_supplicant is embedded in an system like a TV or a projector ?

Regards,

Fabien


From saurav.barik  Wed Oct 13 07:57:33 2010
From: saurav.barik (saurav barik)
Date: Wed, 13 Oct 2010 20:27:33 +0530
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <20101010064714.GA7107@jm.kir.nu>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<20101009054901.GB22525@jm.kir.nu>
	<AANLkTin3sHEGTxX=wUSuM_Lv=hB0OPivCzgPo7m2=GT3@mail.gmail.com>
	<20101010064714.GA7107@jm.kir.nu>
Message-ID: <AANLkTinLCdiD+Lg2tH5qRs5tzwcj96HwA=MmAC7WGigi@mail.gmail.com>

I ran wpa_supplicant with -dd option and attached is the log.
logoff/logon is trying to reauth, but couple of places I see it uses
old-successful-config-data if fast_reauth is enabled. I disabled
fast_reauth in my config but it did not help(new credentials such as
"private_key_passwd" are not validated again, as part of reauth).

On Sun, Oct 10, 2010 at 12:17 PM, Jouni Malinen <j at w1.fi> wrote:
> On Sun, Oct 10, 2010 at 12:19:15AM +0530, saurav barik wrote:
>> I disabled fast_reauth in my conf file(fast_reauth=0). Then I changed
>> wpa_supplicant conf file with wrong certificates and triggerred logoff
>> followed by logon from wpa_cli. Immediately I could ping the AP
>> successfully(with wrong certificates). So I am not too sure whether
>> the reauthentication really happened. I also tried doing a reassociate
>> after logon. But in all the cases the ping to the AP was successful
>> with wrong certs. If logoff/logon causes a reauth then why should the
>> port get enabled with wrong certs? If PMKSA does not have anything to
>> do with this behavior, I really don't have any issues with it. I am
>> just concerned about the station still able to successfully connect to
>> the AP (via wpa-eap) with wrong credentials.
>
> Please take a look at wpa_supplicant debug log (run it with -dd on
> command line) and see what happens between logoff and logon. Please also
> keep in mind that the station may not actually have any IEEE 802.1X port
> control, so this behavior may depend on the AP side only (i.e., if it
> does not implement 802.1X correctly, the connection could still
> continue).
>
> --
> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: supplicant_eap_tls.rtf
Type: application/rtf
Size: 13308 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20101013/f6901e60/attachment-0001.rtf 


From j  Wed Oct 13 11:23:32 2010
From: j (Jouni Malinen)
Date: Wed, 13 Oct 2010 21:23:32 +0300
Subject: P2P connect doesn't work
In-Reply-To: <4CB5ACDF.4070206@linux.intel.com>
References: <4CAF463B.8090903@linux.intel.com>
	<20101009043930.GA22525@jm.kir.nu>
	<4CB5ACDF.4070206@linux.intel.com>
Message-ID: <20101013182332.GC7913@jm.kir.nu>

On Wed, Oct 13, 2010 at 02:58:07PM +0200, Fabien Marotte wrote:
> Ok, I tested on my setup and p2p_connect on both side works. However is 
> there a way to configure wpa_supplicant in order to accept connections 
> without any user interaction? For example in a context where 
> wpa_supplicant is embedded in an system like a TV or a projector ?

You could do that with an external application/script that follows
events from control interface and accepts connections on behalf of the
user. I'm not sure whether it would be a good idea to enable completely
autonomous accept-all-connections, though, especially with PBC.
Displaying a PIN on TV or projector and allowing that to be used without
user interaction sounds more reasonable, though. It should be possible
to implement that with the current wpa_supplicant, but you will need to
write couple of small scripts to do that.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Wed Oct 13 11:26:45 2010
From: j (Jouni Malinen)
Date: Wed, 13 Oct 2010 21:26:45 +0300
Subject: EAP-TLS - Authentication succeeds with in-correct
	"private_key_passwd"
In-Reply-To: <AANLkTinLCdiD+Lg2tH5qRs5tzwcj96HwA=MmAC7WGigi@mail.gmail.com>
References: <AANLkTikj6r2CnDcX9m19J+UL9WdimD52fEFfC=SsgWLX@mail.gmail.com>
	<20101005123555.GB6749@jm.kir.nu>
	<AANLkTi=iRJavgBCb8X36b=EOnVstzt6ydOwbt_ND50wm@mail.gmail.com>
	<20101005182807.GA19004@jm.kir.nu>
	<AANLkTincHYe1GSyFox-Eu9=FiizesUS6S=Ky-3aFySAz@mail.gmail.com>
	<20101009054901.GB22525@jm.kir.nu>
	<AANLkTin3sHEGTxX=wUSuM_Lv=hB0OPivCzgPo7m2=GT3@mail.gmail.com>
	<20101010064714.GA7107@jm.kir.nu>
	<AANLkTinLCdiD+Lg2tH5qRs5tzwcj96HwA=MmAC7WGigi@mail.gmail.com>
Message-ID: <20101013182645.GD7913@jm.kir.nu>

On Wed, Oct 13, 2010 at 08:27:33PM +0530, saurav barik wrote:
> I ran wpa_supplicant with -dd option and attached is the log.
> logoff/logon is trying to reauth, but couple of places I see it uses
> old-successful-config-data if fast_reauth is enabled. I disabled
> fast_reauth in my config but it did not help(new credentials such as
> "private_key_passwd" are not validated again, as part of reauth).

The fast_reauth=1 case is expected behavior. fast_reauth=0 should use
new credentials, but it looks like you did not actually ask
wpa_supplicant to read the new configuration.. Just modifying
wpa_supplicant.conf is not going to change anything in the running
process without explicit request to re-read the configuration.

-- 
Jouni Malinen                                            PGP id EFC895FA


From pstew  Wed Oct 13 18:13:07 2010
From: pstew (Paul Stewart)
Date: Wed, 13 Oct 2010 18:13:07 -0700
Subject: [PATCH 0/4] Add bitrate CQM support to wpa_supplicant
Message-ID: <AANLkTimKDXhhUbbDwzEuPaw88Yy22q-DxFnegKQTMbOH@mail.gmail.com>

I've proposed a kernel change that will track the transmit rate and
report if it falls below a certain threshold.  This is a useful
indicator of the transmit-side of the connection quality (whereas RSSI
is an indicator of the receive-side connection quality).  This series
of patches adds the support in nl80211 and bgscan to accept this new
data, but doesn't add support within bgscan to actually use it just
yet.


 src/drivers/driver.h           |   21 ++++---
 src/drivers/driver_nl80211.c   |  122 ++++++++++++++++++++--------------------
 src/drivers/nl80211_copy.h     |    4 +
 wpa_supplicant/bgscan.c        |   12 ++--
 wpa_supplicant/bgscan.h        |   15 ++---
 wpa_supplicant/bgscan_learn.c  |   17 +++---
 wpa_supplicant/bgscan_simple.c |   17 +++---
 wpa_supplicant/driver_i.h      |    6 +-
 wpa_supplicant/events.c        |    6 +--
 9 files changed, 109 insertions(+), 111 deletions(-)

--
Paul


From fabienx.marotte  Thu Oct 14 00:08:55 2010
From: fabienx.marotte (Fabien Marotte)
Date: Thu, 14 Oct 2010 09:08:55 +0200
Subject: P2P connect doesn't work
In-Reply-To: <20101013182332.GC7913@jm.kir.nu>
References: <4CAF463B.8090903@linux.intel.com>	<20101009043930.GA22525@jm.kir.nu>	<4CB5ACDF.4070206@linux.intel.com>
	<20101013182332.GC7913@jm.kir.nu>
Message-ID: <4CB6AC87.4090005@linux.intel.com>

On 10/13/2010 08:23 PM, Jouni Malinen wrote:
> On Wed, Oct 13, 2010 at 02:58:07PM +0200, Fabien Marotte wrote:
>> Ok, I tested on my setup and p2p_connect on both side works. However is
>> there a way to configure wpa_supplicant in order to accept connections
>> without any user interaction? For example in a context where
>> wpa_supplicant is embedded in an system like a TV or a projector ?
>
> You could do that with an external application/script that follows
> events from control interface and accepts connections on behalf of the
> user. I'm not sure whether it would be a good idea to enable completely
> autonomous accept-all-connections, though, especially with PBC.
I agree with you for the PBC case.

> Displaying a PIN on TV or projector and allowing that to be used without
> user interaction sounds more reasonable, though. It should be possible
> to implement that with the current wpa_supplicant, but you will need to
> write couple of small scripts to do that.
For the scenario where you display the PIN on one side and enter it on 
the other side, I tested provision discovery request:

 From WPA_supplicant (let's say left side), after a successful find 
phase, I do "p2p_prov_disc <MAC addr> display". On the right side 
wpa_supplicant, I get the message DISPLAY_PIN as expected and can see 
the computed pin. On the left side, I do p2p_connect <MAC addr> PIN_CODE.

 From my understanding, this sequence should lead to a a successful GO 
negotiation since the right side has the provision information.
But I see that the right side still send 0x1 error in the GO negociation 
response. Is my understanding good according to you ?

Regards,

Fabien




From j  Thu Oct 14 01:32:24 2010
From: j (Jouni Malinen)
Date: Thu, 14 Oct 2010 11:32:24 +0300
Subject: P2P connect doesn't work
In-Reply-To: <4CB6AC87.4090005@linux.intel.com>
References: <4CAF463B.8090903@linux.intel.com>
	<20101009043930.GA22525@jm.kir.nu>
	<4CB5ACDF.4070206@linux.intel.com>
	<20101013182332.GC7913@jm.kir.nu>
	<4CB6AC87.4090005@linux.intel.com>
Message-ID: <20101014083224.GA12666@jm.kir.nu>

On Thu, Oct 14, 2010 at 09:08:55AM +0200, Fabien Marotte wrote:
>  From WPA_supplicant (let's say left side), after a successful find 
> phase, I do "p2p_prov_disc <MAC addr> display". On the right side 
> wpa_supplicant, I get the message DISPLAY_PIN as expected and can see 
> the computed pin. On the left side, I do p2p_connect <MAC addr> PIN_CODE.
> 
>  From my understanding, this sequence should lead to a a successful GO 
> negotiation since the right side has the provision information.
> But I see that the right side still send 0x1 error in the GO negociation 
> response. Is my understanding good according to you ?

There is no code in wpa_supplicant to automatically accept connections,
i.e., this is the part where you would need to have simple external
tool/script for accepting.. In other words, something will need to
convert that display PIN event into a p2p_connect command. This
particular p2p_connect command should use the "auth" parameter only to
authorize the connection, to to trigger immediate GO Negotiation (the
other end is expected to start that shortly).

-- 
Jouni Malinen                                            PGP id EFC895FA


From kalle.valo  Fri Oct 15 04:14:47 2010
From: kalle.valo (Kalle Valo)
Date: Fri, 15 Oct 2010 14:14:47 +0300
Subject: [PATCH v2] Fix scan retry after a failure
Message-ID: <20101015111447.20333.85389.stgit@potku.valot.fi>

With broadcom's "wl" driver the first scan always fails. (Apparently it also
doesn't send scan results ready signals, but let's forget it for now.) With
connman's five minute scan interval it meant that it would take five minutes
from boot until a wireless connection was established.

The reason is that currently wpasupplicant doesn't handle scan retries
and it goes directly to INACTIVE state:

14:23:09 wpa_supplicant[1046]: Scan timeout - try to get results
14:23:09 wpa_supplicant[1046]: Failed to get scan results
14:23:09 wpa_supplicant[1046]: Failed to get scan results - try scanning again
14:23:09 wpa_supplicant[1046]: State: SCANNING -> INACTIVE

Instead of going to INACTIVE set wpa_s->scan_req to make it explicit
that this is a requested scan and fix check in wpa_supplicant_req_new_scan().

This is based on Michael Terry's patch for wpasupplicant 0.6.x reported here:

http://w1.fi/bugz/show_bug.cgi?id=374
---
 wpa_supplicant/events.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
index 85dcfb2..c071d3a 100644
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -700,11 +700,12 @@ wpa_supplicant_pick_network(struct wpa_supplicant *wpa_s,
 static void wpa_supplicant_req_new_scan(struct wpa_supplicant *wpa_s,
 					int timeout_sec, int timeout_usec)
 {
-	if (!wpa_supplicant_enabled_networks(wpa_s->conf)) {
+	if (!wpa_supplicant_enabled_networks(wpa_s->conf) &&
+	    !wpa_s->scan_req) {
 		/*
-		 * No networks are enabled; short-circuit request so
-		 * we don't wait timeout seconds before transitioning
-		 * to INACTIVE state.
+		 * No networks are enabled nor explicit scan requests are
+		 * made; short-circuit request so we don't wait timeout
+		 * seconds before transitioning to INACTIVE state.
 		 */
 		wpa_supplicant_set_state(wpa_s, WPA_INACTIVE);
 		return;
@@ -891,8 +892,14 @@ static void wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s,
 	if (scan_res == NULL) {
 		if (wpa_s->conf->ap_scan == 2 || ap)
 			return;
+
+		if (wpa_s->scan_runs != 1)
+			/* only try rescan on first attempt */
+			return;
+
 		wpa_printf(MSG_DEBUG, "Failed to get scan results - try "
 			   "scanning again");
+		wpa_s->scan_req = 1;
 		wpa_supplicant_req_new_scan(wpa_s, 1, 0);
 		return;
 	}



From sergioheinzen  Fri Oct 15 06:43:59 2010
From: sergioheinzen (=?ISO-8859-1?Q?S=E9rgio_Luiz_Heinzen?=)
Date: Fri, 15 Oct 2010 10:43:59 -0300
Subject: Enabling FT-EAP
Message-ID: <AANLkTikZyAWnS5ADuFCGWL7Tx5i3BNreMfr_Os-itD4c@mail.gmail.com>

hello,

I'm working with hostapd and the 802.11r standard. I had success on making
the FT-PSK work and the Fast Transition worked well between two Station with
hostapd enabled.

But now I'm working on the FT-EAP and got no success. I wonder if someone is
working with the 802.11r too. and can help me with the FT.

my hostapd.conf is the following:

interface=wlan0
bridge=br0
driver=nl80211
ctrl_interface_group=0
ssid=teste
hw_mode=g
channel=3
auth_algs=1
ieee8021x=1
eapol_version=2
eap_message=hello
eapol_key_index_workaround=0
eap_server=1
eap_user_file=/home/heinzen/hostapd-0.7.2/hostapd/hostapd.eap_user
ca_cert=/home/heinzen/CA.pem
server_cert=/home/heinzen/server.pem
private_key=/home/heinzen/key-server.pem
private_key_passwd=almar0f4
own_ip_addr=192.168.0.3
nas_identifier=praia
auth_server_addr=192.168.0.3
auth_server_port=1812
auth_server_shared_secret=radius
radius_server_clients=/home/heinzen/hostapd-0.7.2/hostapd/hostapd.radius_clients
radius_server_auth_port=1812
wpa=3
wpa_key_mgmt=FT-EAP WPA-EAP
wpa_passphrase=almar0f4
wpa_pairwise=CCMP
rsn_pairwise=CCMP
mobility_domain=a1b2
r0_key_lifetime=100000
r1_key_holder=000102030405
reassociation_deadline=1000
r0kh=02:01:02:03:04:05 praia 000102030405060708090a0b0c0d0e0f
r1kh=00:18:e7:28:46:81 00:01:02:03:04:05 000102030405060708090a0b0c0d0e0f






Att,

S?rgio Luiz Heinzen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101015/431356e7/attachment.htm 


From sameo  Fri Oct 15 07:51:51 2010
From: sameo (Samuel Ortiz)
Date: Fri, 15 Oct 2010 16:51:51 +0200
Subject: [PATCH] wpa_supplicant: Test all compiled drivers before failing
Message-ID: <20101015145142.GB2594@sortiz-mobl>


wpa_supplicant_set_driver() is returning an error if the first driver
in the driver list is not built in. It should continue through the
driver list until it finds one that's built in.
---
 wpa_supplicant/wpa_supplicant.c |   34 ++++++++++++++++++++--------------
 1 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index 61d1c87..1f682c8 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -1696,7 +1696,7 @@ static int wpa_supplicant_set_driver(struct wpa_supplicant *wpa_s,
 {
 	int i;
 	size_t len;
-	const char *pos;
+	const char *pos, *driver = name;
 
 	if (wpa_s == NULL)
 		return -1;
@@ -1714,20 +1714,26 @@ static int wpa_supplicant_set_driver(struct wpa_supplicant *wpa_s,
 		return 0;
 	}
 
-	pos = os_strchr(name, ',');
-	if (pos)
-		len = pos - name;
-	else
-		len = os_strlen(name);
-	for (i = 0; wpa_drivers[i]; i++) {
-		if (os_strlen(wpa_drivers[i]->name) == len &&
-		    os_strncmp(name, wpa_drivers[i]->name, len) ==
-		    0) {
-			wpa_s->driver = wpa_drivers[i];
-			wpa_s->global_drv_priv = wpa_s->global->drv_priv[i];
-			return 0;
+	do {
+		pos = os_strchr(driver, ',');
+		if (pos)
+			len = pos - driver;
+		else
+			len = os_strlen(driver);
+
+		for (i = 0; wpa_drivers[i]; i++) {
+			if (os_strlen(wpa_drivers[i]->name) == len &&
+			    os_strncmp(driver, wpa_drivers[i]->name, len) ==
+			    0) {
+				wpa_s->driver = wpa_drivers[i];
+				wpa_s->global_drv_priv =
+					wpa_s->global->drv_priv[i];
+				return 0;
+			}
 		}
-	}
+
+		driver = pos + 1;
+	} while (pos);
 
 	wpa_printf(MSG_ERROR, "Unsupported driver '%s'.", name);
 	return -1;
-- 
1.7.1

-- 
Intel Open Source Technology Centre
http://oss.intel.com/


From vijayswami1  Sat Oct 16 06:05:22 2010
From: vijayswami1 (Vijay Swami)
Date: Sat, 16 Oct 2010 18:35:22 +0530
Subject: What will happen to wpa_supplicant process If i will make the WiFi
	Radio Off
Message-ID: <AANLkTin_s+kMALxPV1nR=Ri5UAPNXiAkyG+5P5SQvgTY@mail.gmail.com>

Hi,
   This is Vijay Here. I am using wpa_supplicant for WinXP and Windows
Mobile (For Windows Mobile i have ported ). I am using wpa_supplicant as a
dll. In my Application i have to make the WiFi On and OFF frequently. I am
starting the wpa_supplicant after initialization of my application. First
time it authenticates properly with Access Point. Suppose if i will make
the WiFi Off and again made it On then , Do i need to re start the
wpa_supplicant application again or wpa_supplicant instance which is already
running (Which i have started after inintialization of my application) will
work fine.
1) Once i will make WiFi On I am starting the wpa_supplicant instance. If i
will switch off the WiFi Radio then do i need to close the wpa_supplicant
applicantion?
2) When I will make WiFi Off  and again make it On then do i need to close
the existing wpa_supplicant and again start it or already running
wpa_supplicant will do the Authentication procedure?

Regards,
Vijay Swami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101016/749c7316/attachment.htm 


From vijayswami1  Sat Oct 16 07:21:49 2010
From: vijayswami1 (Vijay Swami)
Date: Sat, 16 Oct 2010 19:51:49 +0530
Subject: Basic Question
Message-ID: <AANLkTiko_-734K=bDXVBWEM=rjhSwaNzx9O=xPZYRA60@mail.gmail.com>

Hi,
   I have one very basic question. Suppose if i have connected to one Access
Point by using wpa_supplicant (EAP-TLS), is it must thing to deauthenticate
with that Access Point when i will disconnect the from Access Point. If i
will switch off the WiFI radio, then is it must thing to deauthenticate with
Access Point with which it has been connected and then Switch off the radio?

Regards,
Vijay Swami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101016/ce4a6b45/attachment.htm 


From fabienx.marotte  Mon Oct 18 05:32:22 2010
From: fabienx.marotte (Fabien Marotte)
Date: Mon, 18 Oct 2010 14:32:22 +0200
Subject: Question about P2P persistant groups
Message-ID: <4CBC3E56.5070808@linux.intel.com>

Hi,

I am now trying to test the P2P persistant group and how it is managed 
in wpa_supplicant.

I saw that the persistant group infos are not saved if I kill and 
restart wpa_supplicant. So I wonder if it's a missing feature or a 
choice to do that.

If it is a choice does it means that a higher level application should 
manage persistant group infos (eg connman or NetworkManager) ?
In that case, what is the API function to retrieve group info and set it 
again ? p2p_group_add ? (even if I don't think this is the right function)

Regards,

Fabien


From j  Mon Oct 18 08:41:36 2010
From: j (Jouni Malinen)
Date: Mon, 18 Oct 2010 18:41:36 +0300
Subject: Question about P2P persistant groups
In-Reply-To: <4CBC3E56.5070808@linux.intel.com>
References: <4CBC3E56.5070808@linux.intel.com>
Message-ID: <20101018154136.GA24953@jm.kir.nu>

On Mon, Oct 18, 2010 at 02:32:22PM +0200, Fabien Marotte wrote:
> I saw that the persistant group infos are not saved if I kill and 
> restart wpa_supplicant. So I wonder if it's a missing feature or a 
> choice to do that.

You need to enable configuration file updates for that to work (add
update_config=1).

> If it is a choice does it means that a higher level application should 
> manage persistant group infos (eg connman or NetworkManager) ?
> In that case, what is the API function to retrieve group info and set it 
> again ? p2p_group_add ? (even if I don't think this is the right function)

These are stored as network configuration blocks, but it may not be that
easy to retrieve them (or well, especially the passphrase part).

-- 
Jouni Malinen                                            PGP id EFC895FA


From dcbw  Mon Oct 18 10:00:57 2010
From: dcbw (Dan Williams)
Date: Mon, 18 Oct 2010 12:00:57 -0500
Subject: Question about P2P persistant groups
In-Reply-To: <20101018154136.GA24953@jm.kir.nu>
References: <4CBC3E56.5070808@linux.intel.com>
	<20101018154136.GA24953@jm.kir.nu>
Message-ID: <1287421257.5843.26.camel@dcbw.foobar.com>

On Mon, 2010-10-18 at 18:41 +0300, Jouni Malinen wrote:
> On Mon, Oct 18, 2010 at 02:32:22PM +0200, Fabien Marotte wrote:
> > I saw that the persistant group infos are not saved if I kill and 
> > restart wpa_supplicant. So I wonder if it's a missing feature or a 
> > choice to do that.
> 
> You need to enable configuration file updates for that to work (add
> update_config=1).
> 
> > If it is a choice does it means that a higher level application should 
> > manage persistant group infos (eg connman or NetworkManager) ?
> > In that case, what is the API function to retrieve group info and set it 
> > again ? p2p_group_add ? (even if I don't think this is the right function)
> 
> These are stored as network configuration blocks, but it may not be that
> easy to retrieve them (or well, especially the passphrase part).

Given that the higher-level manager is usually storing the connection
information elsewhere (since it needs to store IPv4, proxy, IPv6, and
other stuff in the same place as the wifi settings) it probably makes
sense to save persistent information about P2P stuff with the higher
level connection manager as well.  At least the supplicant should
provide that capability, which I'm pretty sure it already does through
the calls to get network properties.  We'd need to make sure that when
the supplicant *does* change the persistent P2P info in it's config that
it sends a signal over the D-Bus control interface or socket control
interface so that the higher levels know they need to read that info and
save it.

Dan





From plahti  Mon Oct 18 11:43:15 2010
From: plahti (Patrik Lahti)
Date: Mon, 18 Oct 2010 14:43:15 -0400
Subject: QNX / libpcap / wpa_supplicant -- packet loss
In-Reply-To: <20101001130411.GA20952@biggy>
References: <20101001130411.GA20952@biggy>
Message-ID: <4CBC9543.9060301@qnx.com>

Hi Andreas,

Indeed, you're right, the supplicant should loop calling pcap_next() and 
process all packets until NULL is returned. The packets don't get lost, 
but get severely delayed, but it isn't a QNX-specific problem. It may be 
specific to using l2_packet_freebsd.c or only cause a problem if using 
BPF to implement libpcap, but I haven't investigated.

If multiple packets are received and read() out of BPF at the same time, 
the supplicant will only get the first packet through pcap_next(). The 
other packets aren't lost, they're still in the pcap_t's buffer and will 
be read next time pcap_next() is called. I.e. next time select() 
indicates the fd is readable, the supplicant will go and call 
pcap_next() again and get an old packet already queued in the pcap_t's 
buffer but not read() more. Since nothing is read, select() will again 
say the fd is readable and again the supplicant calls pcap_next(), and 
so on until there are no more old packets and pcap_next() returns NULL, 
and then on nest invocation pcap_next() finally read()s the BPF fd 
(clearing the fd's readable condition) and getting another packet(s) 
into the pcap_t's buffer and pcap_next() then returns the first of them 
to the supplicant. If there were several packets, then the situation 
(i.e. delay) repeats.

Cheers and thanks for investigating!
/P

On 10-10-01 09:04 AM, Andreas Fenkart wrote:
> Hi
>
> I observed a problem, when bpf queues 3 packages for
> wpa_supplicant. Only the first package is received, then
> wpa_supplicant blocks in select without reading the other 2
> packages.
>
> The is what I debugged so far:
>
> wpa_supplicant io-pkt
> ------------------------------------------------------
> select:
> - - - - | -> bpf_poll
> <- - - - | - <data available
> -> pcap_next " |
> -> pcap_dispatch |
> -> pcap_read_bpf |
> - - - | -> bpf_read
> <- - - | - <pass all queued data>
>
> --> libpcap extracts 1 packet queues remaining data <--
>
> <- 1 packet
> <- 1 packet
> ..
> process packet
> ..
> do select:
> - - - - | -> bpf_poll
> <- - - - | - <no data available
> repeat
>
>
> The problem is that the data is queued in pcap, but the
> supplicant not checking this before calling 'select' again. Select
> will fail, since it checks for available data in io-pkt which in
> my case receives no more data.
>
> Any suggestions, hints and existing patches very welcome.
>
> kind regards
>
> Andreas
>
>
> ---- configuration --------------------------------------------
>
> QNX 6.4.1 / wpa_supplicant 0.6.4 / libpcap 0.9.8
>
> network={
> ssid="MotorolaWPA-EAP"
> scan_ssid=1
> # IEEE 802.1X (i.e., no WPA) with dynamic WEP keys
> key_mgmt=IEEE8021X
> eap=TTLS
> identity="xxxx"
> password="xxxx"
> priority=1
> }
>
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>


From j  Mon Oct 18 11:59:11 2010
From: j (Jouni Malinen)
Date: Mon, 18 Oct 2010 21:59:11 +0300
Subject: Question about P2P persistant groups
In-Reply-To: <1287421257.5843.26.camel@dcbw.foobar.com>
References: <4CBC3E56.5070808@linux.intel.com>
	<20101018154136.GA24953@jm.kir.nu>
	<1287421257.5843.26.camel@dcbw.foobar.com>
Message-ID: <20101018185911.GA29430@jm.kir.nu>

On Mon, Oct 18, 2010 at 12:00:57PM -0500, Dan Williams wrote:
> Given that the higher-level manager is usually storing the connection
> information elsewhere (since it needs to store IPv4, proxy, IPv6, and
> other stuff in the same place as the wifi settings) it probably makes
> sense to save persistent information about P2P stuff with the higher
> level connection manager as well.  At least the supplicant should
> provide that capability, which I'm pretty sure it already does through
> the calls to get network properties.  We'd need to make sure that when
> the supplicant *does* change the persistent P2P info in it's config that
> it sends a signal over the D-Bus control interface or socket control
> interface so that the higher levels know they need to read that info and
> save it.

I would assume everything else is already there apart from maybe not
being able to retrieve psk or the special disabled=2 value (or set
disabled=2 for that matter) to distinguish this is a persistent group.
The full data is also available through ctrl_interface now, but maybe
not with D-Bus yet (well, neither is any other P2P functionality).

-- 
Jouni Malinen                                            PGP id EFC895FA


From ben  Mon Oct 18 12:03:58 2010
From: ben (Ben Thompson)
Date: Mon, 18 Oct 2010 20:03:58 +0100
Subject: CA cert set via GUI prompt
Message-ID: <20101018190358.GA19564@thompson.org.uk>

Hello

I am interested in the possibility of creating a GUI to connect to
WPA-Enterprise wireless networks (for my freerunner phone) which is
able to prompt the user to accept a server certificate with a simple
button click. I am thinking about the kind of thing that Windows
7/Vista and Mac OS does when the user connects to a new network. I
think the process is that a box appears asking for the username and
password (anonymous ID is automatically set to the same as username)
and then a pop up box appears displaying a summary of the details on
the server certificate and has a button to stop or continue. I think
this relies on the fact that a suitable root cert is found in the
certificate store on the computer. The key thing is that the user does
not have to manually type the path to the root certificate or even
know what it is. The only text entered by the user is the username and
password.

I suppose what I would like to know is whether wpa_supplicant would be
able to interact with a GUI in such a way to provide the certificate
details presented by the RADIUS server?

Thanks in advance

Ben Thompson


From dcbw  Mon Oct 18 12:12:28 2010
From: dcbw (Dan Williams)
Date: Mon, 18 Oct 2010 14:12:28 -0500
Subject: Question about P2P persistant groups
In-Reply-To: <20101018185911.GA29430@jm.kir.nu>
References: <4CBC3E56.5070808@linux.intel.com>
	<20101018154136.GA24953@jm.kir.nu>
	<1287421257.5843.26.camel@dcbw.foobar.com>
	<20101018185911.GA29430@jm.kir.nu>
Message-ID: <1287429148.13817.0.camel@dcbw.foobar.com>

On Mon, 2010-10-18 at 21:59 +0300, Jouni Malinen wrote:
> On Mon, Oct 18, 2010 at 12:00:57PM -0500, Dan Williams wrote:
> > Given that the higher-level manager is usually storing the connection
> > information elsewhere (since it needs to store IPv4, proxy, IPv6, and
> > other stuff in the same place as the wifi settings) it probably makes
> > sense to save persistent information about P2P stuff with the higher
> > level connection manager as well.  At least the supplicant should
> > provide that capability, which I'm pretty sure it already does through
> > the calls to get network properties.  We'd need to make sure that when
> > the supplicant *does* change the persistent P2P info in it's config that
> > it sends a signal over the D-Bus control interface or socket control
> > interface so that the higher levels know they need to read that info and
> > save it.
> 
> I would assume everything else is already there apart from maybe not
> being able to retrieve psk or the special disabled=2 value (or set
> disabled=2 for that matter) to distinguish this is a persistent group.
> The full data is also available through ctrl_interface now, but maybe
> not with D-Bus yet (well, neither is any other P2P functionality).

Well, we'd need to get the agreed-upon PSK for WPS too after the initial
association, so we'll have to have this functionality somehow.  I'll
check.

Dan





From j  Mon Oct 18 12:11:41 2010
From: j (Jouni Malinen)
Date: Mon, 18 Oct 2010 22:11:41 +0300
Subject: QNX / libpcap / wpa_supplicant -- packet loss
In-Reply-To: <4CBC9543.9060301@qnx.com>
References: <20101001130411.GA20952@biggy>
 <4CBC9543.9060301@qnx.com>
Message-ID: <20101018191141.GB29430@jm.kir.nu>

On Mon, Oct 18, 2010 at 02:43:15PM -0400, Patrik Lahti wrote:
> Indeed, you're right, the supplicant should loop calling pcap_next() and 
> process all packets until NULL is returned. The packets don't get lost, 
> but get severely delayed, but it isn't a QNX-specific problem. It may be 
> specific to using l2_packet_freebsd.c or only cause a problem if using 
> BPF to implement libpcap, but I haven't investigated.

If I remember correctly, there were some issues with pcap using blocking
operations at least in some cases. Is it clear that this can be done in
non-blocking mode? At least man page for pcap_setnonblock() seems to
indicate that pcap_next() will not work in non-blocking mode.

l2_packet_winpcap.c uses a separate thread to work around related issues
(and lack of select() option for that matter) and I would expect that it
does not have this type of problem. However, I would prefer not to add a
new thread just for this.

I don't really like the pcap API for this and was very pleased to be
able to replace that with Linux packet sockets and proper wait on the
socket without having to figure out what exactly is needed with pcap to
provided packets immediately and without blocking the thread in any
case.

If someone has code that provides a non-blocking and reliable way of
getting packet out from pcap, I would like to get this fixed in
wpa_supplicant. My own interest on this is somewhat limited taking into
account the past history of having to fight with pcap and the current
situation of not having to worry about it on the main platforms I worked
with ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA


From matthias.guentert  Mon Oct 18 23:52:20 2010
From: matthias.guentert (Matthias Guentert)
Date: Tue, 19 Oct 2010 08:52:20 +0200
Subject: Advise for a small WDS
Message-ID: <AANLkTimdjgprdMzERXFLLw5mqw1Xq-Pv_PtNUt8M24EB@mail.gmail.com>

Hello list members

I would like to build a wireless network which should span over two
subnets (A: 192.168.2.0/24 and B: 192.168.1.0/24) Both subnets are
connected via one FreeBSD based (pfSense) router.

I have one linux computer within each subnet running hostapd (host_a:
192.168.2.10 and host_b: 192.168.1.10). Also there is a DHCP server
running on the FreeBSD router for subnet B and another DHCP server for
subnet A on host_a.

What set up can you recommend to have one ESSID clients can use to
connect to? Can you provide some example configurations?

TIA, Matthias


From jayant.sane  Tue Oct 19 14:35:13 2010
From: jayant.sane (Sane, Jayant)
Date: Tue, 19 Oct 2010 14:35:13 -0700
Subject: Followup q on persistent groups
Message-ID: <6D5D25EA3941074EB7734E51B16687040146A93ADE@orsmsx506.amr.corp.intel.com>

I am asking this on behalf of someone to get some feelers.

One of the primary reasons for having/creating persistent groups is the ability to create 'permanent' associations with certain peers. Question became what would be the appropriate entity/place for remembering the peers that had successfully associated with a given persistent group. A sub-question on that is whether it makes sense to have some ability so as to add some 'extra' info/fields to the network profile (corresponding to the persistent group) that will allow applications to maintain the <group, list of peers> associations. Given a peer they can then query the group(s) a given peer belonged to. And to mitigate the possibility of getting multiple groups that a peer might belong to, one possibility suggested was to also maintain an 'service' field in the group info which then allows apps to search for groups that are of interest to them. In other words the query would be for given <peer, service> find the persistent group. 

I realize this would depend on which ever entity managing the persistent groups/profiles and whether it would provide hooks for apps to attach custom info (like list of peers) to the group and be able to retrieve it later. This also raises the question of whether individual apps should own/maintain their own (persistent) groups where they can maintain any custom info with it.

Any thoughts. 

rgds, 
Jayant




From jayant.sane  Tue Oct 19 16:02:25 2010
From: jayant.sane (Sane, Jayant)
Date: Tue, 19 Oct 2010 16:02:25 -0700
Subject: Followup q on persistent groups (resend w/ better formatting)
Message-ID: <6D5D25EA3941074EB7734E51B16687040146A93C35@orsmsx506.amr.corp.intel.com>

Pardon/disregard the earlier post with screwed up line length formatting:-( 

I am asking this on behalf of someone to get some feelers.

One of the primary reasons for having/creating persistent groups is the ability to 
create 'permanent' associations with certain peers. 
Question became what would be the appropriate entity/place for remembering the peers
that had successfully associated with a given persistent group. A sub-question on 
that is whether it makes sense to have some ability so as to add some 'extra' 
info/fields to the network profile (corresponding to the persistent group) that 
will allow applications to maintain the <group, list of peers> associations. 
Given a peer they can then query the group(s) a given peer belonged to. And to 
mitigate the possibility of getting multiple groups that a peer might belong to, one 
possibility suggested was to also maintain an 'service' field in the group info 
which then allows apps to search for groups that are of interest to them. 
In other words the query would be for given <peer, service> find the persistent group. 

I realize this would depend on which ever entity managing the persistent 
groups/profiles and whether it would provide hooks for apps to attach custom info 
(like list of peers) to the group and be able to retrieve it later. This also 
raises the question of whether individual apps should own/maintain their own 
(persistent) groups where they can maintain any custom info with it.

Any thoughts. 

rgds, 
Jayant

rgds, 
Jayant




From sivasanath  Thu Oct 21 00:13:46 2010
From: sivasanath (Siva Pothireddy)
Date: Thu, 21 Oct 2010 12:43:46 +0530
Subject: Building wpa_supplicant\hostapd on to wince 6.0
Message-ID: <AANLkTi=Yx6ugR28ZjXM7U9toK1q+0HnrKD5Wi944eDd2@mail.gmail.com>

Hi All,
Anybody tried building wpa_supplicant or hostapd for Wince 6.0.
Please guide me with some links or docs on how to do that, i am
desperately in need of it

Thanks in Advance
Siva


From yogeshp  Fri Oct 22 04:49:13 2010
From: yogeshp (Yogesh Ashok Powar)
Date: Fri, 22 Oct 2010 17:19:13 +0530
Subject: [RFC] Prohibits configuring WEP when HT enabled
Message-ID: <20101022114908.GA30213@pe-lt345.marvell.com>

Keeping security policy as WEP is not allowed When 11n enabled. According to 11n
test plan version 2.0.8 (refer, test case 4.2.45). This will prevent beacons
generation with HT and WEP both enabled.

Signed-off-by: Yogesh Ashok Powar <yogeshp at marvell.com>
---
 hostapd/config_file.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/hostapd/config_file.c b/hostapd/config_file.c
index a6a3e5c..35826f3 100644
--- a/hostapd/config_file.c
+++ b/hostapd/config_file.c
@@ -1089,6 +1089,16 @@ static int hostapd_config_check_bss(struct hostapd_bss_config *bss,
 #endif /* CONFIG_IEEE80211R */
 
 #ifdef CONFIG_IEEE80211N
+	if (conf->ieee80211n && 
+		(bss->ssid.security_policy == SECURITY_STATIC_WEP)) {
+
+		wpa_printf(MSG_ERROR, "HT (IEEE 802.11n) with WEP "
+			   "does not allowed");
+		return -1;
+	}
+#endif /* CONFIG_IEEE80211N */
+
+#ifdef CONFIG_IEEE80211N
 	if (conf->ieee80211n && bss->wpa &&
 	    !(bss->wpa_pairwise & WPA_CIPHER_CCMP) &&
 	    !(bss->rsn_pairwise & WPA_CIPHER_CCMP)) {
-- 
1.5.4.3




From plahti  Fri Oct 22 07:23:34 2010
From: plahti (Patrik Lahti)
Date: Fri, 22 Oct 2010 10:23:34 -0400
Subject: QNX / libpcap / wpa_supplicant -- packet loss
In-Reply-To: <20101018191141.GB29430@jm.kir.nu>
References: <20101001130411.GA20952@biggy> <4CBC9543.9060301@qnx.com>
	<20101018191141.GB29430@jm.kir.nu>
Message-ID: <4CC19E66.3050408@qnx.com>



On 10-10-18 03:11 PM, Jouni Malinen wrote:
> On Mon, Oct 18, 2010 at 02:43:15PM -0400, Patrik Lahti wrote:
>> Indeed, you're right, the supplicant should loop calling pcap_next() and
>> process all packets until NULL is returned. The packets don't get lost,
>> but get severely delayed, but it isn't a QNX-specific problem. It may be
>> specific to using l2_packet_freebsd.c or only cause a problem if using
>> BPF to implement libpcap, but I haven't investigated.
>
> If I remember correctly, there were some issues with pcap using blocking
> operations at least in some cases. Is it clear that this can be done in
> non-blocking mode? At least man page for pcap_setnonblock() seems to
> indicate that pcap_next() will not work in non-blocking mode.

I am not aware of what the issue might have been. But when the 
supplicant has done a select() and it indicated the fd was readable, 
then the read() shouldn't block, right? (again, only looking at pcap as 
implemented by BPF here)

> l2_packet_winpcap.c uses a separate thread to work around related issues
> (and lack of select() option for that matter) and I would expect that it
> does not have this type of problem. However, I would prefer not to add a
> new thread just for this.
>
> I don't really like the pcap API for this and was very pleased to be
> able to replace that with Linux packet sockets and proper wait on the
> socket without having to figure out what exactly is needed with pcap to
> provided packets immediately and without blocking the thread in any
> case.
>
> If someone has code that provides a non-blocking and reliable way of
> getting packet out from pcap, I would like to get this fixed in
> wpa_supplicant. My own interest on this is somewhat limited taking into
> account the past history of having to fight with pcap and the current
> situation of not having to worry about it on the main platforms I worked
> with ;-).

I guess you don't mind if l2_packet_freebsd.c gets this fix then? :-) Or 
is there someone else which maintains that file?

Cheers!
/P


From igalc  Fri Oct 22 09:55:10 2010
From: igalc (Chernobelsky, Igal)
Date: Fri, 22 Oct 2010 18:55:10 +0200
Subject: WPS2 Certification
Message-ID: <855422D8691CFB4E95601370ED4102C5FEB7B900@dnce02.ent.ti.com>

Hi,

I would like to ask a question regarding WPS2 support in the latest hostap version.
Does WPS2 support (CONFIG_WPS2) complies to WPS2 certification?

Best regards.
Igal


From j  Fri Oct 22 10:45:13 2010
From: j (Jouni Malinen)
Date: Fri, 22 Oct 2010 20:45:13 +0300
Subject: WPS2 Certification
In-Reply-To: <855422D8691CFB4E95601370ED4102C5FEB7B900@dnce02.ent.ti.com>
References: <855422D8691CFB4E95601370ED4102C5FEB7B900@dnce02.ent.ti.com>
Message-ID: <20101022174513.GA9011@jm.kir.nu>

On Fri, Oct 22, 2010 at 06:55:10PM +0200, Chernobelsky, Igal wrote:

> I would like to ask a question regarding WPS2 support in the latest hostap version.
> Does WPS2 support (CONFIG_WPS2) complies to WPS2 certification?

Which certification are you referring to? I'm not aware of any such
certification being available at this point, so your question may be a
bit premature. The WSC 2.0 implementation in hostap.git should be
compliant with the latest available WSC 2.0 draft.

-- 
Jouni Malinen                                            PGP id EFC895FA


From mike4658  Fri Oct 22 11:36:28 2010
From: mike4658 (mike4658 at freenet.de)
Date: Fri, 22 Oct 2010 20:36:28 +0200
Subject: How to log what's happening during 802.1X EAP-TTLS authentification?
Message-ID: <1af92a0ac20b38b34172c3513dd1ee71@email.freenet.de>

Hello,

I get this messages while connecting to an AP with wpa_supplicant:

CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
CTRL-EVENT-EAP-FAILURE EAP authentication failed
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
How can I get a detailed log of what's happening during the EAP-TTLS authentification?
What exactly fails?

I copied the wpa_supplicant configuration file from my ISP.
My hardware is a Linksys WRT54GL router with OpenWRT kamikaze 8.09 RC1 (brcm47xx) installed.


Is openssl needed for an EAP-TTLS authentification with wpa_supplicant?

I hope, somebody can help me.
Thank you in advance.


Mike





FreeLotto - das kostenlose Lotto von freenet!
Jeden Tag die Chance auf 2 Millionen Euro nutzen.
Jetzt gratis Lotto spielen auf http://freelotto.freenet.de!



From j  Fri Oct 22 11:49:38 2010
From: j (Jouni Malinen)
Date: Fri, 22 Oct 2010 21:49:38 +0300
Subject: How to log what's happening during 802.1X EAP-TTLS
	authentification?
In-Reply-To: <1af92a0ac20b38b34172c3513dd1ee71@email.freenet.de>
References: <1af92a0ac20b38b34172c3513dd1ee71@email.freenet.de>
Message-ID: <20101022184938.GA10414@jm.kir.nu>

On Fri, Oct 22, 2010 at 08:36:28PM +0200, mike4658 at freenet.de wrote:
> I get this messages while connecting to an AP with wpa_supplicant:
> 
> CTRL-EVENT-EAP-STARTED EAP authentication started
> CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
> CTRL-EVENT-EAP-FAILURE EAP authentication failed
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> How can I get a detailed log of what's happening during the EAP-TTLS authentification?

You can add -dd on the command like for wpa_supplicant to get detailed
debug output and optionally add -K if you are fine with including
potentially private information likes keys in the output.

> Is openssl needed for an EAP-TTLS authentification with wpa_supplicant?

No, but a TLS library is (i.e., OpenSSL, GnuTLS, or the internal TLS
implementation in wpa_supplicant, etc.).

-- 
Jouni Malinen                                            PGP id EFC895FA


From clopez  Sat Oct 23 13:36:00 2010
From: clopez (Carlos Alberto Lopez Perez)
Date: Sat, 23 Oct 2010 22:36:00 +0200
Subject: How to log what's happening during 802.1X EAP-TTLS
	authentification?
In-Reply-To: <1af92a0ac20b38b34172c3513dd1ee71@email.freenet.de>
References: <1af92a0ac20b38b34172c3513dd1ee71@email.freenet.de>
Message-ID: <4CC34730.5000607@igalia.com>

I think that you will get better debug information if you look at the
radius server.

Stop the radius server and relaunch it the console with debug options:

radiusd -sfxx

On 10/22/2010 08:36 PM, mike4658 at freenet.de wrote:
> Hello,
> 
> I get this messages while connecting to an AP with wpa_supplicant:
> 
> CTRL-EVENT-EAP-STARTED EAP authentication started
> CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
> CTRL-EVENT-EAP-FAILURE EAP authentication failed
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> How can I get a detailed log of what's happening during the EAP-TTLS authentification?
> What exactly fails?
> 
> I copied the wpa_supplicant configuration file from my ISP.
> My hardware is a Linksys WRT54GL router with OpenWRT kamikaze 8.09 RC1 (brcm47xx) installed.
> 
> 
> Is openssl needed for an EAP-TTLS authentification with wpa_supplicant?
> 
> I hope, somebody can help me.
> Thank you in advance.
> 
> 
> Mike
> 
> 
> 
> 
> 
> FreeLotto - das kostenlose Lotto von freenet!
> Jeden Tag die Chance auf 2 Millionen Euro nutzen.
> Jetzt gratis Lotto spielen auf http://freelotto.freenet.de!
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20101023/d6286d4c/attachment.pgp 


From sivasanath  Sun Oct 24 23:57:38 2010
From: sivasanath (Siva Pothireddy)
Date: Mon, 25 Oct 2010 12:27:38 +0530
Subject: wpa_supplicant or hostapd for Wince 6.0
Message-ID: <AANLkTikpLN0n8NRWHBZPrgJ3oUv_Mb8wM3SKmiR4uNDj@mail.gmail.com>

Hi All,
Anybody tried building wpa_supplicant or hostapd for Wince 6.0.
Please guide me with some links or docs on how to do that, i am
desperately in need of it

Thanks in Advance
Siva


From mike4658  Mon Oct 25 04:19:36 2010
From: mike4658 (mike4658 at freenet.de)
Date: Mon, 25 Oct 2010 13:19:36 +0200
Subject: How to log what's happening during 802.1X EAP-TTLS
	authentification?
Message-ID: <ebb1dc839d4710f6d66a425f01e4d932@email.freenet.de>

        Hello,

here is the end of the log file (I logged with the option "-d"):

X509: Did not find any of the issuers from the list of trusted certificates
TLSv1: Server certificate chain validation failed (reason=6)
TLSv1: Send 
SSL: 7 bytes left to be sent out (of total 7 bytes)
EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL
EAP: EAP entering state SEND_RESPONSE
EAP: EAP entering state IDLE
EAPOL: SUPP_BE entering state RESPONSE
EAPOL: txSuppRsp
TX EAPOL: dst=00:12:da:9e:60:00
EAPOL: SUPP_BE entering state RECEIVE
EAPOL: startWhen --> 0
RX EAPOL from 00:12:da:9e:60:00
EAPOL: Received EAP-Packet frame
EAPOL: SUPP_BE entering state REQUEST
EAPOL: getSuppRsp
EAP: EAP entering state RECEIVED
EAP: Received EAP-Failure
EAP: EAP entering state FAILURE
CTRL-EVENT-EAP-FAILURE EAP authentication failed
EAPOL: SUPP_PAE entering state HELD
EAPOL: SUPP_BE entering state RECEIVE
EAPOL: SUPP_BE entering state FAIL
EAPOL: SUPP_BE entering state IDLE
EAPOL authentication completed unsuccessfully
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:00:00:00:00:00
Setting scan request: 0 sec 100000 usec
Added BSSID 00:12:da:9e:60:00 into blacklist
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys

What does this
"X509: Did not find any of the issuers from the list of trusted certificates
TLSv1: Server certificate chain validation failed (reason=6)"
mean?

Thanks in advance,

Mike


> > I get this messages while connecting to an AP with wpa_supplicant:
> >
> > CTRL-EVENT-EAP-STARTED EAP authentication started
> > CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
> > CTRL-EVENT-EAP-FAILURE EAP authentication failed
> > CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> > How can I get a detailed log of what's happening during the
> EAP-TTLS authentification?
> 
> You can add -dd on the command like for wpa_supplicant to get
> detailed
> debug output and optionally add -K if you are fine with including
> potentially private information likes keys in the output.
> 
> > Is openssl needed for an EAP-TTLS authentification with
> wpa_supplicant?
> 
> No, but a TLS library is (i.e., OpenSSL, GnuTLS, or the internal TLS
> implementation in wpa_supplicant, etc.).




FreeLotto - das kostenlose Lotto von freenet!
Jeden Tag die Chance auf 2 Millionen Euro nutzen.
Jetzt gratis Lotto spielen auf http://freelotto.freenet.de!



From queenie245  Mon Oct 25 04:57:03 2010
From: queenie245 (Queenie de Melo)
Date: Mon, 25 Oct 2010 17:27:03 +0530
Subject: madwifi n hostapd
Message-ID: <AANLkTi=1Yqp-KnMcNK1bWiZZBHtqQk9VuvuRJ2=F=P9d@mail.gmail.com>

Dear All,

Iam a bit confused,
Is 802.11r  (fast BSS transition) a driver capability or a capability of the
hostapd ??

if it is a driver capability, Does ath9k and ath5k support 802.11r??
how do i verify this??

google search shows me that mac80211 supports 802.11r so can i assume that
ath5k and ath9k have this feature and that it is a driver feature??
then what is the roll of hostapd in 802.11r, is it the same roll as in
802.1x??
hostapd mentions 802.11r capability so iam confused,

please help!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101025/b6e78a21/attachment.htm 


From j  Mon Oct 25 08:53:44 2010
From: j (Jouni Malinen)
Date: Mon, 25 Oct 2010 18:53:44 +0300
Subject: madwifi n hostapd
In-Reply-To: <AANLkTi=1Yqp-KnMcNK1bWiZZBHtqQk9VuvuRJ2=F=P9d@mail.gmail.com>
References: <AANLkTi=1Yqp-KnMcNK1bWiZZBHtqQk9VuvuRJ2=F=P9d@mail.gmail.com>
Message-ID: <20101025155344.GA10712@jm.kir.nu>

On Mon, Oct 25, 2010 at 05:27:03PM +0530, Queenie de Melo wrote:

> Is 802.11r  (fast BSS transition) a driver capability or a capability of the
> hostapd ??

Mostly hostapd, but the driver will need to support Action frame
transmission for some parts of the functionality.

> if it is a driver capability, Does ath9k and ath5k support 802.11r??

ath9k supports 802.11r (and most likely ath5k, too, but I have not
tested it myself).

-- 
Jouni Malinen                                            PGP id EFC895FA


From hostapd.list  Mon Oct 25 11:40:56 2010
From: hostapd.list (David Sommerseth)
Date: Mon, 25 Oct 2010 20:40:56 +0200
Subject: IFF_RUNNING and hostapd
Message-ID: <4CC5CF38.3060805@topphemmelig.net>

On -10/01/37 20:59, Dave Taht wrote:
> I recently configured an openwrt system (a nanostation M) as a pure
> router, not bridge, in AP mode.
> 
> Neither babeld (with link detection enabled) and radvd work
> (preventing ipv6 from working entirely)
> 
> ip addr
> 
> for wlan0 shows the interface as UP, but with "NO CARRIER".
> 
> In poking through the iproute2 code, it showed that the UP bit being
> set on the interface and the IFF_RUNNING bit not being set = "NO
> CARRIER".
> 
> It doesn't look like the hostapd I'm using sets the IFF_RUNNING bit, ever.
> 
> 
[...snip...]

I have discovered exactly the very same, also using OpenWRT on a TP-Link
TP-WR1043ND (v1.7).  I discovered this when trying to setup radvd.
Others have reported this in this Trac ticket on OpenWRT:

<https://dev.openwrt.org/ticket/7734#comment:7>

root at router:~# ip link show wlan0
20: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
mq state DORMANT qlen 1000
    link/ether 8f:f2:13:9a:7a:15 brd ff:ff:ff:ff:ff:ff
root at router:~#

I'm also using ath9k and the nl80211 driver.

This is still the case even after having connected clients to the
wireless router, authenticated successfully etc, etc.  But radvd
declines to start because the interface is dormant (not in IFF_RUNNING
state).

I've tried both bridged (by adding 'option type bridge' in the openwrt
network config, which does setup the bridge properly, configuring
hostapd and radvd accordingly and correct) and non-bridged setup.

In non-bridged setup radvd does not start up at all.  In bridged mode
radvd starts up, but it prints regularly messages like the one below:

Oct 25 20:32:37 router daemon.warn radvd[4141]: sendmsg: Operation not
permitted

In bridge mode, the br-wifi bridge is in RUNNING mode, while the wlan0
device is still in a dormant state.

> It seems like a good idea to leave it in the NO CARRIER state until
> the first client authenticates.

I do disagree with this, because that will not make it possible to start
radvd before at least one client has connected and the state has
changed.  And what when the last client disconnects, should it go back
to NO-CARRIER (dormant state)?

I believe the state should be RUNNING as soon as the device is
configured and can be used, like when hostapd has configured the device
and is ready to process requests.  NO-CARRIER basically should mean that
the device is not ready to do TX/RX.  While being configured, it is
ready to do so.

[...snip...]


Kind regards,

David Sommerseth


From dave.taht  Mon Oct 25 12:07:14 2010
From: dave.taht (Dave Taht)
Date: Mon, 25 Oct 2010 12:07:14 -0700
Subject: IFF_RUNNING and hostapd
In-Reply-To: <4CC5CF38.3060805@topphemmelig.net>
References: <4CC5CF38.3060805@topphemmelig.net>
Message-ID: <AANLkTi=0USXu4MG6omDb+2RavkiH-WDQQ48LrWj+jT2K@mail.gmail.com>

On Mon, Oct 25, 2010 at 11:40 AM, David Sommerseth
<hostapd.list at topphemmelig.net> wrote:
> On -10/01/37 20:59, Dave Taht wrote:

> Others have reported this in this Trac ticket on OpenWRT:
>
> <https://dev.openwrt.org/ticket/7734#comment:7>

I'm glad I wasn't alone in noticing this.

[snip]

>> It seems like a good idea to leave it in the NO CARRIER state until
>> the first client authenticates.
>
> I do disagree with this, because that will not make it possible to start
> radvd before at least one client has connected and the state has
> changed. ?And what when the last client disconnects, should it go back
> to NO-CARRIER (dormant state)?

I am under the impression that radvd will start when an interface is
disabled if configured to do so. I do not know how or if it monitors
changes in state in an interface.

The advantage to my thinking is that routes from elsewhere to the
wireless lan would not be offered via radvd (or babeld) until after
something is actually up, and that routes would be withdrawn soon
after the last device disconnects. This would cut down unnecessary
traffic to the wireless router in question.

I'm easy, what you propose below would be better than the current
situation by a lot.

>
> I believe the state should be RUNNING as soon as the device is
> configured and can be used, like when hostapd has configured the device
> and is ready to process requests. ?NO-CARRIER basically should mean that
> the device is not ready to do TX/RX. ?While being configured, it is
> ready to do so.
>
> [...snip...]
>
>
> Kind regards,
>
> David Sommerseth
>



-- 
Dave T?ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com


From blaise  Mon Oct 25 13:19:42 2010
From: blaise (Blaise Gassend)
Date: Mon, 25 Oct 2010 13:19:42 -0700
Subject: RFC: Patch allowing associate immediately following unassociate in
	SME mode.
Message-ID: <AANLkTinWcYX98gEO0em5TU9xnwPaw0Y15j5eB98pGVxW@mail.gmail.com>

Hi,

When I try to do a wpa_supplicant_disassociate immediately followed by
a wpa_supplicant_associate, I get a lot of association failures due to
disassociation or disauthentication messges for the previous
association killing the new association. The following patch appears
to fix the problem by ignoring events that do not relate to the
association that is currently in progres (at least for non-encrypted
connections). However, it prevents wpa_supplicant_event_disassoc from
being called, which could lead to problems that I am not anticipating
at the bottom of the EVENT_DEAUTH case. Anybody know what kind of
trouble I might be running into by preventing the cleanup that would
take place in wpa_supplicant_event_disassoc from happening?

Thanks,
Blaise

Note: This is against a modified 0.7.2 tree, so it might not be
entirely up to date. This fix isn't in there yet.

Index: wpa_supplicant/wpa_supplicant/events.c
===================================================================
--- wpa_supplicant/wpa_supplicant/events.c      (revision 33141)
+++ wpa_supplicant/wpa_supplicant/events.c      (working copy)
@@ -1598,6 +1601,7 @@
 {
        struct wpa_supplicant *wpa_s = ctx;
        u16 reason_code = 0;
+        struct u8 *event_bssid;

        switch (event) {
        case EVENT_AUTH:
@@ -1615,17 +1619,23 @@
                        break;
                }
 #endif /* CONFIG_AP */
-               if (data)
-                       reason_code = data->deauth_info.reason_code;
+               if (data) {
+                  reason_code = data->disassoc_info.reason_code;
+                  event_bssid = data->disassoc_info.addr;
+                }
                if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME)
                        sme_event_disassoc(wpa_s, data);
                /* fall through */
        case EVENT_DEAUTH:
                if (event == EVENT_DEAUTH) {
                        wpa_printf(MSG_DEBUG, "Deauthentication notification");
-                       if (data)
+                       if (data) {
                                reason_code = data->deauth_info.reason_code;
+                                event_bssid = data->deauth_info.addr;
+                        }
                }
+                if (wpa_s->current_bss && event_bssid &&
os_memcmp(wpa_s->current
_bss->bssid, event_bssid, ETH_ALEN))
+                  break; // A new association is in progress. This
event refers t
o an old association.
 #ifdef CONFIG_AP
                if (wpa_s->ap_iface && data) {
                        hostapd_notif_disassoc(wpa_s->ap_iface->bss[0],


From hostapd.list  Mon Oct 25 16:11:10 2010
From: hostapd.list (David Sommerseth)
Date: Tue, 26 Oct 2010 01:11:10 +0200
Subject: IFF_RUNNING and hostapd
In-Reply-To: <AANLkTi=0USXu4MG6omDb+2RavkiH-WDQQ48LrWj+jT2K@mail.gmail.com>
References: <4CC5CF38.3060805@topphemmelig.net>
	<AANLkTi=0USXu4MG6omDb+2RavkiH-WDQQ48LrWj+jT2K@mail.gmail.com>
Message-ID: <4CC60E8E.8060003@topphemmelig.net>

On 25/10/10 21:07, Dave Taht wrote:
> On Mon, Oct 25, 2010 at 11:40 AM, David Sommerseth
>>> It seems like a good idea to leave it in the NO CARRIER state until
>>> the first client authenticates.
>>
>> I do disagree with this, because that will not make it possible to start
>> radvd before at least one client has connected and the state has
>> changed.  And what when the last client disconnects, should it go back
>> to NO-CARRIER (dormant state)?
> 
> I am under the impression that radvd will start when an interface is
> disabled if configured to do so. I do not know how or if it monitors
> changes in state in an interface.

I haven't studied all the details of radvd configuration possibilities,
so I might have overseen some details.  I am not completely sure how the
IgnoreIfMissing {on,off} configuration option will work in reality.  But
that will still not solve the case, even if radvd starts.  As it will
not broadcast stateless IPv6 configurations, due to it will lack the
permissions of doing so when the interface is not in a RUNNING state.

> The advantage to my thinking is that routes from elsewhere to the
> wireless lan would not be offered via radvd (or babeld) until after
> something is actually up, and that routes would be withdrawn soon
> after the last device disconnects. This would cut down unnecessary
> traffic to the wireless router in question.

That is true, but I'm not sure that is the core idea behind the
IFF_RUNNING state.

--linux-2.6.32.16/Documentation/networking/operstates.txt-------------

__LINK_STATE_DORMANT, maps to IFF_DORMANT:

Set by the driver to express that the device cannot yet be used
because some driver controlled protocol establishment has to
complete. Corresponding functions are netif_dormant_on() to set the
flag, netif_dormant_off() to clear it and netif_dormant() to query.

On device allocation, networking core sets the flags equivalent to
netif_carrier_ok() and !netif_dormant().
----------------------------------------------------------------------

For me, this translates into that the device should be enabled (doing an
netif_dormant_off() and netif_carrier_ok() calls somehow) when it is
ready to communicate.  When hostapd is running and done initialising, I
would expect that to be the "ready signal", thus moving the device over
to IFF_RUNNING (via netif_dormant_off() and netif_carrier_ok() user
space equivalents)

The kernel documentation here is not too clear about a wireless device
being an AP mode.  Being in traditional client mode the docs seems to
make a lot more sense.

--linux-2.6.32.16/Documentation/networking/operstates.txt-------------

So basically a 802.1X supplicant interacts with the kernel like this:

-subscribe to RTMGRP_LINK
-set IFLA_LINKMODE to 1 via RTM_SETLINK
-query RTM_GETLINK once to get initial state
-if initial flags are not (IFF_LOWER_UP && !IFF_DORMANT), wait until
 netlink multicast signals this state
-do 802.1X, eventually abort if flags go down again
-send RTM_SETLINK to set operstate to IF_OPER_UP if authentication
 succeeds, IF_OPER_DORMANT otherwise
-see how operstate and IFF_RUNNING is echoed via netlink multicast
-set interface back to IF_OPER_DORMANT if 802.1X reauthentication
 fails
-restart if kernel changes IFF_LOWER_UP or IFF_DORMANT flag

if supplicant goes down, bring back IFLA_LINKMODE to 0 and
IFLA_OPERSTATE to a sane value.

A routing daemon or dhcp client just needs to care for IFF_RUNNING or
waiting for operstate to go IF_OPER_UP/IF_OPER_UNKNOWN before
considering the interface / querying a DHCP address.
----------------------------------------------------------------------

Even though this might be interpreted to work like you indicated, which
makes sense according to the very last paragraph, there is still an
important piece missing.  The network device needs to be pulled out of a
dormant state and set to IFF_RUNNING state at some point before any
routing daemon will start to do its job properly.  This is not happening
now.

At least on this point the docs is clear, and this is basically what is
failing currently.  Which can explain why the radvd process is not
allowed to write messages to an interface when not being in IFF_RUNNING
mode.  The kernel obviously blocks such attempts.

If radvd (or babeld or other daemons) should support auto-enabling the
devices based the device state, still requires the state to be changed
somehow.  Whether it is correct to do so, based upon if clients are
connected or not is another discussion.  (And possible pure radvd and
babeld issues is not the topic for this mailing list either)


kind regards,

David Sommerseth


From dave.taht  Mon Oct 25 17:09:51 2010
From: dave.taht (Dave Taht)
Date: Mon, 25 Oct 2010 17:09:51 -0700
Subject: IFF_RUNNING and hostapd
In-Reply-To: <4CC60E8E.8060003@topphemmelig.net>
References: <4CC5CF38.3060805@topphemmelig.net>
	<AANLkTi=0USXu4MG6omDb+2RavkiH-WDQQ48LrWj+jT2K@mail.gmail.com>
	<4CC60E8E.8060003@topphemmelig.net>
Message-ID: <AANLkTind0nHJMFt5hiCgvV08+DaMaUUMx0bjYDg=P=Uz@mail.gmail.com>

On Mon, Oct 25, 2010 at 4:11 PM, David Sommerseth
<hostapd.list at topphemmelig.net> wrote:
> On 25/10/10 21:07, Dave Taht wrote:
>> On Mon, Oct 25, 2010 at 11:40 AM, David Sommerseth wrote

[snip]

> A routing daemon or dhcp client just needs to care for IFF_RUNNING or
> waiting for operstate to go IF_OPER_UP/IF_OPER_UNKNOWN before
> considering the interface / querying a DHCP address.
> ----------------------------------------------------------------------
>
> Even though this might be interpreted to work like you indicated, which
> makes sense according to the very last paragraph, there is still an
> important piece missing. ?The network device needs to be pulled out of a
> dormant state and set to IFF_RUNNING state at some point before any
> routing daemon will start to do its job properly. ?This is not happening
> now.
>
> At least on this point the docs is clear, and this is basically what is
> failing currently. ?Which can explain why the radvd process is not
> allowed to write messages to an interface when not being in IFF_RUNNING
> mode. ?The kernel obviously blocks such attempts.
>
> If radvd (or babeld or other daemons) should support auto-enabling the
> devices based the device state, still requires the state to be changed
> somehow. ?Whether it is correct to do so, based upon if clients are
> connected or not is another discussion. ?(And possible pure radvd and
> babeld issues is not the topic for this mailing list either)

1) From what you've described it sounds like the problem can be solved
within hostap? Merely by modifying (at least in my case) the
linux_set_iface_flags function in src/drivers/linux_ioctl.c to treat
the "UP" state as UP | IFF_RUNNING?

(I'm away from my cross compiler otherwise I'd have tried this already
today) Or does it require a kernel change to reflect this issue within
bridged/non-bridged modes?

Merely setting IFF_RUNNING on non-bridged interfaces would take us
from IPv6 not-working-at-all in non-bridged AP mode to working, which
would be rather good. At the moment, I'd settle for that. :)

2) Adding a configuration variable and logic  to hostap to control
IFF_RUNNING in either of the modes described, with the default as you
describe, might be better. I don't think radvd or babeld need to
twiddle with the state of the interface itself, they have enough to
do. (it would be good if they were more responsive to changes)

The big flaw in my thinking, as I think about it, is that routing
protocols tend to take a while to propagate, and IPv6 autoconfig
should "just work", so changing the interface state on the fly on the
first client connect would introduce more instability to the network
than not.

The traffic control problem (while real) is separate from having
traffic work at all...

so what's fast and reliable and works - works for me. I'll patch the
aformentioned file and hope it works later this evening. If it's
deeper in the stack than that, (which I suspect), I'll fall over the
edge again....


>
>
> kind regards,
>
> David Sommerseth
>



-- 
Dave T?ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com


From panos  Mon Oct 25 17:13:36 2010
From: panos (Panagiotis Georgopoulos)
Date: Tue, 26 Oct 2010 01:13:36 +0100
Subject: Patches for OpenSSL
Message-ID: <006701cb74a2$a228fbf0$e67af3d0$@lancs.ac.uk>

Hello everyone,

 

               In the recent version of wpa_supplicant and hostapd, I've
seen some patches which seem to be for OpenSSL. I am not quite sure of what
their purpose is and whether I should apply them.

 

               I am having some issues with session resumption when using
EAP-TLS or EAP-TTLS with OpenSSL 0.9.8k (ubuntu 10.04) and I was thinking
whether the patches included in wpa_supplicant will help with that. It seems
that the openssl-0.9.9-session-ticket.patch might help with my problem,
however I am not running openSSL 0.9.9. In addition, it seems that there is
no patch for 0.9.8k and I am guessing that I cannot apply the later one,
right?

 

Is my only option to manually compile openSSL 1.0.0 from source for both my
supplicant, hostapd and FreeRadius in order to successfully use Session
Resumption in EAP-TLS and EAP-TTLS? (although I am guessing that if hostapd
is not used as a radius server then it doesn't require the newer version of
openSSL).

 

Thanks a lot in advance,

Panos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101026/97f0cbbf/attachment-0001.htm 


From j  Tue Oct 26 02:41:07 2010
From: j (Jouni Malinen)
Date: Tue, 26 Oct 2010 12:41:07 +0300
Subject: Patches for OpenSSL
In-Reply-To: <006701cb74a2$a228fbf0$e67af3d0$@lancs.ac.uk>
References: <006701cb74a2$a228fbf0$e67af3d0$@lancs.ac.uk>
Message-ID: <20101026094107.GA11917@jm.kir.nu>

On Tue, Oct 26, 2010 at 01:13:36AM +0100, Panagiotis Georgopoulos wrote:
>                In the recent version of wpa_supplicant and hostapd, I've
> seen some patches which seem to be for OpenSSL. I am not quite sure of what
> their purpose is and whether I should apply them.

Their only purpose is to enable EAP-FAST support in OpenSSL 0.9.8
(similar patch was included in OpenSSL 1.0.0).

>                I am having some issues with session resumption when using
> EAP-TLS or EAP-TTLS with OpenSSL 0.9.8k (ubuntu 10.04) and I was thinking
> whether the patches included in wpa_supplicant will help with that.

No, they should not affect EAP-TLS or EAP-TTLS at all.

> Is my only option to manually compile openSSL 1.0.0 from source for both my
> supplicant, hostapd and FreeRadius in order to successfully use Session
> Resumption in EAP-TLS and EAP-TTLS? (although I am guessing that if hostapd
> is not used as a radius server then it doesn't require the newer version of
> openSSL).

No, session resumption is expected to work with standard OpenSSL builds.
Please describe the problems you are seeing in more detail.

-- 
Jouni Malinen                                            PGP id EFC895FA


From gernot.tenchio  Tue Oct 26 03:37:20 2010
From: gernot.tenchio (Gernot Tenchio)
Date: Tue, 26 Oct 2010 12:37:20 +0200
Subject: Looking for a very special WLAN-Card
Message-ID: <20101026123720.2e17eca0@gt.securepoint.local>

Hi,

maybe someone can help me with this. I'm looking for a WLAN-Card with
Atheros chipset and USB Host Interface which fits in a Mini-PCI-E Slot.
Has anyone heard about such a card which also works with hostapd? Sorry,
if this is the wrong list to ask, but i haven't found a better one.

Many thanks in advance
Gernot


From j  Tue Oct 26 06:38:37 2010
From: j (Jouni Malinen)
Date: Tue, 26 Oct 2010 16:38:37 +0300
Subject: IFF_RUNNING and hostapd
In-Reply-To: <AANLkTikF14qsDwtQ9_2w2Erg5SB7WHoCsox6HqK_KBhu@mail.gmail.com>
References: <AANLkTindhPCGcA8PH7GdSy2zwTvj0oD-tJewqUPvsd8F@mail.gmail.com>
	<20101012171439.GA20698@jm.kir.nu>
	<AANLkTikF14qsDwtQ9_2w2Erg5SB7WHoCsox6HqK_KBhu@mail.gmail.com>
Message-ID: <20101026133837.GA15266@jm.kir.nu>

On Tue, Oct 12, 2010 at 01:24:00PM -0700, Dave Taht wrote:
> On Tue, Oct 12, 2010 at 10:14 AM, Jouni Malinen <j at w1.fi> wrote:
> > On Fri, Oct 01, 2010 at 03:32:42PM -0700, Dave Taht wrote:
> >> I recently configured an openwrt system (a nanostation M) as a pure

> > Which driver are you using for wlan0?
> 
> ath9k with nl80211

Ah.. I finally figured out what was happening. Something else in the
system is setting the interface to IF_OPER_DORMANT state and that
prevents IFF_RUNNING from showing up. In normal case, this would not
happen, but it looks like the multi-call hostapd/wpa_supplicant in
OpenWRT triggers this. I was able to reproduce this by forcefully
killing wpa_supplicant so that it does not have chance of cleaning up
the operstate change (which is needed for station mode).

> > hostapd does not control this and the exact behavior is likely to depend
> > on which driver is being used.
> 
> What does? My thought was basically IFF_RUNNING should be set
> somewhere between these steps on a non-bridged AP, for the first
> client that comes online - and unset after the last client goes
> offline.

IFF_RUNNING is set in the kernel; operstate DORMANT/UP can be set in
user space. hostapd never set this to DORMANT, so there was normally no
need for setting it to UP either. However, since other applications may
leave the interface to DORMANT operstate, I now added code in hostapd to
clear that to avoid this issue. The change in the development branch is
here:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=e11f5a2cbc333113a3a1cc1aeea7f698c3936ca3

-- 
Jouni Malinen                                            PGP id EFC895FA


From francesco.gringoli  Tue Oct 26 07:02:37 2010
From: francesco.gringoli (Francesco Gringoli)
Date: Tue, 26 Oct 2010 16:02:37 +0200
Subject: Looking for a very special WLAN-Card
In-Reply-To: <20101026123720.2e17eca0@gt.securepoint.local>
References: <20101026123720.2e17eca0@gt.securepoint.local>
Message-ID: <235D69D3-A829-4F6C-9B1C-C968590C1F17@gmail.com>

On Oct 26, 2010, at 12:37 PM, Gernot Tenchio wrote:

> Hi,
> 
> maybe someone can help me with this. I'm looking for a WLAN-Card with
> Atheros chipset and USB Host Interface which fits in a Mini-PCI-E Slot.
> Has anyone heard about such a card which also works with hostapd? Sorry,
> if this is the wrong list to ask, but i haven't found a better one.
What do you exactly mean with "fit"? Should it connect through mini-pci-e too? Or should it only be enclosed inside an expansion slot (e.g., that of a netbook) and be connected through usb? If you meant the second then you could try a usb key based on ar9170. If you unsolder the USB connector then it should fit.

Cheers,
-FG

> 
> Many thanks in advance
> Gernot
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap



From gernot.tenchio  Tue Oct 26 07:28:05 2010
From: gernot.tenchio (Gernot Tenchio)
Date: Tue, 26 Oct 2010 16:28:05 +0200
Subject: Looking for a very special WLAN-Card
In-Reply-To: <235D69D3-A829-4F6C-9B1C-C968590C1F17@gmail.com>
References: <20101026123720.2e17eca0@gt.securepoint.local>
	<235D69D3-A829-4F6C-9B1C-C968590C1F17@gmail.com>
Message-ID: <20101026162805.762e465c@gt.securepoint.local>

On Tue, 26 Oct 2010 16:02:37 +0200 Francesco Gringoli
wrote:

> What do you exactly mean with "fit"? Should it connect through
> mini-pci-e too? Or should it only be enclosed inside an expansion
> slot (e.g., that of a netbook) and be connected through usb? If you
> meant the second then you could try a usb key based on ar9170. If you
> unsolder the USB connector then it should fit.
> 
> Cheers,
> -FG

I have a board with a Mini-PCI-E expansion slot. But only the USB part
of it is wired. I'm currently using rt73usb but i'm not happy with it.

Greetings
Gernot


From mike4658  Tue Oct 26 08:45:56 2010
From: mike4658 (mike4658 at freenet.de)
Date: Tue, 26 Oct 2010 17:45:56 +0200
Subject: Problem with EAP-TTLS authentication, log file inside - need help!
Message-ID: <56710f739f897316cc7d00ee4111881b@email.freenet.de>

Hello,

my hardware is a Linksys WRT54GL router with OpenWRT kamikaze 8.09 RC1 (brcm47xx) and wpa_supplicant installed.
I want wo connect to a WLAN with EAP-TTLS authentication.
I configured the wpa_supplicant.conf as forced by the provider and have a certificate file.
But the authentication is not working.

Here is the end of the log file (I logged with the option "-d"):

X509: Did not find any of the issuers from the list of trusted certificates
TLSv1: Server certificate chain validation failed (reason=6)
TLSv1: Send 
SSL: 7 bytes left to be sent out (of total 7 bytes)
EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL
EAP: EAP entering state SEND_RESPONSE
EAP: EAP entering state IDLE
EAPOL: SUPP_BE entering state RESPONSE
EAPOL: txSuppRsp
TX EAPOL: dst=00:12:da:9e:60:00
EAPOL: SUPP_BE entering state RECEIVE
EAPOL: startWhen --> 0
RX EAPOL from 00:12:da:9e:60:00
EAPOL: Received EAP-Packet frame
EAPOL: SUPP_BE entering state REQUEST
EAPOL: getSuppRsp
EAP: EAP entering state RECEIVED
EAP: Received EAP-Failure
EAP: EAP entering state FAILURE
CTRL-EVENT-EAP-FAILURE EAP authentication failed
EAPOL: SUPP_PAE entering state HELD
EAPOL: SUPP_BE entering state RECEIVE
EAPOL: SUPP_BE entering state FAIL
EAPOL: SUPP_BE entering state IDLE
EAPOL authentication completed unsuccessfully
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:00:00:00:00:00
Setting scan request: 0 sec 100000 usec
Added BSSID 00:12:da:9e:60:00 into blacklist
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys

What does this
"X509: Did not find any of the issuers from the list of trusted certificates
TLSv1: Server certificate chain validation failed (reason=6)"
mean?
Who can help me?
Is the authentication time too short? I think my USB WLAN adapter takes more time to authenticate.

Thanks in advance,

Mike



FreeLotto - das kostenlose Lotto von freenet!
Jeden Tag die Chance auf 2 Millionen Euro nutzen.
Jetzt gratis Lotto spielen auf http://freelotto.freenet.de!



From hostapd.list  Tue Oct 26 11:11:15 2010
From: hostapd.list (David Sommerseth)
Date: Tue, 26 Oct 2010 20:11:15 +0200
Subject: IFF_RUNNING and hostapd
In-Reply-To: <20101026133837.GA15266@jm.kir.nu>
References: <AANLkTindhPCGcA8PH7GdSy2zwTvj0oD-tJewqUPvsd8F@mail.gmail.com>	<20101012171439.GA20698@jm.kir.nu>	<AANLkTikF14qsDwtQ9_2w2Erg5SB7WHoCsox6HqK_KBhu@mail.gmail.com>
	<20101026133837.GA15266@jm.kir.nu>
Message-ID: <4CC719C3.10603@topphemmelig.net>

On 26/10/10 15:38, Jouni Malinen wrote:
> On Tue, Oct 12, 2010 at 01:24:00PM -0700, Dave Taht wrote:
>> On Tue, Oct 12, 2010 at 10:14 AM, Jouni Malinen <j at w1.fi> wrote:
>>> On Fri, Oct 01, 2010 at 03:32:42PM -0700, Dave Taht wrote:
>>>> I recently configured an openwrt system (a nanostation M) as a pure
> 
>>> Which driver are you using for wlan0?
>>
>> ath9k with nl80211
> 
> Ah.. I finally figured out what was happening. Something else in the
> system is setting the interface to IF_OPER_DORMANT state and that
> prevents IFF_RUNNING from showing up. In normal case, this would not
> happen, but it looks like the multi-call hostapd/wpa_supplicant in
> OpenWRT triggers this. I was able to reproduce this by forcefully
> killing wpa_supplicant so that it does not have chance of cleaning up
> the operstate change (which is needed for station mode).
> 
>>> hostapd does not control this and the exact behavior is likely to depend
>>> on which driver is being used.
>>
>> What does? My thought was basically IFF_RUNNING should be set
>> somewhere between these steps on a non-bridged AP, for the first
>> client that comes online - and unset after the last client goes
>> offline.
> 
> IFF_RUNNING is set in the kernel; operstate DORMANT/UP can be set in
> user space. hostapd never set this to DORMANT, so there was normally no
> need for setting it to UP either. However, since other applications may
> leave the interface to DORMANT operstate, I now added code in hostapd to
> clear that to avoid this issue. The change in the development branch is
> here:
> http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=e11f5a2cbc333113a3a1cc1aeea7f698c3936ca3

I've just tried to compile the updated SVN tree for OpenWRT (backfire,
r23644) and it works just as expected now.  The network interface is in
UP/RUNNING state and radvd can do it's job properly.

Thanks a lot for your promptly response!


kind regards,

David Sommerseth



From clopez  Tue Oct 26 12:28:41 2010
From: clopez (Carlos Alberto Lopez Perez)
Date: Tue, 26 Oct 2010 21:28:41 +0200
Subject: Patches for OpenSSL
In-Reply-To: <006701cb74a2$a228fbf0$e67af3d0$@lancs.ac.uk>
References: <006701cb74a2$a228fbf0$e67af3d0$@lancs.ac.uk>
Message-ID: <4CC72BE9.80704@igalia.com>

Hello,

I had personally experienced this problem and after a lot of tries I found
this solution [1] that worked like a charm.

Setting

ctx_options |= SSL_OP_NO_TICKET ;

in the file rlm_eap_tls.c of freeradius solved the problems with session
resumption when using EAP-TLS with hostapd+freeradius.

------
[1]
http://lists.freeradius.org/pipermail/freeradius-users/2010-June/msg00161.html

El 26/10/10 02:13, Panagiotis Georgopoulos escribi?:
> Hello everyone,
> 
>  
> 
>                In the recent version of wpa_supplicant and hostapd, I've
> seen some patches which seem to be for OpenSSL. I am not quite sure of what
> their purpose is and whether I should apply them.
> 
>  
> 
>                I am having some issues with session resumption when using
> EAP-TLS or EAP-TTLS with OpenSSL 0.9.8k (ubuntu 10.04) and I was thinking
> whether the patches included in wpa_supplicant will help with that. It seems
> that the openssl-0.9.9-session-ticket.patch might help with my problem,
> however I am not running openSSL 0.9.9. In addition, it seems that there is
> no patch for 0.9.8k and I am guessing that I cannot apply the later one,
> right?
> 
>  
> 
> Is my only option to manually compile openSSL 1.0.0 from source for both my
> supplicant, hostapd and FreeRadius in order to successfully use Session
> Resumption in EAP-TLS and EAP-TTLS? (although I am guessing that if hostapd
> is not used as a radius server then it doesn't require the newer version of
> openSSL).
> 
>  
> 
> Thanks a lot in advance,
> 
> Panos
> 
> 
> 
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20101026/10c7a5bb/attachment.pgp 


From dave.taht  Tue Oct 26 15:22:11 2010
From: dave.taht (Dave Taht)
Date: Tue, 26 Oct 2010 15:22:11 -0700
Subject: IFF_RUNNING and hostapd
In-Reply-To: <4CC719C3.10603@topphemmelig.net>
References: <AANLkTindhPCGcA8PH7GdSy2zwTvj0oD-tJewqUPvsd8F@mail.gmail.com>
	<20101012171439.GA20698@jm.kir.nu>
	<AANLkTikF14qsDwtQ9_2w2Erg5SB7WHoCsox6HqK_KBhu@mail.gmail.com>
	<20101026133837.GA15266@jm.kir.nu>
	<4CC719C3.10603@topphemmelig.net>
Message-ID: <AANLkTin9-rnRisobo1SPA2bLczUfG73vCXAO1QCj2YVj@mail.gmail.com>

On Tue, Oct 26, 2010 at 11:11 AM, David Sommerseth
<hostapd.list at topphemmelig.net> wrote:
> On 26/10/10 15:38, Jouni Malinen wrote:
>> IFF_RUNNING is set in the kernel; operstate DORMANT/UP can be set in
>> user space. hostapd never set this to DORMANT, so there was normally no
>> need for setting it to UP either. However, since other applications may
>> leave the interface to DORMANT operstate, I now added code in hostapd to
>> clear that to avoid this issue. The change in the development branch is
>> here:
>> http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=e11f5a2cbc333113a3a1cc1aeea7f698c3936ca3
>
> I've just tried to compile the updated SVN tree for OpenWRT (backfire,
> r23644) and it works just as expected now. ?The network interface is in
> UP/RUNNING state and radvd can do it's job properly.
>
> Thanks a lot for your promptly response!
>
>
> kind regards,
>
> David Sommerseth
>

I also confirm that with latest openwrt svn my nanostation M5s work in
AP routed-only mode. I do have to "kick" the sta router by running
iwconfig wlan0 essid whatever in rc.local but I assume that's a
configuration or layer dependency elsewhere. Much thanks!


-- 
Dave T?ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com


From hp  Wed Oct 27 02:07:09 2010
From: hp (Hans-Peter Oeri)
Date: Wed, 27 Oct 2010 11:07:09 +0200
Subject: EAP-SIM/AKA by issuing at commands (+CUAD,+CEAP,+CERP)
Message-ID: <4CC7EBBD.7060601@oeri.ch>

Hi!

While a lot of information on EAP-SIM/AKA with pcsc is available, I
wonder if anyone tried to use the defined at commands
(+CUAD,+CEAP,+CERP) on a serial interface/modem?

As I see it - but I'm no specialist in the field - authentication could
be possible w/o pcsc support. And - unfortunately - I could not connect
pcsc-lite to my ericsson f3705g internal hsdpa card... But also in times
of multiple sims available (eg. one in phone, one in notebook, one in
tablet...), being able to poll a sim that's only available in a 'modem'
device would be nice.

Thanks for any pointers!
HPO


From helmut.schaa  Wed Oct 27 07:40:23 2010
From: helmut.schaa (Helmut Schaa)
Date: Wed, 27 Oct 2010 16:40:23 +0200
Subject: [PATCH] driver_nl80211: Pass data frames from unknown STAs to hostapd
Message-ID: <201010271640.23588.helmut.schaa@googlemail.com>

Pass data frames from unknown STAs to hostapd in order to reply with a
deauth or deassoc frame. This ensures compliance with 802.11-2007 11.3.

Furthermore, this does not cause a lot of overhead (at least with
mac80211 drivers) since mac80211 does not pass all data frames (but
at least from unauthenticated and unassociated STAs) to cooked monitor
interfaces.

Tested with rt2800pci on a MIPS board.

Signed-off-by: Helmut Schaa <helmut.schaa at googlemail.com>
---
 src/drivers/driver_nl80211.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index 3ad8812..a922ccf 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -3368,8 +3368,14 @@ static struct sock_filter msock_filter_insns[] = {
 	 * add a filter here that filters on our DA and that flag
 	 * to allow us to deauth frames to that bad station.
 	 *
-	 * Not a regression -- we didn't do it before either.
+	 * For now allow all to DS data frames through.
 	 */
+	/* load the IEEE 802.11 frame control field */
+	BPF_STMT(BPF_LD  | BPF_H | BPF_IND, 0),
+	/* mask off frame type, version and DS status */
+	BPF_STMT(BPF_ALU | BPF_AND | BPF_K, 0x0F03),
+	/* accept frame if version 0, type 2 and to DS, fall through otherwise */
+	BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, 0x0801, PASS, 0),
 
 #if 0
 	/*
-- 
1.7.1



From wang.weisung  Wed Oct 27 18:23:03 2010
From: wang.weisung (Weisung Wang)
Date: Thu, 28 Oct 2010 09:23:03 +0800
Subject: Looking for a very special WLAN-Card
In-Reply-To: <20101026162805.762e465c@gt.securepoint.local>
References: <20101026123720.2e17eca0@gt.securepoint.local>
	<235D69D3-A829-4F6C-9B1C-C968590C1F17@gmail.com>
	<20101026162805.762e465c@gt.securepoint.local>
Message-ID: <AANLkTik=fGBakz7TYbLLGbgjJ6MjR_R4J9p-Z-CG=O5Q@mail.gmail.com>

Atheros AR9271 based card should be what you want.  But I am not sure where
you can buy the module card.

Regards,
Weisung Wang

On Tue, Oct 26, 2010 at 10:28 PM, Gernot Tenchio <
gernot.tenchio at securepoint.de> wrote:

> On Tue, 26 Oct 2010 16:02:37 +0200 Francesco Gringoli
> wrote:
>
> > What do you exactly mean with "fit"? Should it connect through
> > mini-pci-e too? Or should it only be enclosed inside an expansion
> > slot (e.g., that of a netbook) and be connected through usb? If you
> > meant the second then you could try a usb key based on ar9170. If you
> > unsolder the USB connector then it should fit.
> >
> > Cheers,
> > -FG
>
> I have a board with a Mini-PCI-E expansion slot. But only the USB part
> of it is wired. I'm currently using rt73usb but i'm not happy with it.
>
> Greetings
> Gernot
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20101028/97509bc6/attachment.htm 


From mike4658  Thu Oct 28 02:32:29 2010
From: mike4658 (mike4658 at freenet.de)
Date: Thu, 28 Oct 2010 11:32:29 +0200
Subject: wpa_supplicant: How to set authentication time?
Message-ID: <310634bcebc8ccdb2d940d982fd7ac1f@email.freenet.de>

Hello,


I think I have a problem with the authentication time ("Authentication with 00:12:da:9e:60:00 timed out.").
How can I set the authentication time ("Setting authentication timeout: 3 sec 0 usec") to 5 or 10 seconds?

I installed wpa_cli to do so but I get the following (error) message when I start wpa_cli:

root at OpenWrt:~# wpa_cli set
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory:
Content of the lhe log file when starting wpa_supplicant:
Associated to a new BSS: BSSID=00:12:da:9e:60:00
No keys have been configured - skip key clearing
Associated with 00:12:da:9e:60:00
WPA: Association event - clear replay counter
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
EAPOL: External notification - portEnabled=1
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: SUPP_BE entering state IDLE
EAP: EAP entering state INITIALIZE
EAP: EAP entering state IDLE
Setting authentication timeout: 3 sec 0 usec
Cancelling scan request
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
EAPOL: startWhen --> 0
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: txStart
TX EAPOL: dst=00:12:da:9e:60:00
Authentication with 00:12:da:9e:60:00 timed out.
Thank you very much for your help,


Mike





Exklusiv: Neue E-Mail-Adresse @iPhone.de jetzt verf?gbar!
Sichern Sie sich jetzt ihre pers?nliche http://www.iphone.de/iphonemail/index.html?pid=10111947021



From dcbw  Thu Oct 28 06:46:32 2010
From: dcbw (Dan Williams)
Date: Thu, 28 Oct 2010 08:46:32 -0500
Subject: wpa_supplicant: How to set authentication time?
In-Reply-To: <310634bcebc8ccdb2d940d982fd7ac1f@email.freenet.de>
References: <310634bcebc8ccdb2d940d982fd7ac1f@email.freenet.de>
Message-ID: <1288273592.2364.2.camel@dcbw.foobar.com>

On Thu, 2010-10-28 at 11:32 +0200, mike4658 at freenet.de wrote:
> Hello,
> 
> 
> I think I have a problem with the authentication time ("Authentication with 00:12:da:9e:60:00 timed out.").
> How can I set the authentication time ("Setting authentication timeout: 3 sec 0 usec") to 5 or 10 seconds?
> 
> I installed wpa_cli to do so but I get the following (error) message when I start wpa_cli:

This can also be driver problems.  Just upping the timeout may not
necessarily fix the issue.  First I'd try getting some driver debugging
to figure out *why* the driver cannot associate within the time given.

Dan

> root at OpenWrt:~# wpa_cli set
> Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory:
> Content of the lhe log file when starting wpa_supplicant:
> Associated to a new BSS: BSSID=00:12:da:9e:60:00
> No keys have been configured - skip key clearing
> Associated with 00:12:da:9e:60:00
> WPA: Association event - clear replay counter
> EAPOL: External notification - portEnabled=0
> EAPOL: External notification - portValid=0
> EAPOL: External notification - portEnabled=1
> EAPOL: SUPP_PAE entering state CONNECTING
> EAPOL: SUPP_BE entering state IDLE
> EAP: EAP entering state INITIALIZE
> EAP: EAP entering state IDLE
> Setting authentication timeout: 3 sec 0 usec
> Cancelling scan request
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> EAPOL: startWhen --> 0
> EAPOL: SUPP_PAE entering state CONNECTING
> EAPOL: txStart
> TX EAPOL: dst=00:12:da:9e:60:00
> Authentication with 00:12:da:9e:60:00 timed out.
> Thank you very much for your help,
> 
> 
> Mike
> 
> 
> 
> 
> 
> Exklusiv: Neue E-Mail-Adresse @iPhone.de jetzt verf?gbar!
> Sichern Sie sich jetzt ihre pers?nliche http://www.iphone.de/iphonemail/index.html?pid=10111947021
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap




From mike4658  Thu Oct 28 12:12:02 2010
From: mike4658 (mike4658 at freenet.de)
Date: Thu, 28 Oct 2010 21:12:02 +0200
Subject: wpa_supplicant: How to set authentication time?
Message-ID: <9840907de3f6717e8df998d2703003c7@email.freenet.de>

> > Hello,
> >
> >
> > I think I have a problem with the authentication time
> > ("Authentication with 00:12:da:9e:60:00 timed out.").
> > How can I set the authentication time ("Setting authentication
> > timeout: 3 sec 0 usec") to 5 or 10 seconds?
> >
> > I installed wpa_cli to do so but I get the following (error)
> > message when I start wpa_cli:
> 
> This can also be driver problems.  Just upping the timeout may not
> necessarily fix the issue.  First I'd try getting some driver
> debugging
> to figure out *why* the driver cannot associate within the time
> given.
> 
> Dan

How can I debug the driver? Sorry, if this is a newbie question, but I am a newbie. Thankfully one isn't a
newbie forever.

But still I would like to try to set the authentication time. Maybe somebody can help.

Thanks,

Mike


> > root at OpenWrt:~# wpa_cli set
> > Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file
> > or directory:
> > Content of the lhe log file when starting wpa_supplicant:
> > Associated to a new BSS: BSSID=00:12:da:9e:60:00
> > No keys have been configured - skip key clearing
> > Associated with 00:12:da:9e:60:00
> > WPA: Association event - clear replay counter
> > EAPOL: External notification - portEnabled=0
> > EAPOL: External notification - portValid=0
> > EAPOL: External notification - portEnabled=1
> > EAPOL: SUPP_PAE entering state CONNECTING
> > EAPOL: SUPP_BE entering state IDLE
> > EAP: EAP entering state INITIALIZE
> > EAP: EAP entering state IDLE
> > Setting authentication timeout: 3 sec 0 usec
> > Cancelling scan request
> > RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> > RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> > RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> > RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> > EAPOL: startWhen --> 0
> > EAPOL: SUPP_PAE entering state CONNECTING
> > EAPOL: txStart
> > TX EAPOL: dst=00:12:da:9e:60:00
> > Authentication with 00:12:da:9e:60:00 timed out.
> > Thank you very much for your help,
> >
> >
> > Mike
> > _______________________________________________
> > HostAP mailing list
> > HostAP at lists.shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap




FreeLotto - das kostenlose Lotto von freenet!
Jeden Tag die Chance auf 2 Millionen Euro nutzen.
Jetzt gratis Lotto spielen auf http://freelotto.freenet.de!



From j  Thu Oct 28 12:17:40 2010
From: j (Jouni Malinen)
Date: Thu, 28 Oct 2010 22:17:40 +0300
Subject: wpa_supplicant: How to set authentication time?
In-Reply-To: <9840907de3f6717e8df998d2703003c7@email.freenet.de>
References: <9840907de3f6717e8df998d2703003c7@email.freenet.de>
Message-ID: <20101028191740.GA2876@jm.kir.nu>

On Thu, Oct 28, 2010 at 09:12:02PM +0200, mike4658 at freenet.de wrote:
> But still I would like to try to set the authentication time. Maybe somebody can help.

You can do that by modifying source code.. There is no configuration
option for this.

-- 
Jouni Malinen                                            PGP id EFC895FA


From dimitrysh  Thu Oct 28 14:30:29 2010
From: dimitrysh (Dmitry Shmidt)
Date: Thu, 28 Oct 2010 14:30:29 -0700
Subject: [PATCH] Clear vars in drivers makefile
Message-ID: <AANLkTi=donw7jWjofNC==Sg=762_NK6ka9zcc_Lnj43o@mail.gmail.com>

drivers.mak is shared between hostapd and wpa_supplicant and
compilation them together may create "wrong" flags.

--------------------



From dimitrysh  Thu Oct 28 14:25:52 2010
From: dimitrysh (Dmitry Shmidt)
Date: Thu, 28 Oct 2010 14:25:52 -0700
Subject: [PATCH] Clear vars in drivers makefile
Message-ID: <mailman.25.1288301438.20990.hostap@lists.shmoo.com>

Signed-off-by: Dmitry Shmidt <dimitrysh at google.com>
---
 src/drivers/drivers.mak |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/src/drivers/drivers.mak b/src/drivers/drivers.mak
index aeb7924..c0c2c33 100644
--- a/src/drivers/drivers.mak
+++ b/src/drivers/drivers.mak
@@ -1,3 +1,15 @@
+##### CLEAR VARS
+
+DRV_CFLAGS =
+DRV_WPA_CFLAGS =
+DRV_AP_CFLAGS =
+DRV_OBJS =
+DRV_WPA_OBJS =
+DRV_AP_OBJS =
+DRV_LIBS =
+DRV_WPA_LIBS =
+DRV_AP_LIBS =
+
 ##### COMMON DRIVERS

 ifdef CONFIG_DRIVER_HOSTAP
-- 
1.6.2.2


From dimitrysh  Fri Oct 29 14:43:35 2010
From: dimitrysh (Dmitry Shmidt)
Date: Fri, 29 Oct 2010 14:43:35 -0700
Subject: [PATCH] Add WPA_IGNORE_CONFIG_ERRORS option to continue in case of
	bad config
Message-ID: <AANLkTinqczN31JRSr22sYJvDDek1pSPKH7-q6k0tdPF4@mail.gmail.com>

Hi,
This is an option to continue with wpa_supplicant and hostapd even if
config file has errors.
The problem is that these daemons are the best "candidates" for the
config change, so if they can not start
because config file was let's say corrupted, you can not fix it easily.
Thanks,

Dmitry

---------------



From dimitrysh  Fri Oct 29 14:22:28 2010
From: dimitrysh (Dmitry Shmidt)
Date: Fri, 29 Oct 2010 14:22:28 -0700
Subject: [PATCH] Add WPA_IGNORE_CONFIG_ERRORS option to continue in
Message-ID: <mailman.26.1288388622.20990.hostap@lists.shmoo.com>

case of bad config

Signed-off-by: Dmitry Shmidt <dimitrysh at google.com>
---
 hostapd/config_file.c        |    2 ++
 wpa_supplicant/config_file.c |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/hostapd/config_file.c b/hostapd/config_file.c
index a6a3e5c..7eaf683 100644
--- a/hostapd/config_file.c
+++ b/hostapd/config_file.c
@@ -2068,6 +2068,7 @@ struct hostapd_config *
hostapd_config_read(const char *fname)
 			bss->ssid.security_policy = SECURITY_PLAINTEXT;
 	}

+#ifndef WPA_IGNORE_CONFIG_ERRORS
 	if (hostapd_config_check(conf))
 		errors++;

@@ -2077,6 +2078,7 @@ struct hostapd_config *
hostapd_config_read(const char *fname)
 		hostapd_config_free(conf);
 		conf = NULL;
 	}
+#endif

 	return conf;
 }
diff --git a/wpa_supplicant/config_file.c b/wpa_supplicant/config_file.c
index 2431e84..4ed5e0a 100644
--- a/wpa_supplicant/config_file.c
+++ b/wpa_supplicant/config_file.c
@@ -331,11 +331,13 @@ struct wpa_config * wpa_config_read(const char *name)
 	config->ssid = head;
 	wpa_config_debug_dump_networks(config);

+#ifndef WPA_IGNORE_CONFIG_ERRORS
 	if (errors) {
 		wpa_config_free(config);
 		config = NULL;
 		head = NULL;
 	}
+#endif

 	return config;
 }
-- 
1.6.2.2


From j  Sun Oct 31 03:00:21 2010
From: j (Jouni Malinen)
Date: Sun, 31 Oct 2010 12:00:21 +0200
Subject: [PATCH] Clear vars in drivers makefile
In-Reply-To: <AANLkTi=donw7jWjofNC==Sg=762_NK6ka9zcc_Lnj43o@mail.gmail.com>
References: <AANLkTi=donw7jWjofNC==Sg=762_NK6ka9zcc_Lnj43o@mail.gmail.com>
Message-ID: <20101031100021.GA4706@jm.kir.nu>

On Thu, Oct 28, 2010 at 02:30:29PM -0700, Dmitry Shmidt wrote:
> drivers.mak is shared between hostapd and wpa_supplicant and
> compilation them together may create "wrong" flags.

Thanks! Applied.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sun Oct 31 03:40:40 2010
From: j (Jouni Malinen)
Date: Sun, 31 Oct 2010 12:40:40 +0200
Subject: [PATCH] Add WPA_IGNORE_CONFIG_ERRORS option to continue in
	case of bad config
In-Reply-To: <AANLkTinqczN31JRSr22sYJvDDek1pSPKH7-q6k0tdPF4@mail.gmail.com>
References: <AANLkTinqczN31JRSr22sYJvDDek1pSPKH7-q6k0tdPF4@mail.gmail.com>
Message-ID: <20101031104040.GA13170@jm.kir.nu>

On Fri, Oct 29, 2010 at 02:43:35PM -0700, Dmitry Shmidt wrote:
> This is an option to continue with wpa_supplicant and hostapd even if
> config file has errors.
> The problem is that these daemons are the best "candidates" for the
> config change, so if they can not start
> because config file was let's say corrupted, you can not fix it easily.

Thanks, applied. Though, I made the hostapd version call
hostapd_config_check() to get the errors shown in output and to get rid
of a compiler warning on unused function.

-- 
Jouni Malinen                                            PGP id EFC895FA


From j  Sun Oct 31 12:39:06 2010
From: j (Jouni Malinen)
Date: Sun, 31 Oct 2010 21:39:06 +0200
Subject: [PATCH] driver_nl80211: Pass data frames from unknown STAs to
	hostapd
In-Reply-To: <201010271640.23588.helmut.schaa@googlemail.com>
References: <201010271640.23588.helmut.schaa@googlemail.com>
Message-ID: <20101031193906.GA19012@jm.kir.nu>

On Wed, Oct 27, 2010 at 04:40:23PM +0200, Helmut Schaa wrote:
> Pass data frames from unknown STAs to hostapd in order to reply with a
> deauth or deassoc frame. This ensures compliance with 802.11-2007 11.3.
> 
> Furthermore, this does not cause a lot of overhead (at least with
> mac80211 drivers) since mac80211 does not pass all data frames (but
> at least from unauthenticated and unassociated STAs) to cooked monitor
> interfaces.

Thanks! Applied. I would hope that we will eventually get an nl80211
event for indicating this, but for now, this looks like a reasonable
approach.

-- 
Jouni Malinen                                            PGP id EFC895FA


