[RADIATOR] EAP outer handler problems
Barry Ard
barry.ard at ualberta.ca
Thu Feb 25 21:03:09 CST 2010
Thanks for the reply Kam, we are having a bunch of problems and are
involving Cisco. The cert doesn't expire until next year but we have had
situations where unchecking "verify server cert" has allowed a client to
connect.
Barry
On 10-02-25 8:39 AM, Kam Ng wrote:
> I saw similar symptom before. My problem was attributed to a server (one
> runs Radiator) cert problem as I used self-signed cert in the test env and
> the window XP WLAN client somehow not warned the user about it. It all
> worked once I unselect cert check on the client. Of course, this is only
> acceptable in test env..:-)
>
> Based on this observation, you may want to check to see if your server cert
> has been expired... Just a thought.
>
> Kam
>
> =========================================
>
>
>
>
> |------------>
> | From: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Barry Ard<barry.ard at ualberta.ca> |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Hugh Irvine<hugh at open.com.au> |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Cc: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Radiator list<radiator at open.com.au> |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |02/24/2010 07:56 PM |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Re: [RADIATOR] EAP outer handler problems |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Sent by: |
> |------------>
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |radiator-bounces at open.com.au |
> >--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>
> Thanks Hugh,
> I didn't notice the EAP-Message attribute but I am happy to here that is
> a client problem, there seems to be a lot of them.
>
> Barry
>
> On 10-02-24 4:43 PM, Hugh Irvine wrote:
>
>> Hello Barry -
>>
>> This is not a Radiator problem - it is the supplicant not sending any
>>
> data.
>
>> Notice the EAP-Message attribute containing just the header - no data.
>>
>> BTW - this looks like a machine authentication ("host/Rock").
>>
>> regards
>>
>> Hugh
>>
>>
>> On 25 Feb 2010, at 10:18, Barry Ard wrote:
>>
>>
>>
>>> I have been noticing lately a situation where our eap outer handler does
>>> not seem to send a reply:
>>>
>>> *** Received from 127.0.0.1 port 32946 ....
>>> Code: Access-Request
>>> Identifier: 75
>>> Authentic:<7><141><147>/<233>G<129><255>A<15><241>L<240><138>F<204>
>>> Attributes:
>>> User-Name = "host/Rock"
>>> Calling-Station-Id = "00-0e-35-6d-1a-9b"
>>> Called-Station-Id = "00-23-04-f2-f9-e0:UWS"
>>> NAS-Port = 29
>>> NAS-IP-Address = 172.20.252.18
>>> NAS-Identifier = "MECE-WiSM#1"
>>> Airespace-WLAN-Id = 2
>>> Service-Type = Framed-User
>>> Framed-MTU = 1300
>>> NAS-Port-Type = Wireless-IEEE-802-11
>>> Tunnel-Type = 0:VLAN
>>> Tunnel-Medium-Type = 0:802
>>> Tunnel-Private-Group-ID = 0:2050
>>> EAP-Message =<2><17><0><6><25><0>
>>> State = EAPBALANCE:id=1
>>> Message-Authenticator = 1./~<21>"M$<170>=By<30><201><137><207>
>>>
>>> Wed Feb 24 15:51:15 2010: DEBUG: Handling request with Handler ''
>>> Wed Feb 24 15:51:15 2010: DEBUG: Rewrote user name to Rock
>>> Wed Feb 24 15:51:15 2010: DEBUG: Rewrote user name to Rock
>>> Wed Feb 24 15:51:15 2010: DEBUG: Deleting session for host/Rock,
>>> 172.20.252.18, 29
>>> Wed Feb 24 15:51:15 2010: DEBUG: Handling with Radius::AuthFILE:
>>> Wed Feb 24 15:51:15 2010: DEBUG: Handling with EAP: code 2, 17, 6, 25
>>> Wed Feb 24 15:51:15 2010: DEBUG: Response type 25
>>> Wed Feb 24 15:51:15 2010: DEBUG: EAP result: 2, EAP PEAP Nothing to read
>>> or write
>>> Wed Feb 24 15:51:15 2010: DEBUG: AuthBy FILE result: IGNORE, EAP PEAP
>>> Nothing to read or write
>>>
>>> The handler is configured as:
>>> <Handler>
>>> RewriteUsername s/(.*)\/(.*)/$2/
>>> RewriteUsername s/(.*)\\(.*)/$2/
>>> <AuthBy FILE>
>>> Filename /dev/null
>>> EAPType PEAP,TTLS
>>> EAPTLS_CAPath /etc/ssl/certs
>>> EAPTLS_CertificateType PEM
>>> EAPTLS_CertificateFile /etc/ssl/certs/%h-cert.pem
>>> EAPTLS_PrivateKeyFile /etc/ssl/private/%h-key.pem
>>> EAPTLS_RandomFile %D/random
>>> EAPTLS_MaxFragmentSize 1024
>>> EAPTLS_PEAPVersion 0
>>> EAPTTLS_NoAckRequired
>>> AutoMPPEKeys
>>> </AuthBy>
>>> </Handler>
>>>
>>> The architecture is a radiusd configured to proxy to multiple backend
>>> radiusd processes. In the proxy radiusd log I see:
>>> Wed Feb 24 15:52:00 2010: INFO: AuthRADIUS: No reply after 3
>>> retransmissions to 127.0.0.1:9002 for host/Rock (2)
>>>
>>> Now the strange thing is I only seem to be seeing this on one of our 2
>>> servers that are configured identically, except ... for os version :).
>>> The problem box is running Debian Etch and the other box is Debian
>>> Lenny. I will be forklifting the old box out tomorrow though...
>>>
>>> --
>>> =================================================================
>>> Barry Ard barry.ard at ualberta.ca
>>> Network Operations
>>> Academic Information and Communication Technologies (AICT)
>>> University of Alberta
>>> Edmonton, Alberta Canada
>>>
>>> This communication is intended for the use of the recipient to which it
>>> is addressed, and may contain confidential, personal, and/or privileged
>>> information. Please contact us immediately if you are not the intended
>>> recipient of this communication. If you are not the intended recipient
>>> of this communication, do not copy, distribute, or take action on it.
>>> Any communication received in error, or subsequent reply, should be
>>> deleted or destroyed.
>>>
>>>
>>> _______________________________________________
>>> radiator mailing list
>>> radiator at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>>>
>>>
>>
>> NB:
>>
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (
>>
> www.open.com.au/archives/radiator)?
>
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>>
>>
>>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
>
>
> ------------------------------------------------------------------------------------------------------------------------
>
> This communication is intended for the use of the recipient to which it is
> addressed, and may
> contain confidential, personal, and or privileged information. Please
> contact the sender
> immediately if you are not the intended recipient of this communication,
> and do not copy,
> distribute, or take action relying on it. Any communication received in
> error, or subsequent
> reply, should be deleted or destroyed.
>
>
More information about the radiator
mailing list