headers
Dmitry Shmidt | 1 Mar 2011 02:52
Picon
Favicon

Flush pmk cache

Hello,

We saw that if you connect to enterprise network, then remove it and
recreate with wrong password it will be still connected properly.
Our suspicion is pmk cache. Does it make sense to flush it in this case like:
---------------------------------------------------------------------------------------------------------------------------
diff --git a/wpa_supplicant/ctrl_iface.c b/wpa_supplicant/ctrl_iface.c
index 351804e..9b0185d 100644
--- a/wpa_supplicant/ctrl_iface.c
+++ b/wpa_supplicant/ctrl_iface.c
 <at>  <at>  -1041,12 +1041,13  <at>  <at>  static int wpa_supplicant_ctrl_iface_remove_network(
        }

        if (ssid == wpa_s->current_ssid) {
+               wpa_printf(MSG_DEBUG, "RSN: flushing PMKID list in the driver");
+               wpa_drv_flush_pmkid(wpa_s);

                /*
                 * Invalidate the EAP session cache if the current network is
                 * removed.
                 */
                eapol_sm_invalidate_cached_session(wpa_s->eapol);

                wpa_supplicant_disassociate(wpa_s, WLAN_REASON_DEAUTH_LEAVING);
        }

Thanks,

Dmitry
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jouni Malinen | 1 Mar 2011 09:04
Picon

Re: Local and remote Authentication at the same time

On Mon, Feb 28, 2011 at 05:07:50PM -0000, Panagiotis Georgopoulos wrote:
> Is there any way to get hostapd to support both local and remote
> authentication in a way that, it first checks its internal RADIUS server and
> if it doesn't have any information for the specific client requesting
> access, then it sends the packets to the remote AAA RADIUS server?

This is not currently supported, but at least in theory, it should be
relatively easy to add support for this since the state machines have at
least partial support for this type of selection.

Though, it should also be noted that there can be some challenges in
recognizing what is to be done locally with EAP methods like EAP-TTLS
that may start with anonymous identity in the first phase.

--

-- 
Jouni Malinen                                            PGP id EFC895FA
Permalink | Reply | 1 comment |
headers
Johannes Berg | 1 Mar 2011 09:28
Favicon

Re: [PATCH] hostapd: Add .gitignore for .config

On Mon, 2011-02-28 at 15:50 -0800, Dmitry Shmidt wrote:

> You mean like this:

Yeah,

> --- a/.gitignore
> +++ b/.gitignore
>  <at>  <at>  -11,10 +11,12  <at>  <at>  wpa_supplicant/wpa_gui/Makefile
>  wpa_supplicant/wpa_gui/wpa_gui
>  wpa_supplicant/wpa_gui-qt4/Makefile
>  wpa_supplicant/wpa_gui-qt4/wpa_gui
> +wpa_supplicant/.config
>  hostapd/hostapd
>  hostapd/hostapd_cli
>  hostapd/hlr_auc_gw
>  hostapd/nt_password_hash
> +hostapd/.config

or even just ".config" instead of these two.

I don't care, but it seems a bit weird to have
a /wpa_supplicant/.gitignore file in addition to a /.gitignore file that
has wpa_supplicant/* things in it :-)

johannes
Permalink | Reply | 1 comment |
headers
Panagiotis Georgopoulos | 1 Mar 2011 11:14
Picon

RE: Local and remote Authentication at the same time

> On Mon, Feb 28, 2011 at 05:07:50PM -0000, Panagiotis Georgopoulos
> wrote:
> > Is there any way to get hostapd to support both local and remote
> > authentication in a way that, it first checks its internal RADIUS
> > server and if it doesn't have any information for the specific client 
> > requesting
> > access, then it sends the packets to the remote AAA RADIUS server?
> 
> This is not currently supported, but at least in theory, it should be
> relatively easy to add support for this since the state machines have
> at
> least partial support for this type of selection.
> 
> Though, it should also be noted that there can be some challenges in
> recognizing what is to be done locally with EAP methods like EAP-TTLS
> that may start with anonymous identity in the first phase.
> 
> Jouni Malinen                                            PGP id

Thanks a lot for your reply Jouni.

I think this is a very useful feature that would interest a lot of people
resorting to use the internal authentication server for some scenarios, but
also willing to support authentication using a remote AAA server. 

Regarding the methods that start with anonymous identity, you could always
have a flag in the configuration file that says primary or default method
for anonymous identity requests = local or remote AAA server or something
similar I imagine.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karl Rothenhöfer | 1 Mar 2011 11:41
Picon

RE: Wake Accesspoint over WLAN

Hello Johannes,

 

thank you for your quick and clear reply.

 

I understand the special interest in waking up clients e.g. for all kinds of maintenance activities.

 

And I could also notice, that the interest to wake up the accesspoint itself by a client being interested in service has not been mentioned publicly. Nevertheless my interest still persists and a solution for my issue could be helpful for others as well.

 

I understand, that in order to be wakeable a client must stay connected with the accesspoint. The client is evidently able to maintain connectivity using 5Vsb (5V standby voltage). With what I know it seems thinkable that an accesspoint could also use 5Vsb to continue performing its routine task of sending beacon frames and providing support for the clients to maintain connection. If that would be achievable with firmware means only, i.e. without SW support, then it would also seem thinkable to react on wake up events, exactly as clients do with the same HW and possibly firmware. Whether this is true was the fundamental question of my initial mail.

 

Besides there have been other questions in my initial mail, where answers would still be desirable and where for sure there are expert participants in the hostap mailing list who have knowledge and are possibly prepared to give helpful answers. I take the freedom to repeat them here:

 

1.    Has ath9k become ready and stable for usage in a Linux based accesspoint?
      (hostap documents say, that madwifi is required, can madwifi be substituted by ath9k)

2.    What WLAN-Adapters supported by ath9k are available, with capabilities for WOWLAN (at least for clients)?

3.    Can a WLAN Client wake up its accesspoint over WLAN (see my reasoning above)?

4.    Can wake up be performed with both Magic Packet and Special Pattern (at least for waking up clients)?

 

Many thanks again for kind and helpful answers from anybody being knowledgeable in these topics.

 

Karl

 

 

 

 

 

 

>-----Original Message-----

>From: Johannes Berg [mailto:johannes <at> sipsolutions.net]

>Sent: Samstag, 26. Februar 2011 11:12

>To: karl <at> krothenhoefer.de

>Cc: hostap <at> lists.shmoo.com

>Subject: Re: Wake Accesspoint over WLAN

>

 

>On Fri, 2011-02-25 at 22:50 +0100, Karl Rothenhöfer wrote:

>

 

>> I want to implement a Wireless server based on Linux. If idle persists

>> for a longer time I would like the server to shutdown to standby in

>> order to save energy; and I would like to wake up the server over wlan

>> (WOWLAN) by clients requesting service.

>

 

>WoWLAN typically supports only clients staying connected to an AP while

>suspended and then being woken up.

>

 

>johannes

>

 

 

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 1 comment |
headers
Martinsson Patrik | 1 Mar 2011 13:40
Picon
Favicon

wpa_supplicant and dhclient.

Hello,

We use 802.X authentication with certificates stored on smart card, this seems to be working with wpa_supplicant, however I'm a bit confused when it comes to wpa_supplicant and the (if any) relation with dhclient.

Today we use NetworkManager to handle the connections, however NM is not able to pass the needed pkcs11 options to wpa_supplicant, and therefore I'm currently trying to use wpa_supplicant in "standalone" mode.

So the procedure today is basically,
- Stop NM.
- Stop dhclient (started by NM)
- Stop wpa_supplicant (started by NM)
- Start wpa_supplicant
- Start wpa_gui to connect and enter pin.
- Start dhclient on the interface we just brought up.

This feels rather messy, although as a sysadmin you can live with it, however as a regular user you can not.

Basically I have two questions,
- Since dhclient already is started by NM with dbussupport, why cant wpa_supplicant/gui talk to dhclient and request an ip when a successful connection is made, should I manually have to start dhclient whenever I've connected through wpa_supplicant, or am I missing something ?
- Does anybody have any suggestions at all how to make this easy and workable for a regular user ?

We use Rhel 6.
It's a shame that NM can't handle certificates stored on smart cards - that would have been the ultimate solution.

Patrik Martinsson

ITi

SMHI
Telefon 011 - 495 84 17 Fax 011 - 495 83 50
Mobil 011 - 495 84 17 Epost Patrik.Martinsson <at> smhi.se
601 76 Norrköping Besöksadress Folkborgsvägen 1
www.smhi.se 
_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 2 comments |
headers
Helmut Schaa | 2 Mar 2011 09:37

[PATCH] hostapd: Don't force HT Mixed Mode for non-GF STAs

Currently hostapd will force HT Mixed Mode if at least one non-GF STA is
associated. This will force _all_ HT transmissions to be protected.

802.11n-2009 doesn't require HT Mixed Mode to be used in case of non-GF
STAs but instead the HT information element contains a flag if non-GF
STAs are present. All STAs are required to protect GF transmissions in
that case. Hence, setting HT Mixed mode if non-GF STAs are present is
superfluous.

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

diff --git a/src/ap/ieee802_11_ht.c b/src/ap/ieee802_11_ht.c
index acb85fe..73e9a9f 100644
--- a/src/ap/ieee802_11_ht.c
+++ b/src/ap/ieee802_11_ht.c
 <at>  <at>  -131,13 +131,8  <at>  <at>  int hostapd_ht_operation_update(struct hostapd_iface *iface)
 		op_mode_changes++;
 	}

-	/* Note: currently we switch to the MIXED op mode if HT non-greenfield
-	 * station is associated. Probably it's a theoretical case, since
-	 * it looks like all known HT STAs support greenfield.
-	 */
 	new_op_mode = 0;
-	if (iface->num_sta_no_ht ||
-	    (iface->ht_op_mode & HT_INFO_OPERATION_MODE_NON_GF_DEVS_PRESENT))
+	if (iface->num_sta_no_ht)
 		new_op_mode = OP_MODE_MIXED;
 	else if ((iface->conf->ht_capab & HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET)
 		 && iface->num_sta_ht_20mhz)
--

-- 
1.7.1
Permalink | Reply | 14 comments |
headers
Johannes Berg | 2 Mar 2011 09:44
Favicon

Re: [PATCH] hostapd: Don't force HT Mixed Mode for non-GF STAs

On Wed, 2011-03-02 at 09:37 +0100, Helmut Schaa wrote:
> Currently hostapd will force HT Mixed Mode if at least one non-GF STA is
> associated. This will force _all_ HT transmissions to be protected.
> 
> 802.11n-2009 doesn't require HT Mixed Mode to be used in case of non-GF
> STAs but instead the HT information element contains a flag if non-GF
> STAs are present. All STAs are required to protect GF transmissions in
> that case. Hence, setting HT Mixed mode if non-GF STAs are present is
> superfluous.

It seems like this would still be relevant for the AP's TX?

johannes
Permalink | Reply | 9 comments |
headers
Helmut Schaa | 2 Mar 2011 09:53

Re: [PATCH] hostapd: Don't force HT Mixed Mode for non-GF STAs

Am Mittwoch, 2. März 2011 schrieb Johannes Berg:
> On Wed, 2011-03-02 at 09:37 +0100, Helmut Schaa wrote:
> > Currently hostapd will force HT Mixed Mode if at least one non-GF STA is
> > associated. This will force _all_ HT transmissions to be protected.
> > 
> > 802.11n-2009 doesn't require HT Mixed Mode to be used in case of non-GF
> > STAs but instead the HT information element contains a flag if non-GF
> > STAs are present. All STAs are required to protect GF transmissions in
> > that case. Hence, setting HT Mixed mode if non-GF STAs are present is
> > superfluous.
> 
> It seems like this would still be relevant for the AP's TX?

Why? hostapd will configure the new ht_opmode (including the non-GF-STA flag)
to the driver. And the driver should do the right thing and enable protection only
for GF transmissions in that case, no?

Helmut
Permalink | Reply | 8 comments |
headers
Johannes Berg | 2 Mar 2011 09:57
Favicon

Re: [PATCH] hostapd: Don't force HT Mixed Mode for non-GF STAs

On Wed, 2011-03-02 at 09:53 +0100, Helmut Schaa wrote:
> Am Mittwoch, 2. März 2011 schrieb Johannes Berg:
> > On Wed, 2011-03-02 at 09:37 +0100, Helmut Schaa wrote:
> > > Currently hostapd will force HT Mixed Mode if at least one non-GF STA is
> > > associated. This will force _all_ HT transmissions to be protected.
> > > 
> > > 802.11n-2009 doesn't require HT Mixed Mode to be used in case of non-GF
> > > STAs but instead the HT information element contains a flag if non-GF
> > > STAs are present. All STAs are required to protect GF transmissions in
> > > that case. Hence, setting HT Mixed mode if non-GF STAs are present is
> > > superfluous.
> > 
> > It seems like this would still be relevant for the AP's TX?
> 
> Why? hostapd will configure the new ht_opmode (including the non-GF-STA flag)
> to the driver. And the driver should do the right thing and enable protection only
> for GF transmissions in that case, no?

Not sure really, this HT stuff isn't as well defined as we'd like :-)
I'd suspect it doesn't.

johannes

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 7 comments |

Gmane