[RADIATOR] Radiator dying in SIGSEGV

[Matti Saarinen]

 Hello Mike,

Mike McCauley wrote:

>>  my $session = &Net::SSLeay::get_session($context->{ssl});
>
> It seems odd that a TLS session can finish authenticating, but there
> is no $session available.

 SSL_get_session(3) tells "SSL_get_session() returns a pointer to the
 SSL_SESSION actually used in ssl. The reference count of the
 SSL_SESSION is not incremented, so that the pointer can become invalid
 by other operations." I understand the explanation so that in some
 cases the function may return undefined value.

 In our case I suppose the culprit lies somewhere behind Radiator.
 Radiator proxies to requests to other radius backend-server who may
 relay the request even further radius server. It may be that sometimes
 this takes so long that something times out resulting in $session
 becoming null.

> What version of openssl do you have.

 The OS is Debian Lenny and the OpenSSL package is based on OpenSSL
 0.9.8g. 

> Do you have a Trace 4 log of what radiator was doing before the crash?

 Yes, I do. The original request is generated by eapol_test program that
 comes with wpa_supplicant. We use it to monitor Radiator and especially
 EAP.

Sun May 31 00:10:05 2009: DEBUG: Packet dump:
*** Received from x.x.x.x port 35834 ....
Code:       Access-Request
Identifier: 0
Authentic:  <245> <186>@R<227><191><137><21>%<135><162><21><233><229><245>
Attributes:
        User-Name = "..."
        NAS-IP-Address = 127.0.0.1
        Calling-Station-Id = "02-00-00-00-00-01"
        Framed-MTU = 1400
        NAS-Port-Type = Wireless-IEEE-802-11
        Connect-Info = "CONNECT 11Mbps 802.11b"
        EAP-Message = <2><0><0><26><1>...
        Message-Authenticator = <246>:<184>E<233>mG(u<177><215><177><8><201>-<18>

Sun May 31 00:10:05 2009: DEBUG: Handling request with Handler 'Realm=/helsinki.fi$/i'
Sun May 31 00:10:05 2009: DEBUG:  Deleting session for ..., 127.0.0.1, 
Sun May 31 00:10:05 2009: DEBUG: Handling with Radius::AuthFILE: 
Sun May 31 00:10:05 2009: DEBUG: Handling with EAP: code 2, 0, 26, 1
Sun May 31 00:10:05 2009: DEBUG: Response type 1
Sun May 31 00:10:05 2009: DEBUG: EAP result: 3, EAP TTLS Challenge
Sun May 31 00:10:05 2009: DEBUG: AuthBy FILE result: CHALLENGE, EAP TTLS Challenge
Sun May 31 00:10:05 2009: DEBUG: Access challenged for ....: EAP TTLS Challenge
Sun May 31 00:10:05 2009: DEBUG: Packet dump:
*** Sending to x.x.x.x port 35834 ....
Code:       Access-Challenge
Identifier: 0
Authentic:  <152><151><253><253><236><171>z<215>?=a$UdT,
Attributes:
        EAP-Message = <1><1><0><6><21> 
        Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>

Sun May 31 00:10:05 2009: DEBUG: Received reply in AuthRADIUS for req 160 from y.y.y.y:1645
Sun May 31 00:10:05 2009: DEBUG: Packet dump:
*** Received from y.y.y.y port 1645 ....
Code:       Access-Accept
Identifier: 160
Authentic:  s<207><197><159><253>,<234>-<172><5><185>L at o"<211>
Attributes:

Sun May 31 00:10:05 2009: DEBUG: Access accepted for ....
Sun May 31 00:10:05 2009: DEBUG: Returned TTLS tunnelled Diameter Packet dump:
Code:       Access-Accept
Identifier: UNDEF
Authentic:  m<190><185><192><4><21>^Z<235>R<211><221>bj[<172>
Attributes:

Segmentation fault (core dumped)


 Cheers,

-- 
- Matti -