2008 vpn | 1 Sep 2011 03:52
Picon

What's the reason for "OpenSSL: openssl_handshake - SSL_connect error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher"



  I'm try eap-fast method.
   But error happens:
   4c e8 59 6b 27
   EAP-FAST: server_random - hexdump(len=32): 4e 5d da af 1f eb a8 e0 fa c6 27
   89 e5 70 a3 fb 11 19 7a 4c c6 20 77 69 de 4b cd 38 b9 d8 40 dd
   EAP-FAST: master_secret - hexdump(len=48): [REMOVED]
   SSL: (where=0x4008 ret=0x228)
   SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake
   failure
   SSL: (where=0x2002 ret=0xffffffff)
   SSL: SSL_accept:error in SSLv3 read client hello C
   OpenSSL: openssl_handshake - SSL_connect error:1408A0C1:SSL
   routines:SSL3_GET_CLIENT_
HELLO:no shared cipher
   SSL: 7 bytes pending from ssl_out
   SSL: Failed - tls_out available to report error
   EAP-FAST: TLS processing failed
   EAP-FAST: PHASE1 -> FAILURE
   EAP: EAP entering state SELECT_ACTION
   EAP: getDecision: method failed -> FAILURE
   EAP: EAP entering state FAILURE
   EAP: Building EAP-Failure (id=116)
   What does this mean?  Is my config wrong?




   My Config file is as following:
   interface=eth2
   driver=wired
   logger_stdout=-1
   logger_stdout_level=1
   debug=2
   dump_file=/tmp/hostapd.dump
   ctrl_interface=/var/run/hostapd

   ieee8021x=1
   eap_server=1
   eap_user_file=/home/test/work/eap-fast/hostapd/hostapd-0.7.3/hostapd/hostapd.eap_user.wired
   eap_reauth_period=3600
   dh_file=/etc/hostapd/hostapd.dh.pem
   use_pae_group_addr=1
   pac_opaque_encr_key=000102030405060708090a0b0c0d0e0f

   eap_fast_a_id=201112131415161718191a1b1c1d1e1f
   eap_fast_a_id_info=test server

   eap_fast_prov=3
   pac_key_lifetime=604800
   pac_key_refresh_time=86400

   ##### RADIUS configuration
   ####################################################
   # for IEEE 802.1X with external Authentication Server, IEEE 802.11
   # authentication with external ACL for MAC addresses, and accounting

   # The own IP address of the access point (used as NAS-IP-Address)
   own_ip_addr=127.0.0.1

   # RADIUS authentication server
   auth_server_addr=127.0.0.1
   auth_server_port=1812
   auth_server_shared_secret=radius*


  And the content of hostapd.eap_user.wired is:
   # Phase 1 users
   "user"          MD5     "password"
   "test user"     MD5     "secret"
   "FAST-000102030405" FAST

   # Phase 2 (tunnelled within EAP-PEAP or EAP-TTLS) users
   "t-md5"         MD5     "password"      [2]
   "DOMAIN\t-mschapv2"     MSCHAPV2        "password"      [2]
   "t-gtc"         GTC     "password"      [2]
   "not anonymous" MSCHAPV2        "password"      [2]
   "user"          MD5,GTC,MSCHAPV2        "password"      [2]
   "test user"     MSCHAPV2        hash:000102030405060708090a0b0c0d0e0f   [2]
   "ttls-user"     TTLS-PAP,TTLS-CHAP,TTLS-MSCHAP,TTLS-MSCHAPV2
   "password"      [2]


   Config for wpa_supplicant is:
   ctrl_interface=/var/run/wpa_supplicant

   ctrl_interface_group=root

   ap_scan=0
   fast_reauth=1
   network={
   ssid=""
   scan_ssid=0
   key_mgmt=IEEE8021X
   eap=FAST
   identity="user"
   password="password"
   anonymous_identity="FAST-000102030405"
           phase1="fast_provisioning=1"
           pac_file="/etc/wpa_supplicant.eap-fast-pac"

   }

   I noticed we should config certificate file for EAP-TLS/PEAP/TTLS.
   But do we need config certificate file for EAP-FAST?


   Best Regards.

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
| 1 Sep 2011 06:44
Picon

Re: wpa_supplicant messes with keyboard

2011/8/29 Klaus Müller <kmueller <at> justmail.de>:
> Zé schrieb:
>> 2011/8/29 Klaus Müller <kmueller <at> justmail.de>:
>>> Zé schrieb:
>>> [...]
>>>> That doesnt make much sense since when i kill wpa_supplicant the
>>>> referred problems simply disappear.
>>
>> The problems starts happening when wpa-supplicant runs, and it
>> continues afecting the mouse and the keyboard and not just the
>> keyboard when using from git like i referred in previous comments.
>>
>> So this problem can be triggered by th wifi driver?
>
> wpa_supplicant has to start the hardware with the driver. If you stop
> wpa_supplicant, the hardware is stopped again (by wpa_supplicant).
> That's why it could be a driver issue.
>
>> when running dmesg it shows too much outputs of the wifi driver
>> (almost like a loop).
>
> This sounds bad.
>
>> But im attaching the ddesg output.
>>
>>> Surely. Which hardware / driver do you use? Which kernel (version)?
>>> 32/64 bit? Do you use compat-wireless (which version)?
>>
>> Currently im running a kernel-3.0.3 and its 64bits.
>> Since i remember using wpa_supplicant this always happened, no matter
>> if i used kernel-2.6.38 or the 3.0.x versions.
>>
>> This is the wifi driver:
>> rtl8192ce: Realtek Semiconductor Co., Ltd.|Device 8176 [NETWORK_OTHER]
>> (vendor:10ec device:8176 subv:10ec subd:9196) (rev: 01)
>
>
> According http://pci-ids.ucw.cz/read/PC/10ec/8176 ..., it's a Realtek
> RTL8188CE 802.11b/g/n WiFi Adapter
> (http://pci-ids.ucw.cz/read/PC/10ec/8176).
>
> I don't know, which driver you're really using. I would try
> the official driver (if you not already use it). You can get it here
> (one line):
>
> http://218.210.127.131/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8188CE
>
> According this entry, this driver should work (one line again):
> http://www.backtrack-linux.org/forums/hardware-compatibility-list/34817-realtek-rtl8188ce.html
>
>
> Klaus
>

Well i have installed the latest official driver from Realtek and
seams to have resolved some but not all.

When booting and after log in i see that theres 2 wpa_supplicant
instances running and im still with those problems, mouse hanging, and
keyboard repeating, but if i kill the wpa_supplicant triggered by
initscripts and stay only with the wpa_supplicant instance triggered
by NetworkManager than the mouse and keyboard behave fine.

So the initscript that calls wpa_supplicant is
/etc/sysconfig/network-scripts/ifup-eth and runs:

wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf -D wext

and seams due to this instance that mouse and keyboard continue with
that weird behaviour.

Can anyone comment?

--

-- 
Zé
Janusz Dziedzic | 1 Sep 2011 07:17
Picon

Re: wpa_supplicant roaming question

2011/8/31 Matt Causey <matt.causey <at> gmail.com>:
> Ha!  Yeah that's pretty lame on my part.  I was convinced that I'd
> configured the supplicant properly at compile time, but alas I was
> wrong.  I went back and re-compiled and now it works as expected.  :-)
>
> I have another question now...I notice that if the supplicant
> processes a disassociation or deauth, we call
> wpa_supplicant_event_disassoc() (in blacklist.c), which then adds that
> BSSID to a blacklist.  Then, the supplicant can no longer roam to that
> BSSID, even if it is a better choice.
>
> In our use case, we have a large number of access points and they can
> drop offline for maintenance periodically.  What would folks recommend
> we do to keep these BSSID's from becoming permanently blacklisted just
> because they needed to reboot?
>

Seems this is true. Blacklist will be cleared if "No APs found".

In case of our implementation we don't hit this problem. We have
additional CQM signal - beacon_miss - from our driver (nl80211). Count
of beacon_miss is configurable from supplicant when bgscan starts. Our
firmware support this beacon_miss detection - so, it is usefull - we
can roam before deauthenitcation in case someone will switch off AP or
we loose connection.
I think we will push this CQM cfg80211/nl80211 compat-wireless +
hostap implementation soon.

So, in case someone will switch off AP, before we will get
deauthentication we get this beacon_miss event and we have chance to
roam to another APs. If there isn't another APs blacklist will be
cleared because of "No APs found".

BR
Janusz
Helmut Schaa | 1 Sep 2011 09:00

Re: Michael MIC Failure Report with CCMP?

On Fri, Aug 26, 2011 at 5:27 PM, Helmut Schaa
<helmut.schaa <at> googlemail.com> wrote:
> I've got a client connected to hostapd that is sending a Michael MIC
> Failure Report to a CCMP-only AP after the group key handshake:

JFI the client in question is an Axis 207MW webcam [1].
Helmut

[1] http://www.axis.com/de/products/cam_207mw/
Janusz Dziedzic | 1 Sep 2011 10:00
Picon

Re: [RFC] p2p: disable 11b rates on p2p interface creation

2011/8/29 Rajkumar Manoharan <rmanohar <at> qca.qualcomm.com>:
> On Wed, Aug 17, 2011 at 12:59:20AM +0530, Rajkumar Manoharan wrote:
>> 11b rates are disabled blindly during p2p init based on driver
>> capability. This prevents use of CCK rates when no p2p vif
>> is present. This patch disables 11b rates while creating p2p
>> interface.
>>
>> Signed-off-by: Rajkumar Manoharan <rmanohar <at> qca.qualcomm.com>
>> ---
>>  src/drivers/driver.h            |    4 ++--
>>  src/drivers/driver_nl80211.c    |   17 ++++++++++++-----
>>  wpa_supplicant/driver_i.h       |    6 ++----
>>  wpa_supplicant/p2p_supplicant.c |    5 +----
>>  4 files changed, 17 insertions(+), 15 deletions(-)
>>
> Any comments are welcome.
>

Hello,
What with p2p_find - we should not use B-rates there - before connection.
Does you patch cover this case also?

BR
Janusz
Johannes Berg | 1 Sep 2011 14:15
Favicon

Re: [RFC] p2p: disable 11b rates on p2p interface creation

On Thu, 2011-09-01 at 10:00 +0200, Janusz Dziedzic wrote:
> 2011/8/29 Rajkumar Manoharan <rmanohar <at> qca.qualcomm.com>:
> > On Wed, Aug 17, 2011 at 12:59:20AM +0530, Rajkumar Manoharan wrote:
> >> 11b rates are disabled blindly during p2p init based on driver
> >> capability. This prevents use of CCK rates when no p2p vif
> >> is present. This patch disables 11b rates while creating p2p
> >> interface.
> >>
> >> Signed-off-by: Rajkumar Manoharan <rmanohar <at> qca.qualcomm.com>
> >> ---
> >>  src/drivers/driver.h            |    4 ++--
> >>  src/drivers/driver_nl80211.c    |   17 ++++++++++++-----
> >>  wpa_supplicant/driver_i.h       |    6 ++----
> >>  wpa_supplicant/p2p_supplicant.c |    5 +----
> >>  4 files changed, 17 insertions(+), 15 deletions(-)
> >>
> > Any comments are welcome.
> >
> 
> Hello,
> What with p2p_find - we should not use B-rates there - before connection.
> Does you patch cover this case also?

No, that still needs work on the scanning settings stuff.

johannes
Matt Causey | 1 Sep 2011 14:40
Picon

Re: wpa_supplicant roaming question

On Thu, Sep 1, 2011 at 1:17 AM, Janusz Dziedzic
<janusz.dziedzic <at> gmail.com> wrote:
> 2011/8/31 Matt Causey <matt.causey <at> gmail.com>:
>> Ha!  Yeah that's pretty lame on my part.  I was convinced that I'd
>> configured the supplicant properly at compile time, but alas I was
>> wrong.  I went back and re-compiled and now it works as expected.  :-)
>>
>> I have another question now...I notice that if the supplicant
>> processes a disassociation or deauth, we call
>> wpa_supplicant_event_disassoc() (in blacklist.c), which then adds that
>> BSSID to a blacklist.  Then, the supplicant can no longer roam to that
>> BSSID, even if it is a better choice.
>>
>> In our use case, we have a large number of access points and they can
>> drop offline for maintenance periodically.  What would folks recommend
>> we do to keep these BSSID's from becoming permanently blacklisted just
>> because they needed to reboot?
>>
>
> Seems this is true. Blacklist will be cleared if "No APs found".
>
> In case of our implementation we don't hit this problem. We have
> additional CQM signal - beacon_miss - from our driver (nl80211). Count
> of beacon_miss is configurable from supplicant when bgscan starts. Our
> firmware support this beacon_miss detection - so, it is usefull - we
> can roam before deauthenitcation in case someone will switch off AP or
> we loose connection.
> I think we will push this CQM cfg80211/nl80211 compat-wireless +
> hostap implementation soon.
>
> So, in case someone will switch off AP, before we will get
> deauthentication we get this beacon_miss event and we have chance to
> roam to another APs. If there isn't another APs blacklist will be
> cleared because of "No APs found".
>

Interesting.  So you have events that get processed before a deauth
happens.  Even with that, it is only a matter of time before your
client receives a deauth for some other reason that does not correlate
with a missed beacon, and then you will be vulnerable to the same
issue.

This functionality as it stands is a show-stopper for us so I've
commented out the call to wpa_blacklist_add()
(http://hostap.epitest.fi/wpa_supplicant/devel/blacklist_8c.html#af59c8fe6b0bef5b49f433bd06b29e9ab).
 I kind of wish that we could at least configure this behavior because
it's pretty broken currently.  I can see the rationale...the idea is
that if a BSSID is impaired in some way, but is the strongest BSSID
for a network, then clients will go there and have a bad experience.
Unfortunately I think that the heuristic needs more work.

Now, it may be that I can get ath9k to produce similar events that
prevent the supplicant from processing the deauth, thus preventing the
bug in the same way you are.  Where in the driver would one typically
look to see what, if any, 80211 events are supported?

Cheers,

--
Matt

>
> BR
> Janusz
>
Johannes Berg | 1 Sep 2011 15:10
Favicon

future wpa_s/hostapd release plans

Hi all,

For those who were at the summit -- this is mostly an announcement for
what we discussed there. I may have gotten things wrong, so please
comment and let's hammer this out, then later when we've agreed on "the
plan" I suggest things end up on the website.

For those who weren't at the summit -- in a nutshell: a lot more people
are starting to rely on upstream releases so we need to have more
predictability in the releases. Also, Jouni's overloaded as is, and
really needs help :-)

So the plan is roughly this:

Every 6 months, the current hostap.git repository forks into a new
hostap-x.y.git repository. This repository will be maintained by
different community members, we've volunteered for the first one and TI
indicated they'd be willing to help with the second one.

The hostap-x.y.git repository will be on w1.fi (for all intents and
purposes, the technical implementation may require whoever maintains it
to have their own version somewhere and git synchronising things).

After the fork, a stabilisation period begins, concluding with the
release of "x.y.0" after about 4-8 weeks. This may involve multiple RCs,
e.g. "x.y.0-rc1" per the discretion of the maintainer.

Each one of these stable releases will be maintained for at least a
year, so whoever commits to maintenance will commit to maintaining that
tree for a year from the .0 release.

As far as patch flow goes, for the first 6 months the current stable
tree ("x.y") will have fixes flowing from the development tree into it,
this may require re-writing fixes of course. After 6 months, this
becomes "oldstable" and then only picks up patches from the new "stable"
tree (x.y+1), after another 6 months it is either abandoned or maybe
continues to be maintained for really critical fixes. This patch flow
ensures that fixes are vetted appropriately and the stable trees never
have anything that isn't in the development tree.

Oh, and because this is a change, Jouni proposed calling the first one
that will come out of this "1.0" (first release 1.0.0), followed by
"1.1". (or did you mean 1.0 being the first release, followed by 2.0,
and fixes as 1.1, 1.2, ...?)

That's all. Essentially, the maintenance of the stable and oldstable
branches will be taken off Jouni's shoulder and be more predictable.

Now -- the bad parts:

First of all, when will the first branch happen? I'm not sure -- we need
to put infrastructure in place on our side to make it happen and
familiarise ourselves with the release scripts etc., so that might take
a little while. I'm thinking maybe some time in November, and then the
next ones can be in May 2012, November 2012 etc.

Secondly, we don't have a fully functional test bed, so when/how do we
call what branched as 1.0 actually release-worthy? Jouni -- what's your
process there? Just "generally I'm happy"?

That's all, please comment :-)

johannes
Janusz Dziedzic | 1 Sep 2011 21:53
Picon

Re: wpa_supplicant roaming question

2011/9/1 Matt Causey <matt.causey <at> gmail.com>:
> On Thu, Sep 1, 2011 at 1:17 AM, Janusz Dziedzic
> <janusz.dziedzic <at> gmail.com> wrote:
>> 2011/8/31 Matt Causey <matt.causey <at> gmail.com>:
>>> Ha!  Yeah that's pretty lame on my part.  I was convinced that I'd
>>> configured the supplicant properly at compile time, but alas I was
>>> wrong.  I went back and re-compiled and now it works as expected.  :-)
>>>
>>> I have another question now...I notice that if the supplicant
>>> processes a disassociation or deauth, we call
>>> wpa_supplicant_event_disassoc() (in blacklist.c), which then adds that
>>> BSSID to a blacklist.  Then, the supplicant can no longer roam to that
>>> BSSID, even if it is a better choice.
>>>
>>> In our use case, we have a large number of access points and they can
>>> drop offline for maintenance periodically.  What would folks recommend
>>> we do to keep these BSSID's from becoming permanently blacklisted just
>>> because they needed to reboot?
>>>
>>
>> Seems this is true. Blacklist will be cleared if "No APs found".
>>
>> In case of our implementation we don't hit this problem. We have
>> additional CQM signal - beacon_miss - from our driver (nl80211). Count
>> of beacon_miss is configurable from supplicant when bgscan starts. Our
>> firmware support this beacon_miss detection - so, it is usefull - we
>> can roam before deauthenitcation in case someone will switch off AP or
>> we loose connection.
>> I think we will push this CQM cfg80211/nl80211 compat-wireless +
>> hostap implementation soon.
>>
>> So, in case someone will switch off AP, before we will get
>> deauthentication we get this beacon_miss event and we have chance to
>> roam to another APs. If there isn't another APs blacklist will be
>> cleared because of "No APs found".
>>
>
> Interesting.  So you have events that get processed before a deauth
> happens.  Even with that, it is only a matter of time before your
> client receives a deauth for some other reason that does not correlate
> with a missed beacon, and then you will be vulnerable to the same
> issue.
>
> This functionality as it stands is a show-stopper for us so I've
> commented out the call to wpa_blacklist_add()
> (http://hostap.epitest.fi/wpa_supplicant/devel/blacklist_8c.html#af59c8fe6b0bef5b49f433bd06b29e9ab).
>  I kind of wish that we could at least configure this behavior because
> it's pretty broken currently.  I can see the rationale...the idea is
> that if a BSSID is impaired in some way, but is the strongest BSSID
> for a network, then clients will go there and have a bad experience.
> Unfortunately I think that the heuristic needs more work.
>
> Now, it may be that I can get ath9k to produce similar events that
> prevent the supplicant from processing the deauth, thus preventing the
> bug in the same way you are.  Where in the driver would one typically
> look to see what, if any, 80211 events are supported?
>

In case of black_list  - maybe good idea is to add time parameter for
each blacklisted AP.
In such case we could add APs to blacklist for specyfic amount of time
period. After this time APs will be removed from blacklist.

BR
Janusz
Matt Causey | 1 Sep 2011 22:18
Picon

Re: wpa_supplicant roaming question

On Thu, Sep 1, 2011 at 3:53 PM, Janusz Dziedzic
<janusz.dziedzic <at> gmail.com> wrote:
> 2011/9/1 Matt Causey <matt.causey <at> gmail.com>:
>> On Thu, Sep 1, 2011 at 1:17 AM, Janusz Dziedzic
>> <janusz.dziedzic <at> gmail.com> wrote:
>>> 2011/8/31 Matt Causey <matt.causey <at> gmail.com>:
>>>> Ha!  Yeah that's pretty lame on my part.  I was convinced that I'd
>>>> configured the supplicant properly at compile time, but alas I was
>>>> wrong.  I went back and re-compiled and now it works as expected.  :-)
>>>>
>>>> I have another question now...I notice that if the supplicant
>>>> processes a disassociation or deauth, we call
>>>> wpa_supplicant_event_disassoc() (in blacklist.c), which then adds that
>>>> BSSID to a blacklist.  Then, the supplicant can no longer roam to that
>>>> BSSID, even if it is a better choice.
>>>>
>>>> In our use case, we have a large number of access points and they can
>>>> drop offline for maintenance periodically.  What would folks recommend
>>>> we do to keep these BSSID's from becoming permanently blacklisted just
>>>> because they needed to reboot?
>>>>
>>>
>>> Seems this is true. Blacklist will be cleared if "No APs found".
>>>
>>> In case of our implementation we don't hit this problem. We have
>>> additional CQM signal - beacon_miss - from our driver (nl80211). Count
>>> of beacon_miss is configurable from supplicant when bgscan starts. Our
>>> firmware support this beacon_miss detection - so, it is usefull - we
>>> can roam before deauthenitcation in case someone will switch off AP or
>>> we loose connection.
>>> I think we will push this CQM cfg80211/nl80211 compat-wireless +
>>> hostap implementation soon.
>>>
>>> So, in case someone will switch off AP, before we will get
>>> deauthentication we get this beacon_miss event and we have chance to
>>> roam to another APs. If there isn't another APs blacklist will be
>>> cleared because of "No APs found".
>>>
>>
>> Interesting.  So you have events that get processed before a deauth
>> happens.  Even with that, it is only a matter of time before your
>> client receives a deauth for some other reason that does not correlate
>> with a missed beacon, and then you will be vulnerable to the same
>> issue.
>>
>> This functionality as it stands is a show-stopper for us so I've
>> commented out the call to wpa_blacklist_add()
>> (http://hostap.epitest.fi/wpa_supplicant/devel/blacklist_8c.html#af59c8fe6b0bef5b49f433bd06b29e9ab).
>>  I kind of wish that we could at least configure this behavior because
>> it's pretty broken currently.  I can see the rationale...the idea is
>> that if a BSSID is impaired in some way, but is the strongest BSSID
>> for a network, then clients will go there and have a bad experience.
>> Unfortunately I think that the heuristic needs more work.
>>
>> Now, it may be that I can get ath9k to produce similar events that
>> prevent the supplicant from processing the deauth, thus preventing the
>> bug in the same way you are.  Where in the driver would one typically
>> look to see what, if any, 80211 events are supported?
>>
>
> In case of black_list  - maybe good idea is to add time parameter for
> each blacklisted AP.
> In such case we could add APs to blacklist for specyfic amount of time
> period. After this time APs will be removed from blacklist.
>

I would agree with that.  It might also be useful to make that
configurable rather than a compile-time option.

Even with a time value, though, I'm thinking that there will be some
edge cases that we'll discover.  I am not sure that it's the
supplicant's job, actually, to blacklist BSSIDs at all.  I would
submit that if we have an ESSID with multiple BSSIDs in the first
place, we're talking about an enterprise network or at the very least
a network that should have some robust management in place.  And if a
network like that has BSSID's out there that are broken, it isn't the
client's job to work around that.  Roaming to another (uh, weaker)
access point isn't really a solution.

I'm just curious...what was the failure mode that precipitated the
blacklist feature enhancement to wpa_supplicant?

Thanks!

--
Matt

Gmane