Hello, I set up radsec (tls site) in FR3. On start works well, but after a while (20-30 minutes) I see following in logs: Info: Ignoring new connection due to client max_connections (16) and FR3 rejects new incoming tls radsec connections. Ok, I set up client max_connetions = 0 and now after while I get: Info: Ignoring new connection due to socket max_connections Often I see in logs reconnection: Info: ... closing socket auth from client (195.113.18 7.22, 56256) -> (*, 2083, virtual-server=default) Info: ... adding new socket auth from client (195.113 .187.22, 53889) -> (*, 2083, virtual-server=default) I watch at netstat -t and get max 3 connections to port 2083: one in ESTABLISHED state and two in TIME_WAIT state. Client is radiator. What should I set up? Thank you Pavel Polacek
Polish wrote:
I set up radsec (tls site) in FR3. On start works well, but after a while (20-30 minutes) I see following in logs: Info: Ignoring new connection due to client max_connections (16)
Do you have idle timeouts and connection lifetimes set?
and FR3 rejects new incoming tls radsec connections.
Ok, I set up client max_connetions = 0 and now after while I get: Info: Ignoring new connection due to socket max_connections
Often I see in logs reconnection: Info: ... closing socket auth from client (195.113.18 7.22, 56256) -> (*, 2083, virtual-server=default) Info: ... adding new socket auth from client (195.113 .187.22, 53889) -> (*, 2083, virtual-server=default)
I watch at netstat -t and get max 3 connections to port 2083: one in ESTABLISHED state and two in TIME_WAIT state.
Client is radiator.
What should I set up?
Please try the v3.0.x branch from github.com. I've pushed some fixes which should help. Alan DeKok.
Hello, On Wed, 20 Nov 2013, Alan DeKok wrote:
Polish wrote:
I set up radsec (tls site) in FR3. On start works well, but after a while (20-30 minutes) I see following in logs: Info: Ignoring new connection due to client max_connections (16)
Do you have idle timeouts and connection lifetimes set?
Yes
and FR3 rejects new incoming tls radsec connections.
Ok, I set up client max_connetions = 0 and now after while I get: Info: Ignoring new connection due to socket max_connections
Often I see in logs reconnection: Info: ... closing socket auth from client (195.113.18 7.22, 56256) -> (*, 2083, virtual-server=default) Info: ... adding new socket auth from client (195.113 .187.22, 53889) -> (*, 2083, virtual-server=default)
I watch at netstat -t and get max 3 connections to port 2083: one in ESTABLISHED state and two in TIME_WAIT state.
Client is radiator.
What should I set up?
Please try the v3.0.x branch from github.com. I've pushed some fixes which should help.
Alan DeKok.
You are rigth, git version works well. Is possible suppress following logs records? I mean that all debuging options are turned off. : (0) Thu Nov 21 16:38:23 2013 : Debug: Requiring client certificate (0) Thu Nov 21 16:38:23 2013 : Debug: Initiate (0) Thu Nov 21 16:38:23 2013 : Debug: (other): before/accept initialization (0) Thu Nov 21 16:38:23 2013 : Debug: TLS_accept: before/accept initialization (0) Thu Nov 21 16:38:23 2013 : Debug: TLS_accept: SSLv3 read client hello A (0) Thu Nov 21 16:38:23 2013 : Debug: TLS_accept: SSLv3 write server hello A (0) Thu Nov 21 16:38:23 2013 : Debug: TLS_accept: SSLv3 write certificate A (0) Thu Nov 21 16:38:23 2013 : Debug: TLS_accept: SSLv3 write key exchange A (0) Thu Nov 21 16:38:23 2013 : Debug: TLS_accept: SSLv3 write certificate request A Thank you Pavel Polacek
Polish wrote:
You are rigth, git version works well.
Thanks.
Is possible suppress following logs records? I mean that all debuging options are turned off. :
Debugging messages should only appear when debugging is turned off. Those messages come from a DEBUG macro, just like 1000's of other DEBUG macros in the source. Either all should produce debugging, or none of them. Alan DeKok.
On Thu, 21 Nov 2013, Alan DeKok wrote:
Is possible suppress following logs records? I mean that all debuging options are turned off. :
Debugging messages should only appear when debugging is turned off.
Those messages come from a DEBUG macro, just like 1000's of other DEBUG macros in the source. Either all should produce debugging, or none of them.
Alan DeKok. -
I built debian packages by "fakeroot dpkg-buildpackage -b -uc" and install freeradius without debugging symbols. I expected that package is compliled without debugging. I will look at source to deactivate debuging. Thank you Pavel Polacek
On 21 Nov 2013, at 19:10, Polish <pavel.polacek@ujep.cz> wrote:
On Thu, 21 Nov 2013, Alan DeKok wrote:
Is possible suppress following logs records? I mean that all debuging options are turned off. :
Debugging messages should only appear when debugging is turned off.
Those messages come from a DEBUG macro, just like 1000's of other DEBUG macros in the source. Either all should produce debugging, or none of them.
Alan DeKok. -
I built debian packages by "fakeroot dpkg-buildpackage -b -uc" and install freeradius without debugging symbols. I expected that package is compliled without debugging. I will look at source to deactivate debuging.
DEBUG log messages are not controlled by compile time definitions, they're controlled by the runtime debugging flags -X and -x. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hello, On Thu, 21 Nov 2013, Arran Cudbard-Bell wrote:
On 21 Nov 2013, at 19:10, Polish <pavel.polacek@ujep.cz> wrote:
On Thu, 21 Nov 2013, Alan DeKok wrote:
Is possible suppress following logs records? I mean that all debuging options are turned off. :
Debugging messages should only appear when debugging is turned off.
Those messages come from a DEBUG macro, just like 1000's of other DEBUG macros in the source. Either all should produce debugging, or none of them.
Alan DeKok. -
I built debian packages by "fakeroot dpkg-buildpackage -b -uc" and install freeradius without debugging symbols. I expected that package is compliled without debugging. I will look at source to deactivate debuging.
DEBUG log messages are not controlled by compile time definitions, they're controlled by the runtime debugging flags -X and -x.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
I'm confused but I ask: Why I have debug messages in logs, when I run freeradius without any debug switch (started by /etc/init.d/freeradius start). Bug reported here: http://freeradius.1045715.n5.nabble.com/FR3-Debugging-Switches-td5722824.htm... isn't solved. So debian init script "/etc/init.d/freeradius restart" always fail when enable tls (radsec tunnel) virtual server. less /etc/init.d/freeradius: .. test_freeradius_config() { log_action_begin_msg "Checking $DESCR configuration" out=`$PROGRAM -Cxl stdout $FREERADIUS_OPTIONS`; ret=$? out=`echo "${out}" | tail -n 1 | sed 's/^\s*ERROR:\s*\(.*\)\s*$/\1/'` log_action_end_msg $ret "$out" return $ret } .. /etc/freeradius# freeradius -Cxl stdout freeradius: FreeRADIUS Version 3.1.0 (git #2deafa8), for host x86_64-pc-linux-gnu, built on Nov 21 2013 at 10:46:32 Copyright (C) 1999-2013 The FreeRADIUS server project and contributors There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License For more information about these matters, see the file named COPYRIGHT Starting - reading configuration files ... Using cached TLS configuration from previous invocation Using cached TLS configuration from previous invocation WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) WARNING: Ignoring "ldap" (see raddb/mods-available/README.rst) WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) WARNING: Ignoring "ldap" (see raddb/mods-available/README.rst) WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) radiusd: #### Skipping IP addresses and Ports #### /etc/freeradius/sites-enabled/tls[7]: Threading must be enabled for TLS sockets to function properly /etc/freeradius/sites-enabled/tls[7]: You probably need to do 'radiusd -fxx -l stdout' for debugging Sorry, Maybe a mix too many things together. Thank you Pavel Polacek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Look at what you just posted. There is clearly a debug flag in that command (-x) that is why it's failing. TLS means you cannot run in single thread mode. ... so if you want to debug you need the flags that the server asks you to use when it fails. Are you really telling us that some distribution has those flags on a default install??? alan - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -----BEGIN PGP SIGNATURE----- Version: APG v1.0.9 iHkEAREIADkFAlKPHucyHEFsYW4gQnV4ZXkgKEFsYW4gQnV4ZXkpIDxhLmwubS5i dXhleUBsYm9yby5hYy51az4ACgkQobRdvRSkLC5rUwCdF9vQPQAiuTYrQ3MbrdL9 H0O9qdMAn0aowWrvzgzXlu/VwjpQg2wHS7CE =+WP4 -----END PGP SIGNATURE-----
On Fri, 22 Nov 2013, Alan Buxey wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Look at what you just posted. There is clearly a debug flag in that command (-x) that is why it's failing.
TLS means you cannot run in single thread mode. ... so if you want to debug you need the flags that the server asks you to use when it fails. Are you really telling us that some distribution has those flags on a default install???
alan
I don't able to describe clear. Downloaded version of FR3 (3.0.0 or latest git version) compiled by tools to generate debian packages. 1) debug messages in logs without -x option "/etc/init.d/freeradius start" on debian wheezy in logs I see: 0) Fri Nov 22 10:20:09 2013 : Debug: TLS_accept: before/accept initialization (0) Fri Nov 22 10:20:09 2013 : Debug: TLS_accept: SSLv3 read client hello A 19 rows for every tls connection, so in default (idle_timeout) every 30 seconds. 2) invoking "/etc/init.d/freeradius restart" always fail if site tls is enabled /etc/freeradius# /etc/init.d/freeradius restart [FAIL] Checking FreeRADIUS daemon configuration...failed (/etc/freeradius/sites-enabled/tls[7]: You probably need to do 'radiusd -fxx -l stdout' for debugging). Best regards Pavel Polacek
Hi,
Downloaded version of FR3 (3.0.0 or latest git version) compiled by tools to generate debian packages.
yes...and the Debian scripts are wrong. please please please just read what you've been told and LOOK at what the script is running. its running in a non operative way - theres a small 'x' in its arguments (in the 'service check' part - -Cx..... thats wrong. as the server CLEARLY says "You probably need to do 'radiusd -fxx -l stdout' for debugging" so , if you want to use that debian start script, edit the line that has -Cx..... and fix it. alan
Hi, On Fri, 22 Nov 2013, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Downloaded version of FR3 (3.0.0 or latest git version) compiled by tools to generate debian packages.
yes...and the Debian scripts are wrong. please please please just read what you've been told and LOOK at what the script is running. its running in a non operative way - theres a small 'x' in its arguments (in the 'service check' part - -Cx.....
Yes, but only for configuration check. Procedure are called from restart, reload, configtest, testconfig, but not from start section: part of /etc/init.d/freeradius: start) log_daemon_msg "Starting $DESCR" "$PROG" start_daemon -p "$PIDFILE" "$PROGRAM" $FREERADIUS_OPTIONS || ret=$? log_end_msg $ret ;; I don't see any small 'x' on start_daemon row. #ps aux | grep freeradius freerad 8170 0.0 1.2 160364 6444 ? Ssl 11:00 0:00 /usr/sbin/freeradius # cat /proc/8170/cmdline /usr/sbin/freeradius Debug messages are generated only for TLS (radsec) tunnel.
thats wrong.
as the server CLEARLY says
"You probably need to do 'radiusd -fxx -l stdout' for debugging"
so , if you want to use that debian start script, edit the line that has -Cx..... and fix it.
alan
Yes, I change init script for myself, but It should be repaired for all others (debian users) if is it possible. Thank you Pavel Polacek
thats wrong.
as the server CLEARLY says
"You probably need to do 'radiusd -fxx -l stdout' for debugging"
so , if you want to use that debian start script, edit the line that has -Cx..... and fix it.
alan
Yes, I change init script for myself, but It should be repaired for all others (debian users) if is it possible.
The init script is fine, the x is needed for the config check else you don't get any output regarding what the issue is, and the config check is useless. I'll have a look at it today. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Polish wrote:
1) debug messages in logs without -x option "/etc/init.d/freeradius start" on debian wheezy
in logs I see: 0) Fri Nov 22 10:20:09 2013 : Debug: TLS_accept: before/accept initialization (0) Fri Nov 22 10:20:09 2013 : Debug: TLS_accept: SSLv3 read client hello A
There's nothing special about those debug messages, or about the request which initiates TLS. It should be producing messages *only* when the debug flag is non-zero.
19 rows for every tls connection, so in default (idle_timeout) every 30 seconds.
That's a different issue. You have idle_timeout set to 30s, so FreeRADIUS closes the socket. However, the client is configured to keep the socket open. So it immediately re-opens the socket. One short-term work-around is to set idle_timeout to zero. Or, configure the client to not immediately re-open the connection.
2) invoking "/etc/init.d/freeradius restart" always fail if site tls is enabled
I just pushed a fix for that. Alan DeKok.
Polish wrote:
1) debug messages in logs without -x option "/etc/init.d/freeradius start" on debian wheezy
in logs I see: 0) Fri Nov 22 10:20:09 2013 : Debug: TLS_accept: before/accept initialization (0) Fri Nov 22 10:20:09 2013 : Debug: TLS_accept: SSLv3 read client hello A
I've found the issue and pushed a fix. Alan DeKok.
Hello, On Fri, 22 Nov 2013, Alan DeKok wrote:
Polish wrote:
1) debug messages in logs without -x option "/etc/init.d/freeradius start" on debian wheezy
in logs I see: 0) Fri Nov 22 10:20:09 2013 : Debug: TLS_accept: before/accept initialization (0) Fri Nov 22 10:20:09 2013 : Debug: TLS_accept: SSLv3 read client hello A
I've found the issue and pushed a fix.
Alan DeKok. -
Works. Thank you Pavel Polacek
Polish wrote:
I'm confused but I ask: Why I have debug messages in logs, when I run freeradius without any debug switch (started by /etc/init.d/freeradius start).
Bug reported here: http://freeradius.1045715.n5.nabble.com/FR3-Debugging-Switches-td5722824.htm...
isn't solved.
I just pushed a fix. Please do "git pull", then re-build and re-install. "radiusd -C" now works with tls. Alan DeKok.
Hello, On Fri, 22 Nov 2013, Alan DeKok wrote:
Polish wrote:
I'm confused but I ask: Why I have debug messages in logs, when I run freeradius without any debug switch (started by /etc/init.d/freeradius start).
Bug reported here: http://freeradius.1045715.n5.nabble.com/FR3-Debugging-Switches-td5722824.htm...
isn't solved.
I just pushed a fix. Please do "git pull", then re-build and re-install.
"radiusd -C" now works with tls.
Alan DeKok.
Works well. Thank you
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Arran Cudbard-Bell -
Polish