Hi Hoercher,

 

Thank you very much for your advice.

 

Using ethereal sniffing, I've captured the packets in the wireless supplicant interface and the related records are as follows:

 

 

 

Besides,  the related radius log is as follows:

 

rad_recv: Access-Request packet from host 172.24.26.144:1025, id=186, length=249

      Acct-Session-Id = "2e578294"

      NAS-Port = 1

      NAS-Port-Type = Wireless-802.11

      User-Name = "alcatel"

      Calling-Station-Id = "00-0E-35-89-71-E0"

      Called-Station-Id = "00-03-52-01-84-7D"

      EAP-Message = 0x02f3005019800000004616030100410100003d030144ed53ef07a048b6fc29ca4e446ccb5d3fbfca4977bba0fee1d0212aacab134400001600040005000a000900640062000300060013001200630100

      State = 0xd5fc64a31e807c1466886de9976ddb63

      NAS-Identifier = "R014-00755"

      NAS-IP-Address = 172.24.26.144

      Framed-MTU = 1496

      Connect-Info = "IEEE802.1X"

      Service-Type = Framed-User

      Message-Authenticator = 0xad27137f763a888a127758b4802d60bd

  Processing the authorize section of radiusd.conf

modcall: entering group authorize for request 6

  modcall[authorize]: module "preprocess" returns ok for request 6

radius_xlat:   '/usr/local/var/log/radius/radacct/172.24.26.144/auth-detail-20060824'

rlm_detail: /usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/var/log/radius/radacct/172.24.26.144/auth-detail-20060824

  modcall[authorize]: module "auth_log" returns ok for request 6

  modcall[authorize]: module "mschap" returns noop for request 6

    rlm_realm: No '@' in User-Name = "alcatel", looking up realm NULL

    rlm_realm: No such realm "NULL"

  modcall[authorize]: module "suffix" returns noop for request 6

  rlm_eap: EAP packet type response id 243 length 80

  rlm_eap: No EAP Start, assuming it's an on-going EAP conversation

  modcall[authorize]: module "eap" returns updated for request 6

    users: Matched entry DEFAULT at line 152

    users: Matched entry DEFAULT at line 171

  modcall[authorize]: module "files" returns ok for request 6

modcall: leaving group authorize (returns updated) for request 6

  rad_check_password:  Found Auth-Type EAP

auth: type "EAP"

  Processing the authenticate section of radiusd.conf

modcall: entering group authenticate for request 6

  rlm_eap: Request found, released from the list

  rlm_eap: EAP/peap

  rlm_eap: processing type peap

  rlm_eap_peap: Authenticate

  rlm_eap_tls: processing TLS

rlm_eap_tls:   Length Included

  eaptls_verify returned 11

    (other): before/accept initialization

    TLS_accept: before/accept initialization

  rlm_eap_tls: <<< TLS 1.0 Handshake [length 0041], ClientHello 

    TLS_accept: SSLv3 read client hello A

  rlm_eap_tls: >>> TLS 1.0 Handshake [length 004a], ServerHello 

    TLS_accept: SSLv3 write server hello A

  rlm_eap_tls: >>> TLS 1.0 Handshake [length 0243], Certificate 

    TLS_accept: SSLv3 write certificate A

  rlm_eap_tls: >>> TLS 1.0 Handshake [length 0004], ServerHelloDone 

    TLS_accept: SSLv3 write server done A

    TLS_accept: SSLv3 flush data

    TLS_accept:error in SSLv3 read client certificate A

rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0)

In SSL Handshake Phase

In SSL Accept mode  

  eaptls_process returned 13

  rlm_eap_peap: EAPTLS_HANDLED

  modcall[authenticate]: module "eap" returns handled for request 6

modcall: leaving group authenticate (returns handled) for request 6

Sending Access-Challenge of id 186 to 172.24.26.144 port 1025

      Framed-IP-Address = 255.255.255.254

      Framed-MTU = 576

      Service-Type = Framed-User

      EAP-Message = 0x01f402a61900160301004a02000046030144ed52c7791dfb4db0d0bacf1f84744c2e7aa61d8990d0711343cfd7428edc4320d9fdf4f079954337b4c264c8a33c0b2ccca925f5119a4c314a5d25e612fca3aa00040016030102430b00023f00023c000239308202353082019ea003020102020101300d06092a864886f70d01010405003054310b3009060355040613024652310e300c060355040813055061726973310f300d0603550407130656656c697a793110300e060355040a1307416c636174656c31123010060355040313096c6f63616c686f7374301e170d3036303831373131343230355a170d3037303831373131343230355a3054310b

      EAP-Message = 0x3009060355040613024652310e300c060355040813055061726973310f300d0603550407130656656c697a793110300e060355040a1307416c636174656c31123010060355040313096c6f63616c686f737430819f300d06092a864886f70d010101050003818d0030818902818100c0b68a2064159d8dc8b4067746ee82384bc71ac4efbf1132ffe1afabf49a207e3e3d553a6e27b1a7c3875c8892c8ebd91a09fd7709e354168e9a4a71e38a936c82e2b857eb5176eae445966adf28ce8f3a31c987aced4d774a9957de5b26bdc300fcee71c0f7139845ebd253c6f27945bbe70fd3501563e231ba1d52419508ed0203010001a31730153013060355

      EAP-Message = 0x1d25040c300a06082b06010505070301300d06092a864886f70d0101040500038181001a8366350e04eb86535cbf2b3c4a13c32f5c4455310aad4e23480d695cab9ea9dbdeed10885c1c483beb583e19adaf4e663bc41fe81c3a00a83dbcb86dbae0dd25653c2f2eea11f510cbc359e83589e6236a8456ae91bb0631c30c87172933e625ff3e2571d8781b5a3351179d0ebcd2955b235513684fcdcd288386eb612a8316030100040e000000

      Message-Authenticator = 0x00000000000000000000000000000000

      State = 0xac69d287747a66f880697ba51187da63

Finished request 6

Going to the next request

Waking up in 6 seconds...

rad_recv: Access-Request packet from host 172.24.26.144:1025, id=144, length=175

      Acct-Session-Id = "2e578294"

      NAS-Port = 1

      NAS-Port-Type = Wireless-802.11

      User-Name = "alcatel"

      Calling-Station-Id = "00-0E-35-89-71-E0"

      Called-Station-Id = "00-03-52-01-84-7D"

      EAP-Message = 0x02f400061900

      State = 0xac69d287747a66f880697ba51187da63

      NAS-Identifier = "R014-00755"

      NAS-IP-Address = 172.24.26.144

      Framed-MTU = 1496

      Connect-Info = "IEEE802.1X"

      Service-Type = Framed-User

      Message-Authenticator = 0x96da8d8ab41d8a0d4d4fe964298b1d0f

  Processing the authorize section of radiusd.conf

modcall: entering group authorize for request 7

  modcall[authorize]: module "preprocess" returns ok for request 7

radius_xlat:   '/usr/local/var/log/radius/radacct/172.24.26.144/auth-detail-20060824'

rlm_detail: /usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/var/log/radius/radacct/172.24.26.144/auth-detail-20060824

  modcall[authorize]: module "auth_log" returns ok for request 7

  modcall[authorize]: module "mschap" returns noop for request 7

    rlm_realm: No '@' in User-Name = "alcatel", looking up realm NULL

    rlm_realm: No such realm "NULL"

  modcall[authorize]: module "suffix" returns noop for request 7

  rlm_eap: EAP packet type response id 244 length 6

  rlm_eap: No EAP Start, assuming it's an on-going EAP conversation

  modcall[authorize]: module "eap" returns updated for request 7

    users: Matched entry DEFAULT at line 152

    users: Matched entry DEFAULT at line 171

  modcall[authorize]: module "files" returns ok for request 7

modcall: leaving group authorize (returns updated) for request 7

  rad_check_password:  Found Auth-Type EAP

auth: type "EAP"

  Processing the authenticate section of radiusd.conf

modcall: entering group authenticate for request 7

  rlm_eap: Request found, released from the list

  rlm_eap: EAP/peap

  rlm_eap: processing type peap

  rlm_eap_peap: Authenticate

  rlm_eap_tls: processing TLS

rlm_eap_tls: Received EAP-TLS ACK message

  rlm_eap_tls: ack handshake fragment handler

  eaptls_verify returned 1

  eaptls_process returned 13

  rlm_eap_peap: EAPTLS_HANDLED

  modcall[authenticate]: module "eap" returns handled for request 7

modcall: leaving group authenticate (returns handled) for request 7

Sending Access-Challenge of id 144 to 172.24.26.144 port 1025

      Framed-IP-Address = 255.255.255.254

      Framed-MTU = 576

      Service-Type = Framed-User

      EAP-Message = 0x01f500061900

      Message-Authenticator = 0x00000000000000000000000000000000

      State = 0xb2fb4146c8792b2e32313e63983fdbdd

Finished request 7

Going to the next request

Waking up in 6 seconds...

--- Walking the entire request list ---

Cleaning up request 5 ID 108 with timestamp 44ed52c7

Cleaning up request 7 ID 144 with timestamp 44ed52c7

Cleaning up request 6 ID 186 with timestamp 44ed52c7

Nothing to do.   Sleeping until we see a request.

 

 

Anyone has some good suggestions? Thanks in advance.

 

 

 

2006/8/23, K. Hoercher <wbhoer@gmail.com>:

On 8/22/06, sheng <wushengws1001@gmail.com> wrote:

> There's a strange problem: each time the client send a request, the server
> tries to read the client certificate on the supplicant. I think it's very
> strange considering that no client certificate is needed for peap/mschapv2.
> This event is recorded in the handshake phase on the radius logfile(I've
> listed it in the below). It seems the handshake phase fails because the
> server cann't read the client certificate.
[...]
>     TLS_accept:error in SSLv3 read client certificate A
> rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0)
> In SSL Handshake Phase
> In SSL Accept mode
>   eaptls_process returned 13
>   rlm_eap_peap: EAPTLS_HANDLED

Hi,

if you are referring to the quoted part, that' not a problem. Roughly
put: openssl just mentiones that it wasn't able to check the client
cert (which is possible, but unneeded for eap-peap).

> Finished request 3
> Going to the next request
> Waking up in 6 seconds...
> --- Walking the entire request list ---
> Cleaning up request 2 ID 19 with timestamp 44e9e42f
> Cleaning up request 3 ID 138 with timestamp 44e9e42f
> Nothing to do.  Sleeping until we see a request.
> rad_recv: Access-Request packet from host 172.24.26.144:1025, id=137,
> length=249
>  Acct-Session-Id = "67671438"
>  NAS-Port = 1
>  NAS-Port-Type = Wireless-802.11
>  User-Name = "alcatel"
>  Calling-Station-Id = "00-0E-35-89-71-E0"
>  Called-Station-Id = "00-03-52-01-84-7D"
>  EAP-Message = 0x0280005019800000004616030100410100003d030144e9e54ee8bf5c390cecf9fa8b659b32ac0a7eb623919876fa26dd9dc220d75800001600040005000a000900640062000300060013001200630100
>  State = 0x091ad12235d4b0c91ca834c803d04ee0
[...]
> modcall: entering group authenticate for request 4
> rlm_eap: Request not found in the list
> rlm_eap: Either EAP-request timed out OR EAP-response to an unknown
> EAP-request
> rlm_eap: Failed in handler

Which of the two cases mentioned in the debug output to your further
requests might be happening I'm not sure of. There seems to elapse
quite some time, before they come in after the challenge was sent out.
That looks curious.

As your included data got truncated on the list you might consider
resending it as attachment or use a pastebot and provide the link.

Maybe you could provide some sniffing on the wireless part (via
wireshark et al). That might be instructive in sorting out when who
did send what.

regards
K. Hoercher
(Hopefully gmail really could not send this out, as it keept telling
me. Otherwise this must be the 5th reply, if so please excuse me.)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html