Re: RadSec FR3.0 to Radiator: Received packet will be too large
Alan Buxey wrote: interestinga RADSEC packet can be much bigger than that too - 2048 gives some room for a big certificate - but not if its double-chained with intermediate and its got a nice security size instead of being a little 512bit RSA one. typically EAP-TLS can be fragmented on the server due to it going through to the end-clients ..and being UDP things get a little nasty...whereas with RADSEC theres no reason why a single TCP request couldnt be quite large and needing to be fragmented by the routers That is hidden from the server. It's just receiving a stream of data, not packets. IIRC, the TLS packets over TCP can be up to 64K in length. So I suppose that the server should handle that. Oh well... more changes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: Received packet will be too large
Stefan Winter wrote: The RADIUS/TLS wrapper around those datagrams is not size-limited at all The TLS protocol sends data in packets with headers. Those packets can be up to 64K in length. The TLS code in FreeRADIUS was originally based on the EAP-TLS code. The EAP-TLS packets run over ethernet, which means that the encoded RADIUS + EAP + TLS packets must fit within an ethernet frame. i.e. about 1K. The TLS code in FreeRADIUS still has that limitation. My guess is that main/tls.c thinks it operates within a EAP context and tries to warn of too big data chunks, while there is actually nothing to warn about. Yeah. The warning is just that the code doesn't handle more than 1K of TLS data at a time. It's easy enough to fix, though. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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
RE: RadSec FR3.0 to Radiator: Received packet will be too large
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 (, 0) - home_server (XXX, 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 (YY, 59751) - home_server (XXX, 2083) Sending Access-Request of id 51 to port 2083 User-Name = UU NAS-IP-Address = NAS-Identifier = 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 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. 0x0043c6a7 in proxy_tls_recv (listener=0x700024d0) 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 *) 0x700047a0 (gdb) print sock-data $2 = (uint8_t *) 0x0 (gdb) print listener $3 = (rad_listen_t *) 0x700024d0 (gdb) print listener-tls $4 = (fr_tls_server_conf_t *) 0x0 From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of Alan DeKok [al...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: Received packet will be too large
Brian Julin wrote: After merging this (and a bunch of other stuff that had built up) and rebuilding, this happens: Oops. Do a git pull, and I think it should be fixed. Thanks for the GDB backtrace. That helped. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RadSec FR3.0 to Radiator: Received packet will be too large
-Original Message- From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.or g [mailto:freeradius-users-bounces+bjulin=clarku.edu@lists.freer adius.org] On Behalf Of Alan DeKok Sent: Thursday, February 23, 2012 10:31 AM Subject: Re: RadSec FR3.0 to Radiator: Received packet will be too large Oops. Do a git pull, and I think it should be fixed. That seems to have done the trick. I also tested the codepath that prints an error when fragment_size is too small, and that works fine, too. Thanks, again, very much. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RadSec FR3.0 to Radiator: Received packet will be too large
Hello again, 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... diff --git a/src/main/tls.c b/src/main/tls.c index 10caec4..947409f 100644 --- a/src/main/tls.c +++ b/src/main/tls.c @@ -2709,7 +2709,7 @@ int proxy_tls_recv(rad_listen_t *listener) size_t length; listen_socket_t *sock = listener-data; char buffer[256]; - uint8_t data[1024]; + uint8_t data[2048]; RADIUS_PACKET *packet; RAD_REQUEST_FUNP fun = NULL; - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: Received packet will be too large
Hi, 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... interestinga RADSEC packet can be much bigger than that too - 2048 gives some room for a big certificate - but not if its double-chained with intermediate and its got a nice security size instead of being a little 512bit RSA one. typically EAP-TLS can be fragmented on the server due to it going through to the end-clients ..and being UDP things get a little nasty...whereas with RADSEC theres no reason why a single TCP request couldnt be quite large and needing to be fragmented by the routers alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: Received packet will be too large
Hi, 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. The above doesn't make much sense to me... there are size limits in RADIUS, but not regarding the TLS stream around them. The limits in question are: - EAP-Message total length must be = MTU between NAS and device (EAP cannot be fragmented on layer 2) - RADIUS datagram total length 4096 Bytes (arbitrary RFC limit) The RADIUS/TLS wrapper around those datagrams is not size-limited at all - it carries streams on n RADIUS datagrams. The TCP stack will take care of sending the data in chunks like with any other TCP based protocol. My guess is that main/tls.c thinks it operates within a EAP context and tries to warn of too big data chunks, while there is actually nothing to warn about. Greetings, Stefan Winter So we applied the below as a test and it works, but I was wondering as to the wisdom of it... interestinga RADSEC packet can be much bigger than that too - 2048 gives some room for a big certificate - but not if its double-chained with intermediate and its got a nice security size instead of being a little 512bit RSA one. typically EAP-TLS can be fragmented on the server due to it going through to the end-clients ..and being UDP things get a little nasty...whereas with RADSEC theres no reason why a single TCP request couldnt be quite large and needing to be fragmented by the routers alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
