[RADIATOR] EAP outer handler problems

[Barry Ard]

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?
>
>