headers
Jar | 1 Jul 2007 13:35
Picon
Picon

Invalid packet for Michael MIC warnings


I am using ccmp and now when I enabled also tkip, I can see the messages 
like this in my dmseg:

Invalid packet for Michael MIC add (tailroom=4 hdr_len=24 skb->len=1348)
wifi0: TX - encryption failed

Can be related to this: 
http://lists.shmoo.com/pipermail/hostap/2007-January/014941.html

What happened to that patch? Is that patch proper fix?

--

-- 
Best Regards, Jar
Permalink | Reply | 0 comments |
headers
Daniel Drake | 2 Jul 2007 16:48

Fix wpa_cli disconnect/reassociate race

It's possible to trigger a race with the following steps:

 1. start wpa_supplicant and wait for it to complete association
 2. run "wpa_cli disconnect" and wait for it to disconnect
 3. run "wpa_cli reassociate; wpa_cli disconnect"

At this point, wpa_cli will complete reassociation, effectively ignoring the
final disconnect command.

The reason behind this is that the reassociate command has already triggered
a scan before the disconnect command is processed. The disconnect command
puts the interface into disconnected state, but then the scan results come in
wpa_supplicant processes the results regardless, and decides to associate to
one of the networks.
---
 wpa_supplicant/ctrl_iface.c |    1 +
 wpa_supplicant/events.c     |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

I have also backported this to 0.5.x but I'll await review of this patch before
sending it on.

diff --git a/wpa_supplicant/ctrl_iface.c b/wpa_supplicant/ctrl_iface.c
index ae17511..a1e63bc 100644
--- a/wpa_supplicant/ctrl_iface.c
+++ b/wpa_supplicant/ctrl_iface.c
 <at>  <at>  -1263,6 +1263,7  <at>  <at>  char * wpa_supplicant_ctrl_iface_process(struct wpa_supplicant *wpa_s,
 		reply_len = wpa_supplicant_ctrl_iface_list_networks(
 			wpa_s, reply, reply_size);
 	} else if (os_strcmp(buf, "DISCONNECT") == 0) {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Timur Alperovich | 2 Jul 2007 17:07
Picon

both managed and master mode?

Hi,

I was wondering if it's possible to have a prism 2/2.5 card to be both in master and managed mode, i.e. have an interface in master mode as an AP and an interface that would associate with another AP, which is not necessarily on the same channel.

Thank you,
Timur

_______________________________________________
HostAP mailing list
HostAP <at> shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 0 comments |
headers
Noorul Ameen T | 3 Jul 2007 11:36
Picon

EAP-SIM on hostapd & wpa_supplicant

Hi,

I would like to test EAP-SIM with hardcoded triplet between hostapd
and wpa_supplicant. I am using hostapd(0.5.8) with internal
authentication server as AP
and wpa_supplicant(0.5.7)/madwifi as station.

Anyone can give you the configuration file for wpa_supplicant as well
as for hostapd?

- Ameen
Permalink | Reply | 0 comments |
headers
Jaume | 4 Jul 2007 18:45
Picon

wpa_supplicant WPA-EAP-TTLS configuration

Hi,

I'm trying to enable de EAP_TTLS option in my wpa_supplicant 0.4.9 but
i can't "make" it. Anybody can help me to find where is my error
please?

Thanks in advance!

my (.config)
------------------------------------------------------------------
 #.config
 CONFIG_DRIVER_WEXT=y
 #CONFIG_IEEE8021X_EAPOL=y
 # EAP-TLS
 CONFIG_EAP_TLS=y
 # EAP-TTLS
 CONFIG_EAP_TTLS=y
 # Include control interface for external programs, e.g, wpa_cli
 CONFIG_CTRL_IFACE=y

make error
 ------------------------------------------------------------------
crypto.o: In function `fips186_2_prf':
/tmp/wpa_supplicant-0.5.8/crypto.c:104: multiple definition of `fips186_2_prf'
sha1.o:/tmp/wpa_supplicant-0.5.8/sha1.c:408: first defined here
/usr/bin/ld: Warning: size of symbol `fips186_2_prf' changed from 409
in sha1.o to 565 in crypto.o
crypto.o: In function `sha1_vector':
/tmp/wpa_supplicant-0.5.8/crypto.c:82: multiple definition of `sha1_vector'
sha1.o:/tmp/wpa_supplicant-0.5.8/sha1.c:396: first defined here
/usr/bin/ld: Warning: size of symbol `sha1_vector' changed from 252 in
sha1.o to 88 in crypto.o
crypto.o: In function `md5_vector':
/tmp/wpa_supplicant-0.5.8/crypto.c:70: multiple definition of `md5_vector'
md5.o:/tmp/wpa_supplicant-0.5.8/md5.c:138: first defined here
/usr/bin/ld: Warning: size of symbol `md5_vector' changed from 542 in
md5.o to 88 in crypto.o
aes_wrap.o: In function `aes_encrypt':
/tmp/wpa_supplicant-0.5.8/aes.c:1074: multiple definition of `aes_encrypt'
crypto.o:/tmp/wpa_supplicant-0.5.8/crypto.c:172: first defined here
/usr/bin/ld: Warning: size of symbol `aes_encrypt' changed from 27 in
crypto.o to 9 in aes_wrap.o
aes_wrap.o: In function `aes_decrypt':
/tmp/wpa_supplicant-0.5.8/aes.c:1099: multiple definition of `aes_decrypt'
crypto.o:/tmp/wpa_supplicant-0.5.8/crypto.c:198: first defined here
/usr/bin/ld: Warning: size of symbol `aes_decrypt' changed from 27 in
crypto.o to 9 in aes_wrap.o
aes_wrap.o: In function `aes_decrypt_init':
/tmp/wpa_supplicant-0.5.8/aes.c:1086: multiple definition of `aes_decrypt_init'
crypto.o:/tmp/wpa_supplicant-0.5.8/crypto.c:184: first defined here
/usr/bin/ld: Warning: size of symbol `aes_decrypt_init' changed from
78 in crypto.o to 58 in aes_wrap.o
aes_wrap.o: In function `aes_encrypt_init':
/tmp/wpa_supplicant-0.5.8/aes.c:1061: multiple definition of `aes_encrypt_init'
crypto.o:/tmp/wpa_supplicant-0.5.8/crypto.c:158: first defined here
/usr/bin/ld: Warning: size of symbol `aes_encrypt_init' changed from
78 in crypto.o to 58 in aes_wrap.o
aes_wrap.o: In function `aes_decrypt_deinit':
/tmp/wpa_supplicant-0.5.8/aes.c:1105: multiple definition of
`aes_decrypt_deinit'
crypto.o:/tmp/wpa_supplicant-0.5.8/crypto.c:204: first defined here
aes_wrap.o: In function `aes_encrypt_deinit':
/tmp/wpa_supplicant-0.5.8/aes.c:1080: multiple definition of
`aes_encrypt_deinit'
crypto.o:/tmp/wpa_supplicant-0.5.8/crypto.c:178: first defined here
eap.o: In function `eap_sm_allowMethod':
/tmp/wpa_supplicant-0.5.8/eap.c:695: undefined reference to
`wpa_config_allowed_eap_method'
eap.o: In function `eap_sm_buildNak':
/tmp/wpa_supplicant-0.5.8/eap.c:803: undefined reference to
`wpa_config_allowed_eap_method'
eap.o: In function `eap_sm_build_expanded_nak':
/tmp/wpa_supplicant-0.5.8/eap.c:739: undefined reference to
`wpa_config_allowed_eap_method'
collect2: ld devolvió el estado de salida 1
make: *** [wpa_supplicant] Error 1
Permalink | Reply | 1 comment |
headers
Jouni Malinen | 4 Jul 2007 19:51
Picon

Re: wpa_supplicant WPA-EAP-TTLS configuration

On Wed, Jul 04, 2007 at 11:45:35AM -0500, Jaume wrote:

> I'm trying to enable de EAP_TTLS option in my wpa_supplicant 0.4.9 but
> i can't "make" it. Anybody can help me to find where is my error
> please?

> crypto.o: In function `fips186_2_prf':
> /tmp/wpa_supplicant-0.5.8/crypto.c:104: multiple definition of `fips186_2_prf'

Did you happen to change .config file and then run "make" without
cleaning up previous build? This function (like the other cases
mentioned in your list) are defined in multiple places and the build
configuration selects which one is used. If you change configuration,
you will need to clean the previous build ("make clean") before building
the new configuration.

--

-- 
Jouni Malinen                                            PGP id EFC895FA
Permalink | Reply | 0 comments |
headers
Andreas Wetzel | 4 Jul 2007 20:06
Picon

hostapd + freeRadius accounting

Hi,

I've installed hostapd and freeRadius on a FreeBSD 6.2-RELEASE machine.
The NAS-Port attribute that hostapd sends in the RADIUS packets happens
to always contain a value of 0. Additionally the Acct-Session-Id attribute
always contains '00000000-00000000'. This happens with the hostapd 0.4.8 that
is included with the FreeBSD release, as well as with v0.5.8.

Any ideas?

best regard, Andreas

--

-- 
Keep it icy man.
I don't want to end up a corpse before my time because you were daydreaming.
Permalink | Reply | 2 comments |
headers
Jouni Malinen | 4 Jul 2007 21:43
Picon

Re: hostapd + freeRadius accounting

On Wed, Jul 04, 2007 at 08:06:13PM +0200, Andreas Wetzel wrote:

> I've installed hostapd and freeRadius on a FreeBSD 6.2-RELEASE machine.
> The NAS-Port attribute that hostapd sends in the RADIUS packets happens
> to always contain a value of 0. Additionally the Acct-Session-Id attribute
> always contains '00000000-00000000'. This happens with the hostapd 0.4.8 that
> is included with the FreeBSD release, as well as with v0.5.8.

NAS-Port is set to the Association ID, if one is available. However, it
is not available when using FreeBSD which takes care of IEEE 802.11
association. If it would be important to get this stored (though, I
don't really see much value for it at the RADIUS server), this would
need an addition to FreeBSD net80211 to allow the association ID to be
read (or to make it automatically reported as part of association
event).

Lack of proper Acct-Session-Id looks like a bug in the FreeBSD driver
wrapper code. bsd_new_sta() function should call
accounting_sta_get_id(hapd, sta) in the same way as driver_madwifi.c is
doing in madwifi_new_sta().

--

-- 
Jouni Malinen                                            PGP id EFC895FA
Permalink | Reply | 1 comment |
headers
Andreas Wetzel | 4 Jul 2007 22:08
Picon

Re: hostapd + freeRadius accounting

Jouni Malinen wrote:
> On Wed, Jul 04, 2007 at 08:06:13PM +0200, Andreas Wetzel wrote:
> 
>> I've installed hostapd and freeRadius on a FreeBSD 6.2-RELEASE machine.
>> The NAS-Port attribute that hostapd sends in the RADIUS packets happens
>> to always contain a value of 0. Additionally the Acct-Session-Id attribute
>> always contains '00000000-00000000'. This happens with the hostapd 0.4.8 that
>> is included with the FreeBSD release, as well as with v0.5.8.
> 
> NAS-Port is set to the Association ID, if one is available. However, it
> is not available when using FreeBSD which takes care of IEEE 802.11
> association.

I guess the association ID would be sta->aid, right? The weird part is,
when I insert a printf that outputs sta->aid at the time of association,
I get the following:

1st station associates:

hostapd: ath0: STA 00:19:e0:83:b0:41 IEEE 802.11: associated (aid=1)

2nd station associates:

hostapd: ath0: STA 00:14:78:7d:51:2c IEEE 802.11: associated (aid=32001)

NAS-Port, which seems to use sta->aid though is always 0.
Which part am I missing?

 > If it would be important to get this stored (though, I
 > don't really see much value for it at the RADIUS server), this would
 > need an addition to FreeBSD net80211 to allow the association ID to be
 > read (or to make it automatically reported as part of association
 > event).

freeradius uses a combination of the NAS-IP-Address and the NAS-Port as
the key to store utmp style entries with the radutmp module. With NAS-Port
being always zero, each station that signs on, overwrites the entry of the
last station :-(

> Lack of proper Acct-Session-Id looks like a bug in the FreeBSD driver
> wrapper code. bsd_new_sta() function should call
> accounting_sta_get_id(hapd, sta) in the same way as driver_madwifi.c is
> doing in madwifi_new_sta().

I also tried passing an Acct-Session-Id in the Access-Accept message to
hostapd, but that is ignored by hostapd.

Andreas
--

-- 
Keep it icy man.
I don't want to end up a corpse before my time because you were daydreaming.
Permalink | Reply | 0 comments |
headers
Stefano Paris | 6 Jul 2007 10:58
Picon
Favicon

Hostapd and madwifi interaction

Hi 
i'm an University researcher, working with wireless devices. I employ
hostapd with madwifi drivers, since i use atheros based cards, and i
have a couple of doubts regarding the interaction between the drivers
and hostapd (0.5.8) itself. 
In particular, do hostapd configurations override madwifi
configurations? Some examples: 
- if i set up a wep key with the "iwconfig ath0 key s:goofy" command
(i.e. using the madwifi drivers), should i also add such "goofy" key to
the hostapd.conf file? what happens if i don't? and if i do, will i be
able to change the key without restarting the hostapd daemon (i ask this
since i'm wondering about periodically changing the wep key for security
reasons, because I'm using the madwifi ad-hoc mode that seems to support
only the wep security framework)? 
- if i tell hostapd.conf that channel=60 (therefore hw_mode=a), am i
allowed to change the channel through the wireless tools without
restarting hostapd? 

Moreover, does hostapd keep an "associated station list" separate from
the madwifi "associated station list"? I did set ap_max_inactivity=30 in
order to have the ap consider gone a station that does not send or ack
any frame for 30 seconds; then i performed a mobility test, moving
(through the iwconfig ath0 ap new_mac_ap) the station from an ap to a
new_ap, both of which running hostapd, and by observing the madwifi
"associated stations list" on the old ap (through the "watch -n1
wlanconfig ath0 list sta" command) i didn't see it vanish from the old
ap. I actually saw it for a long period of time (around 5 minutes,
maybe) associated to both aps.... Is it an hostapd configuration
problem?

Thanks in advance for your kind answers 
Best Regards
Stefano Paris
Permalink | Reply | 0 comments |

Gmane