alfred steele | 1 Dec 03:08 2010
Picon

Re: Directed/Unicast probe to a specific BSSID

On Fri, Nov 19, 2010 at 5:43 PM, Jouni Malinen <j <at> w1.fi> wrote:

> No, this is not supported.

> Not only wpa_supplicant, but you may need to implement support for that
> in the driver and kernel interface for that matter..
Does this mean i have to add :
i) an extra member in the wpa_supplicant structure apart from creating
a new command/interface in wpa_supplicant on the same lines as the
existing ones in "scan.c"

To support  that, i have to add  the corresponding command support in
driver and the kernel wireless ext.
Is that what you mean.

Isn't there an existing generic wireless extension for doing a probe
based on whatever is populated in the wpa supplicant conf as BSSID?

Thanks,
Alfred.
Olsson, Ola1 | 1 Dec 16:55 2010

[wpa_supplicant] Most WPA AP:s dont get to WPA_4WAY_HANDSHAKE state when wrong PSK is supplied

Hi,

 

For most WPA AP:s when using supplicant 0.6 with driver_wext and supplying the wrong PSK, I don’t get the wpa_msg callback stating “pre-shared key may be incorrect” as the station is not in WPA_4WAY_HANDSHAKE state. There are APs where I actually do get this callback however…

According to the code, this is fully understandable as the wpa_supplicant_event_disassoc() in events.c is designed like this.

 

The behaviour I get in most cases is that I get my phone in state ASSOCIATING and then get EVENT_DISASSOC from wpa_driver_wext_event_wireless() in driver_wext.c after evaluating that the is_zero_ether_addr() evaluates to true.

 

My question is:

*Why don’t we treat this 00:00:00:00:00:00 mac address as erroneous PSK even though we are only in ASSOCIATING state? When changing the code in events.c to also send the callback when in ASSOCIATING, it works perfectly. I’m a little bit worried of the side effects though. Anybody who knows what might go wrong?

 

 

Br Ola

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Cainikov, Andrej | 2 Dec 11:49 2010

Is TTLS-NONE / TTLS-GTC actually working?

Hi,

We are working towards improvement of TTLS related issues with Android phones. During some analysis and
investigation we have found that none of the Androids from various vendors are working with TTLS-NONE and
TTLS-GTC, while there is no problems with other configurations like TTLS-PAP, TTLS-MD5 and
TTLS-MSCHAP. Basically, none of other phase 2 authentication options are working for TTLS as phase 1.
Surfing the internet for possible hints, all valuable info that can be found are standards and some Radius
configuration file examples, which we was unable to test even with laptop. Looking at the supplicant logs
it looks like it's trying to use different phase2 mechanism instead of GTC, which shows that this is
supplicant issue.

So, the actual question is.. Is actually anyone using TTLS-NONE or TTLS-GTC? Someone of you guys got it ever
working? How to test it? Links, configuration files for both Radius and supplicant (please state the
version) will be highly appreciated.

Thanks!

Best regards,
Andrejs.
Panagiotis Georgopoulos | 2 Dec 12:28 2010
Picon

Accounting info when using the internal hostapd's RADIUS functionality

Hello all,

 

                When I use hostapd’s internal RADIUS server functionality, is there any way to do accounting?

 

As far as I can tell from the archives of the list, hostapd does not store accounting information. Is there any add-on or other application that could store those? If not, what would be the easiest way to implement that (code-wise), ie. what source files should I start looking into ?

 

                Thanks a lot in advance,

                Panos

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Tomasz Bursztyka | 2 Dec 13:43 2010
Picon

WPS-enabled Bss and other WPS related questions

Hello,

I am currently figuring out which Bss provide WPS, and current situation 
seems to be to parse IEs buffer in Bss properties. No mention of wps is 
made anywhere else. Is that normal or am I missing something?

If parsing IEs is the only solution that's fine but:
- old dbus api used to provide "wpsie" for a bss and that was quite easy 
then to know wether or not a bss provided wps.
- would it be then relevant to reintroduce such property? (I could do 
the patch)

Also, Start() method from WPS interface provides association with (or 
not) bssid argument. It tends to be less obvious to use than by ssid. If 
I have 2 ap sharing same ssid, the two ones providing wps, then the 
easiest is to ask Start() without any bssid (since I might not be aware 
of their respective bssid). What if we could request Start() with an 
ssid argument, to filter out bss by ssid? If such argument would be 
provided with a bssid then only the bssid would matter and it would 
ignore the ssid, if ssid would be alone then we would filter out Bss 
based on that ssid.

Do you think it would be relevant to get such optional argument? (I 
could provide the patch also)

Best regards,

Tomasz
Dennis Borgmann | 2 Dec 14:06 2010

Re: Accounting info when using the internal hostapd's RADIUS functionality

Hi Panagiotis!

Just a few words on this - I use freeradius, since I've had problems
with hostapd's RADIUS implementation before. Maybe it is a bit
overloaded, but it works :-)

Kind regards,
Dennis Borgmann

Panagiotis Georgopoulos schrieb:
>
> Hello all,
>
>  
>
>                 When I use hostapd’s internal RADIUS server
> functionality, is there any way to do accounting?
>
>  
>
> As far as I can tell from the archives of the list, hostapd does not
> store accounting information. Is there any add-on or other application
> that could store those? If not, what would be the easiest way to
> implement that (code-wise), ie. what source files should I start
> looking into ?
>
>  
>
>                 Thanks a lot in advance,
>
>                 Panos
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
Johannes Berg | 2 Dec 16:03 2010
Picon

[PATCH] P2P: clear driver Probe Response IE on stop_listen

From: Johannes Berg <johannes.berg <at> intel.com>

Signed-off-by: Johannes Berg <johannes.berg <at> intel.com>
---
it seems like we should do this, but I'm not familiar with any driver
that'd require it ...

--- a/wpa_supplicant/p2p_supplicant.c
+++ b/wpa_supplicant/p2p_supplicant.c
 <at>  <at>  -1176,6 +1176,7  <at>  <at>  static void wpas_stop_listen(void *ctx)
 		wpa_s->off_channel_freq = 0;
 		wpa_s->roc_waiting_drv_freq = 0;
 	}
+	wpa_drv_set_ap_wps_ie(wpa_s, NULL, NULL, NULL);
 	wpa_drv_probe_req_report(wpa_s, 0);
 }
Panagiotis Georgopoulos | 2 Dec 16:21 2010
Picon

RE: Accounting info when using the internal hostapd's RADIUS functionality

Hello Dennis,

	Thanks for your reply! 

	I am also using freeRadius in my testbed but was thinking of getting a more lightweight authentication and
accounting implementation on the access point (hostapd), when it looses its connection to the Internet
(thus freeRadius).

	The other alternative would be to use freeRadius as proxy (with robust-proxy-accounting) on the access
point (as you suggested), but I was looking for something much more lightweight. I thought that since we
are able to do authentication with hostapd's internal Radius server, we could easily store accounting
information (after all, all these packets go through the AP) and process these stored accounting logs at a
much latter stage. 

	I would really have hoped that a simple solution would exist and avoid the overkill to run FR on the AP...

	Best Regards,
	Panos

> -----Original Message-----
> From: Dennis Borgmann [mailto:dennis.borgmann <at> googlemail.com]
> Sent: 02 December 2010 13:07
> To: Panagiotis Georgopoulos
> Cc: hostap <at> lists.shmoo.com
> Subject: Re: Accounting info when using the internal hostapd's RADIUS
> functionality
> 
> Hi Panagiotis!
> 
> Just a few words on this - I use freeradius, since I've had problems
> with hostapd's RADIUS implementation before. Maybe it is a bit
> overloaded, but it works :-)
> 
> Kind regards,
> Dennis Borgmann
> 
> Panagiotis Georgopoulos schrieb:
> >
> > Hello all,
> >
> >
> >
> >                 When I use hostapds internal RADIUS server
> > functionality, is there any way to do accounting?
> >
> >
> >
> > As far as I can tell from the archives of the list, hostapd does not
> > store accounting information. Is there any add-on or other
> application
> > that could store those? If not, what would be the easiest way to
> > implement that (code-wise), ie. what source files should I start
> > looking into ?
> >
> >
> >
> >                 Thanks a lot in advance,
> >
> >                 Panos
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > HostAP mailing list
> > HostAP <at> lists.shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap
> >
Holger Schurig | 2 Dec 16:43 2010
Picon

Re: Needs to disconnect from previous AP before associating to a new one?

> Hello Everyone,
> 
> I'm using Linux kernel 2.6.35. Looks like nl80211/cfg80211 directly
> returns -EALREADY if it is connected to any AP (in __cfg80211_connect
> function in net\wireless\sme.c). This will cause association to a new
> AP to fail unless you disconnect from the previous connected AP.
> Unfortunately Android does not do this... Has anyone got the same
> problem before and got a solution for it?

The solution is to fix android.

Just do the equivalent of "iw wlan0 disconnect" before re-connecting. To 
my best knowledge recent versions of wpa_supplicant do this 
automatically.

--

-- 
Homepage: http://www.holgerschurig.de
Holger Schurig | 2 Dec 16:50 2010
Picon

Re: Cannot connect to Deutsche Telekom Speedport with WPA

> > wpa_supplicant -ddddt -ctest.conf -ieth1 -Dwext 2&> out.log

What version of wpa_supplicant?
Which WLAN driver?
Which kernel version?
Why do you use the outdated wext?
Try it with -Dnl80211.

> > eth1      unassociated  ESSID:off/any  Nickname:"ipw2100"
> >           Mode:Managed  Channel=0  Access Point: Not-Associated
> >           Bit Rate:0 kb/s   Tx-Power:16 dBm
> >           Retry short limit:7   RTS thr:off   Fragment thr:off
> >           Encryption key:5350-2D58-3955-3044-3534-3772   Security 
mode:open

"iwconfig" doesn't have a good notion of being connected/disconnected. 
Try to use "iw" instead. Or, because you're using wpa_supplicant, use 
"wpa_cli status".

> > 1290757247.814007: Association request to the driver failed
> 
> Unfortunately, it doesn't tell me why.

But you should find out. Maybe you can use another computer, go into 
monitor mode on channel 9 and trace the data exchange. But it might as 
well work once you use the currently maintained interface.

> conf.txt

As you didn't say which driver you use, I cannot say if your "ap_scan=1" 
is correct. For example, if you ath5k, you won't need that anymore.

Also, a WPA or WPA2 passphrase must be at least 8 characters long. 
"secret" is too short.

For example, for wpa2 you could use:

network={
        ssid="Die3"
        scan_ssid=1
        key_mgmt=WPA-PSK
        psk="secretXXXX"
        proto=WPA2
        pairwise=CCMP
        group=CCMP
}

--

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

Gmane