Thanks for looking into this, Alan. After merging this (and a bunch of other stuff that had built up) and rebuilding, this happens: Thu Feb 23 10:02:13 2012 : Debug: Opening new proxy (YYYYYYYY, 0) -> home_server (XXXXXXXXXXX, 2083) Thu Feb 23 10:02:13 2012 : Debug: Trying SSL to port 2083 Thu Feb 23 10:02:13 2012 : Debug: Requiring Server certificate Thu Feb 23 10:02:14 2012 : Debug: Listening on proxy (YYYYYYYYYY, 59751) -> home_server (XXXXXXXXXXX, 2083) Sending Access-Request of id 51 to XXXXXXXXXXXX port 2083 User-Name = "UUUUUUUUUU" NAS-IP-Address = YYYYYYYY NAS-Identifier = ZZZZZZZZZZZZ Airespace-Wlan-Id = V Framed-MTU = 1300 EAP-Message = <snip> Message-Authenticator = <snip> Proxy-State = 0x313433 Proxy-State = 0x3735 Thu Feb 23 10:02:14 2012 : Info: (0) Proxying request to home server XXXXXXXX port 2083 Thu Feb 23 10:02:14 2012 : Debug: Proxy is writing 150 bytes to SSL Thu Feb 23 10:02:14 2012 : Debug: Thread 4 waiting to be assigned a request Thu Feb 23 10:02:14 2012 : Debug: Waking up in 0.4 seconds. Program received signal SIGSEGV, Segmentation fault. 0x000000000043c6a7 in proxy_tls_recv (listener=0x7ffff00024d0) at tls_listen.c:478 478 if (!sock->data) sock->data = rad_malloc(listener->tls->fragment_size); Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) print sock $1 = (listen_socket_t *) 0x7ffff00047a0 (gdb) print sock->data $2 = (uint8_t *) 0x0 (gdb) print listener $3 = (rad_listen_t *) 0x7ffff00024d0 (gdb) print listener->tls $4 = (fr_tls_server_conf_t *) 0x0 ________________________________________ From: freeradius-users-bounces+bjulin=clarku.edu@lists.freeradius.org [freeradius-users-bounces+bjulin=clarku.edu@lists.freeradius.org] On Behalf Of Alan DeKok [aland@deployingradius.com] Sent: Thursday, February 23, 2012 4:12 AM To: FreeRadius users mailing list Subject: Re: RadSec FR3.0 to Radiator: "Received packet will be too large" Brian Julin wrote:
We're piloting RadSec as a federation server uplink. They use Radiator. When we first attempted to connect we'd get a "Received packet will be too large!" carp from main/tls.c. They checked on their end and say they have no fragment size option for RadSec TLS connections, only for EAP-TLS connections.
So we applied the below as a test and it works, but I was wondering as to the wisdom of it...
I've pushed a more functional fix. It now allocates the receive buffer based on fragment_size. If the RadSec connection sends too much data, the server prints out an error saying: ... set fragment_size=16384 Or whatever value will allow it to receive the data. I've also updated the comments about fragment_size in raddb/sites-available/tls Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html