headers
Masashi Honma | 2 Jun 2009 08:30
Picon

[PATCH] Fix: EAPOL frame handling timing problem

Hello.

I couldn't complete WPA 4-way handshake.
I've gotten some messages

WPA: Could not verify EAPOL-Key MIC - dropping packet
WPA: Could not verify EAPOL-Key MIC - dropping packet
WPA: Could not verify EAPOL-Key MIC - dropping packet
WPA: Could not verify EAPOL-Key MIC - dropping packet
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys

in wpa_supplicant_verify_eapol_key_mic function.

I have investigated this and I found out association event
handling occured later than first EAPOL-key frame (from AP)
handling on my own environment.
This was not mean the real wireless frame came with this order.
I watched captured wireless frame, and checked that the order was correct.

In the other words, wpa_sm_notify_assoc function call happens
later than wpa_supplicant_process_1_of_4. 
Therefore sm->tptk_set is unexpectedly set to 0.

So I made below patch and I could connect stably.

diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index d03e9da..4d85050 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
 <at>  <at>  -1627,7 +1627,11  <at>  <at>  void wpa_supplicant_rx_eapol(void *ctx, const u8 *src_addr,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando | 2 Jun 2009 11:14
Picon
Favicon

Re: association time

Jouni Malinen escribió:
> On Thu, May 21, 2009 at 05:36:54PM +0200, Fernando wrote:
>
>   
>> Is possible to configure hostapd to allow an station to be only 
>> associated X time?
>>     
>
> What exactly do you mean with that? To disassociate a station after X
> seconds regardless of whether it uses the connection to transmit data or
> not?
Yes, for example, if the station is 10 seconds connect disassociate it.
>  And then? Allow the station to associate again immediately? Or
> reject associations from it for some time (how long?)?
>   
Reject associations for example for 120 seconds.

There is some mechanism to carry out it?
> There is currently couple of mechanisms related to timing out the
> association. Neither of these may not meet your exact expectation, but
> at least they are likely to do something similar.
>
> ap_max_inactivity parameter in hostapd.conf can be used to define a
> station inactivity limit (see hostapd.conf for more details). When using
> a RADIUS authentication server, Session-Timeout attribute can be used to
> set up a limit for the duration of the session. Both of these allow the
> station to try to associate again (which, in case of RADIUS
> authentication, could be denied by the RADIUS server).
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paresh Sawant | 3 Jun 2009 07:28
Picon

kernel subsystems

Hi,

What is the difference in mac80211 and ieee80211 subsystems?

what is the functionality performed by these subsystems ?

In future, nl80211 is going to replace the wext, then what is going to be the  underneath subsystem?

Regards
- Paresh

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 3 comments |
headers
santosh kumar upadhyaya | 3 Jun 2009 09:21
Favicon

Using Internal TLS for HTTPS

Hi All,
I am using wpa supplicant(wpa_supplicant-0.6.9) on Embedded Platform.
I could make EAP-TLS work using internal TLS for the embedded platform.

Now , I am trying make HTTPS client using internal TLS.

Does any one have any information about this ??
Is it possible to do HTTPS client using Internal TLS ??

Regards
Santosh




_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 1 comment |
headers
Dan Williams | 3 Jun 2009 14:45
Picon
Favicon

Re: kernel subsystems

On Wed, 2009-06-03 at 10:58 +0530, Paresh Sawant wrote:
> Hi,
> 
> What is the difference in mac80211 and ieee80211 subsystems?

mac80211 is a softmac stack, it performs all 802.11 management and data
functions in software.

ieee80211 is more of a helper library and doesn't implement much of the
management function in software, leaving stuff like auth/assoc,
beaconing, etc to the firmware.  As such, it's kind of "halfmac".

> In future, nl80211 is going to replace the wext, then what is going to
> be the  underneath subsystem?

nl80211/cfg80211 will replace wext, yes.  They are independent of the
underlying 802.11 stack, but are simply a mechanism to *configure* the
parameters of that stack.  As such, nl80211/cfg80211 can be used with
any driver.  There are proof-of-concept cfg80211 patches for orinoco
cards (really popular old FullMAC cards) already, and it's expected that
most of the drivers in the kernel will be ported over to cfg80211
eventually.

This will provide a consistent configuration interface, which is the
huge problem with WEXT.  Every driver implements WEXT a little
differently, leading to tons of workarounds in wifi control programs
like wpa_supplicant and NetworkManager.  cfg80211 will fix all that by
providing a WEXT compatbility layer, so all drivers that use cfg80211
will work pretty much the same.

Dan
Permalink | Reply | 2 comments |
headers
Michael Kurecka | 3 Jun 2009 18:05
Picon

Integrated server operation?

Is the eap_mschapv2.c and eap_peap.c classes in the src/eap_server directory for use with the integrated server for hostapd? I setup a client to use PEAP/MSCHAPv2 and none of the methods were used from these two classes except to register.

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 1 comment |
headers
Paresh Sawant | 3 Jun 2009 20:36
Picon

Re: kernel subsystems

Thanks for the information !

So the mac80211 subsystems could be utilized as a (driver) API to develop a driver for a given chipset?

And what kind of details one would need to develop the driver using mac80211?

- Paresh

On Wed, Jun 3, 2009 at 6:15 PM, Dan Williams <dcbw <at> redhat.com> wrote:
On Wed, 2009-06-03 at 10:58 +0530, Paresh Sawant wrote:
> Hi,
>
> What is the difference in mac80211 and ieee80211 subsystems?

mac80211 is a softmac stack, it performs all 802.11 management and data
functions in software.

ieee80211 is more of a helper library and doesn't implement much of the
management function in software, leaving stuff like auth/assoc,
beaconing, etc to the firmware.  As such, it's kind of "halfmac".

> In future, nl80211 is going to replace the wext, then what is going to
> be the  underneath subsystem?

nl80211/cfg80211 will replace wext, yes.  They are independent of the
underlying 802.11 stack, but are simply a mechanism to *configure* the
parameters of that stack.  As such, nl80211/cfg80211 can be used with
any driver.  There are proof-of-concept cfg80211 patches for orinoco
cards (really popular old FullMAC cards) already, and it's expected that
most of the drivers in the kernel will be ported over to cfg80211
eventually.

This will provide a consistent configuration interface, which is the
huge problem with WEXT.  Every driver implements WEXT a little
differently, leading to tons of workarounds in wifi control programs
like wpa_supplicant and NetworkManager.  cfg80211 will fix all that by
providing a WEXT compatbility layer, so all drivers that use cfg80211
will work pretty much the same.

Dan



_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 1 comment |
headers
Dan Williams | 3 Jun 2009 22:33
Picon
Favicon

Re: kernel subsystems

On Thu, 2009-06-04 at 00:06 +0530, Paresh Sawant wrote:
> Thanks for the information !
> 
> So the mac80211 subsystems could be utilized as a (driver) API to
> develop a driver for a given chipset?

Yes.

> And what kind of details one would need to develop the driver using
> mac80211?

The documentation or spec for the chipset of course.  Then develop using
the existing drivers.  The 'libertastf' driver is probably a pretty
simple driver to look at for starts.  You'll probably want to jump over
to linux-wireless <at> vger.kernel.org since that's the list where Linux
wireless development is discussed, and where the mac80211 developers
hang out.

Dan

> - Paresh
> 
> On Wed, Jun 3, 2009 at 6:15 PM, Dan Williams <dcbw <at> redhat.com> wrote:
>         On Wed, 2009-06-03 at 10:58 +0530, Paresh Sawant wrote:
>         > Hi,
>         >
>         > What is the difference in mac80211 and ieee80211 subsystems?
>         
>         
>         mac80211 is a softmac stack, it performs all 802.11 management
>         and data
>         functions in software.
>         
>         ieee80211 is more of a helper library and doesn't implement
>         much of the
>         management function in software, leaving stuff like
>         auth/assoc,
>         beaconing, etc to the firmware.  As such, it's kind of
>         "halfmac".
>         
>         > In future, nl80211 is going to replace the wext, then what
>         is going to
>         > be the  underneath subsystem?
>         
>         
>         nl80211/cfg80211 will replace wext, yes.  They are independent
>         of the
>         underlying 802.11 stack, but are simply a mechanism to
>         *configure* the
>         parameters of that stack.  As such, nl80211/cfg80211 can be
>         used with
>         any driver.  There are proof-of-concept cfg80211 patches for
>         orinoco
>         cards (really popular old FullMAC cards) already, and it's
>         expected that
>         most of the drivers in the kernel will be ported over to
>         cfg80211
>         eventually.
>         
>         This will provide a consistent configuration interface, which
>         is the
>         huge problem with WEXT.  Every driver implements WEXT a little
>         differently, leading to tons of workarounds in wifi control
>         programs
>         like wpa_supplicant and NetworkManager.  cfg80211 will fix all
>         that by
>         providing a WEXT compatbility layer, so all drivers that use
>         cfg80211
>         will work pretty much the same.
>         
>         Dan
>         
>         
> 
> _______________________________________________
> HostAP mailing list
> HostAP <at> lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
Permalink | Reply | 0 comments |
headers
gokulnatha | 5 Jun 2009 13:55
Picon
Favicon

kernel panic is coming in Repeater mode while upgrading hostapd 0.4.8 to 0.6.9


--- On Sun, 31/5/09, Pavel Roskin <proski <at> gnu.org> wrote:

> From: Pavel Roskin <proski <at> gnu.org>
> Subject: Re: kernel panic is coming in Repeater mode while upgrading hostapd 0.4.8 to 0.6.9
> To: "gokulnath A" <gokulnatha <at> yahoo.co.in>
> Cc: hostap <at> lists.shmoo.com
> Date: Sunday, 31 May, 2009, 3:25 AM
> On Sat, 2009-05-30 at 13:09 +0530,
> gokulnath A wrote:
> > hi all...
> >   
> >    I have upgraded the hostapd version 0.4.8
> to 0.6.9 in my atheros
> > based chipset. I am using Madwifi Wirless driver
> .  i have set
> > Repeater Mode with first Vap as managed mode and
> Second Vap as Master
> > mode . While setting WPA, WPA2 , WPA-PSK, WPA2-PSK,
> WPA-auto,
> > WPA2-auto anyone of the security settings in VAP2 ,
> kernel panic is
> > coming after reboot . Please help me to solve this
> issue.
> > 
> > But setting in VAP1 have no problem. Only VAP2 having
> the kernel panic
> > problem. 
> 

> Userspace software such as hostapd or wpa_supplicant cannot
> be held
> responsible for kernel panics.
> 
> Kernel panic is a kernel issue and should be reported as
> such, that is,
> to the list about the appropriate driver (MadWifi in this
> case),
> complete with the versions of the software involved (kernel
> and MadWifi)
> and the backtrace from the kernel log.

hi .

  The kernel panic is coming when i upgrade the hostapd to 0.6.9. In the version i previously used is 0.4.8.In
that version there is no  kernel panic and the system works fine. if it is not a hostapd issue then the panic
should come in 0.4.8 version . But in my case its not coming . 

And In the System Kernel(linux-2.4.25) , Wireless Driver (madwifi-ng),  I didn't change anything in that . 

As i said when Vap2 entered promiscuous mode its try to get the security settings. there only kernel panic starts.
here is kernel log :
<6>device ath1 entered promiscuous mode
<6>device ath2 entered promiscuous mode
<4>unexpected operating mode 1Break instruction in kernel code in traps.c::do_bp, line 591:
<4>$0 : 00000000 1000ed00 0000001b 00000001 80158898 00000000 1000ed00 00000031
<4>$8 : 00000000 00000000 00000001 80164aeb fffffffb ffffffff 0000000a 00000000
<4>$16: 81c88160 81f04000 81d28160 81d28ae0 c04aa8d0 00000001 00000000 00000001
<4>$24: 81fa9cb8 80164ecf                   81fa8000 81fa9d98 00000000 c049b344
<4>Hi : 00000000
<4>Lo : 0000000a
<4>epc   : c049b344    Tainted: P
<4>Status: 1000ed03
<4>Cause : 10800024
<4>PrId  : 00018009
<4>Process hostapd (pid: 470, stackpage=81fa8000)
<4>Stack:    00000059 00000001 81fa9ea0 81fa9ea0 81c82b20 800b8c60 81f04000
<4> 00000001 81d28ae0 81fa9ea0 c04aa8d0 c04aa924 8104d200 80029a98 000001f0
<4> 800b87ec 81f04000 c049a534 8013c420 81fc1d80 81f9015c 81fc1d80 81fa9ea4
<4> 81d28160 81fa9ea0 c04aa9b8 00000000 c04aab30 00000000 10000ba8 00000000
<4> 00000001 00000000 00000000 8013c420 00457450 81c58000 00008be6 81fa9e90
<4> 800c7220 ...
<4>Call Trace:   [<800b8c60>] [<c04aa8d0>] [<c04aa924>] [<80029a98>] [<800b87ec>]
<4> [<c049a534>] [<c04aa9b8>] [<c04aab30>] [<800c7220>] [<80024940>] [<80024908>]
<4> [<800bef30>] [<800b5cb0>] [<800b5c64>] [<80052954>] [<800fc5e4>] [<800b54b8>]
<4> [<8004ccb4>] [<800b5ad0>] [<80009664>]
<4>
<4>Code: 24422f0c  0040f809  00000000 <0200000d> 08126c3a  9622002c  9487002c  8c83001c  24850179 
<0>Kernel panic: Aiee, killing interrupt handler!
<0>In interrupt handler - not syncing

Regards , 

Goks

      Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/
Permalink | Reply | 501 comments |
headers
Jouni Malinen | 5 Jun 2009 16:29
Picon

Re: Using Internal TLS for HTTPS

On Wed, Jun 03, 2009 at 07:21:05AM -0000, santosh kumar upadhyaya wrote:

> I am using wpa supplicant(wpa_supplicant-0.6.9) on Embedded Platform.
> I could make EAP-TLS work using internal TLS for the embedded platform.
> 
> Now , I am trying make HTTPS client using internal TLS.
> 
> Is it possible to do HTTPS client using Internal TLS ??

In theory, you could do this if you are willing to implement the TLS
socket integration for the HTTPS client. However, the feature set
supported in the internal TLS code is limited to whatever is needed to
support EAP methods and that may not meet the needs of your use case for
HTTPS. For example, only TLS 1.0 is supported (i.e., no support for SSL
3.0) and that may result in not being able to connect to all HTTPS
servers.

--

-- 
Jouni Malinen                                            PGP id EFC895FA
Permalink | Reply | 0 comments |

Gmane