Re: freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
This fails without fail every Sunday? In that case check what happens... eg if that HUP'ING of the freeradius is a weekly crontab then investigate what else is going on at that time ...eg there appear to be mysql errors - ate you using mysql? If so, its not good having errors with that module (and can be the cause if the problem...) I wouldn't say just stop that jobit has a purpose...but see if you are also eg dealing with mysql logrotating at the same time and if you are, don't. I would advise doing a restart of the daemon rather than a HUP and contact your distro maintainers to get latest version. 2.1.10 is really really old. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[Resolved]Re: freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
On 30/12/2555 13:47, Fajar A. Nugraha wrote:
On Sun, Dec 30, 2012 at 9:41 AM, EasyHorpak.com i...@easyhorpak.com wrote:
On 30/12/2555 09:12, EasyHorpak.com wrote:
Dear all
I found freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT
FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
Sun Dec 30 06:50:40 2012 : Info: Received HUP signal.
This looks like cron job rotating the log and sending HUP. The easiest
workaround for you is to just disable that logrotate job
(/etc/logrotate.d/freeradius, I think).
Sun Dec 30 06:50:40 2012 : Info: Loaded virtual server default
Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type
MOD_SINGLE) (p-type = MOD_POLICY)
Do you use fancy entries on policy.conf, perhaps?
More info about OS and freeradius version
Debian x86_64 bit
freeradius: FreeRADIUS Version 2.1.10, for host x86_64-pc-linux-gnu, built
on Sep 24 2012 at 17:58:57
In FR terms, this is old. If you're going to stick with old
distro-provided versions, then file a bug report to the distro.
I didn't get those errors in my environment, so you might also want to
try one of these things:
- try restoring policy.conf to the stock version. Just in case some
changes you made broke it.
- upgrade to the latest version, and see if the bug remains. See
http://freeradius.org/,
http://wiki.freeradius.org/building/Build#Building-Debian-packages, or
https://launchpad.net/~freeradius/+archive/stable
Dear Fajar
I have check in file /etc/logrotate.d/freeradius
it 's show
/var/log/freeradius/*.log {
weekly
rotate 52
compress
delaycompress
notifempty
missingok
postrotate
/etc/init.d/freeradius reload /dev/null
endscript
}
so when I try on /etc/init.d/freeradius reload
freeradius is stopped
so I change to /etc/init.d/freeradius restart
everything works fine
Thank you so much for your advice.
Regards
Chuan Chudabut
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
Dear all I found freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) with the error code Sun Dec 30 06:50:40 2012 : Info: Received HUP signal. Sun Dec 30 06:50:40 2012 : Info: HUP - Re-reading configuration files Sun Dec 30 06:50:40 2012 : Error: rlm_sql_mysql: MYSQL Error: No Fields Sun Dec 30 06:50:40 2012 : Error: rlm_sql_mysql: MYSQL error: Sun Dec 30 06:50:40 2012 : Info: rlm_sql (sql): Attempting to connect rlm_sql_mysql #2 Sun Dec 30 06:50:40 2012 : Info: rlm_sql_mysql: Starting connect to MySQL server for #2 Sun Dec 30 06:50:40 2012 : Info: rlm_sql (sql): Connected new DB handle, #2 Sun Dec 30 06:50:40 2012 : Error: rlm_sql (sql): failed after re-connect Sun Dec 30 06:50:40 2012 : Info: HUP - loading modules Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module files Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module suffix Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module pap Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module attr_filter.access_reject Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module attr_filter.accounting_response Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module radutmp Sun Dec 30 06:50:40 2012 : Info: Loaded virtual server inner-tunnel Sun Dec 30 06:50:40 2012 : Info: Loaded virtual server default Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) Regards Chuan Chudabut - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
On 30/12/2555 09:12, EasyHorpak.com wrote: Dear all I found freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) with the error code Sun Dec 30 06:50:40 2012 : Info: Received HUP signal. Sun Dec 30 06:50:40 2012 : Info: HUP - Re-reading configuration files Sun Dec 30 06:50:40 2012 : Error: rlm_sql_mysql: MYSQL Error: No Fields Sun Dec 30 06:50:40 2012 : Error: rlm_sql_mysql: MYSQL error: Sun Dec 30 06:50:40 2012 : Info: rlm_sql (sql): Attempting to connect rlm_sql_mysql #2 Sun Dec 30 06:50:40 2012 : Info: rlm_sql_mysql: Starting connect to MySQL server for #2 Sun Dec 30 06:50:40 2012 : Info: rlm_sql (sql): Connected new DB handle, #2 Sun Dec 30 06:50:40 2012 : Error: rlm_sql (sql): failed after re-connect Sun Dec 30 06:50:40 2012 : Info: HUP - loading modules Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module files Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module suffix Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module pap Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module attr_filter.access_reject Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module attr_filter.accounting_response Sun Dec 30 06:50:40 2012 : Info: Module: Reloaded module radutmp Sun Dec 30 06:50:40 2012 : Info: Loaded virtual server inner-tunnel Sun Dec 30 06:50:40 2012 : Info: Loaded virtual server default Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) Regards Chuan Chudabut - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html More info about OS and freeradius version Debian x86_64 bit freeradius: FreeRADIUS Version 2.1.10, for host x86_64-pc-linux-gnu, built on Sep 24 2012 at 17:58:57 Copyright (C) 1999-2010 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
On Sun, Dec 30, 2012 at 9:41 AM, EasyHorpak.com i...@easyhorpak.com wrote: On 30/12/2555 09:12, EasyHorpak.com wrote: Dear all I found freeradius down every Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) Sun Dec 30 06:50:40 2012 : Info: Received HUP signal. This looks like cron job rotating the log and sending HUP. The easiest workaround for you is to just disable that logrotate job (/etc/logrotate.d/freeradius, I think). Sun Dec 30 06:50:40 2012 : Info: Loaded virtual server default Sun Dec 30 06:50:40 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) Do you use fancy entries on policy.conf, perhaps? More info about OS and freeradius version Debian x86_64 bit freeradius: FreeRADIUS Version 2.1.10, for host x86_64-pc-linux-gnu, built on Sep 24 2012 at 17:58:57 In FR terms, this is old. If you're going to stick with old distro-provided versions, then file a bug report to the distro. I didn't get those errors in my environment, so you might also want to try one of these things: - try restoring policy.conf to the stock version. Just in case some changes you made broke it. - upgrade to the latest version, and see if the bug remains. See http://freeradius.org/, http://wiki.freeradius.org/building/Build#Building-Debian-packages, or https://launchpad.net/~freeradius/+archive/stable -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius down and shows Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
Hi, i fond my freeradius is down and show log below Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module detail Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module pap Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module radutmp Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module suffix Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module attr_filter.access_reject Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module attr_filter.accounting_response Sun Jul 22 06:25:05 2012 : Info: Loaded virtual server inner-tunnel Sun Jul 22 06:25:05 2012 : Info: Loaded virtual server default Sun Jul 22 06:25:05 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) what version? if not the latest from freeradius.org, then in the first instance, upgrade your server as it may be a bug already fixed. after upgrading, see if you can replicate the incident. if so, then read doc/bugs and provide the required output alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius down and shows Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
EasyHorpak.com wrote: Sun Jul 22 06:25:05 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) Upgrade. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
freeradius down and shows Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
Dear all i fond my freeradius is down and show log below Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module detail Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module pap Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module radutmp Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module suffix Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module attr_filter.access_reject Sun Jul 22 06:25:05 2012 : Info: Module: Reloaded module attr_filter.accounting_response Sun Jul 22 06:25:05 2012 : Info: Loaded virtual server inner-tunnel Sun Jul 22 06:25:05 2012 : Info: Loaded virtual server default Sun Jul 22 06:25:05 2012 : Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY) thank you in advance Chuan Chudabut EasyZone Hotspot Billing v2.9.7 VLAN http://www.easyzonecorp.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
/freeradius-server-2.1.12' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- View this message in context: http://freeradius.1045715.n5.nabble.com/Assert-Failed-on-Proxing-tp4924319p4952616.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
I've tried to install also from the source...but with no success, this is the error i get after the install: # radiusd -X radiusd: error while loading shared libraries: libfreeradius-radius-2.1.12.so: cannot open shared object file: No such file or directory there were no errors in configure make or make install procedures. Also, the old freeradius is still there, working.. Can you help me? -- View this message in context: http://freeradius.1045715.n5.nabble.com/Assert-Failed-on-Proxing-tp4924319p4952896.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
Hi, I've tried to install also from the source...but with no success, this is the error i get after the install: ldconfig -v alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
On Mon, Oct 31, 2011 at 9:48 PM, andreapepa andrea.p...@trentinonetwork.it wrote: So...i've followed the instructions on this link.( http://wiki.freeradius.org/Build#Building+Debian+packages )..but compilation give me this error, libssl-dev is installed: libtool: compile: gcc -g -O2 -O2 -Wall -D_GNU_SOURCE -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/home/apepa/fr212/freeradius-server-2.1.12/src -DHOSTINFO=\x86_64-pc-linux-gnu\ -DRADIUSD_VERSION=\2.1.12\ -DOPENSSL_NO_KRB5 -DRADIUSD_MAJOR_VERSION=2 -DRADIUSD_MINOR_VERSION=1.12 -c modules.c -fPIC -DPIC -o .libs/modules.o modules.c: In function âfr_dlopenextâ: modules.c:216: error: âlt_dladviseâ undeclared (first use in this function) modules.c:216: error: (Each undeclared identifier is reported only once (Shrug) works for me (just tested it). Did you perhaps missed some dependency? Try apt-get build-dep freeradius first. As an alternative, you could try building from the source of my ppa. It's based on Ubuntu's 2.1.10 package (which is slightly different then the bundled FR debian build rules). Both should work though. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Assert Failed on Proxing
rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 7 , fields = 5 rlm_sql (sql): Released sql socket id: 43 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop WARNING: Empty pre-proxy section. Using default return values. Sending Access-Request of id 123 to 172.25.200.161 port 1812 NAS-Port-Type = Wireless-802.11 Calling-Station-Id = 40:61:86:9C:6D:F9 Called-Station-Id = hotspot1 NAS-Port-Id = wlan1 User-Name = apepa NAS-Port = 2150629460 Acct-Session-Id = 80300054 Framed-IP-Address = 10.29.66.3 Vendor-14988-Attr-10 = 0x0a1d4203 CHAP-Challenge = 0xb68620a7e997208ee43593bf739602b6 CHAP-Password = 0x563096c0c85e3e1b1bec92d585dc44496b Service-Type = Login-User WISPr-Logoff-URL = http://10.29.66.1/logout; NAS-Identifier = AP Test Vincenzo NAS-IP-Address = 172.25.18.123 Message-Authenticator := 0x Proxy-State = 0x3938 Proxying request 0 to home server 172.25.200.161 port 1812 Sending Access-Request of id 123 to 172.25.200.161 port 1812 NAS-Port-Type = Wireless-802.11 Calling-Station-Id = 40:61:86:9C:6D:F9 Called-Station-Id = hotspot1 NAS-Port-Id = wlan1 User-Name = apepa NAS-Port = 2150629460 Acct-Session-Id = 80300054 Framed-IP-Address = 10.29.66.3 Vendor-14988-Attr-10 = 0x0a1d4203 CHAP-Challenge = 0xb68620a7e997208ee43593bf739602b6 CHAP-Password = 0x563096c0c85e3e1b1bec92d585dc44496b Service-Type = Login-User WISPr-Logoff-URL = http://10.29.66.1/logout; NAS-Identifier = AP Test Vincenzo NAS-IP-Address = 172.25.18.123 Message-Authenticator := 0x Proxy-State = 0x3938 Going to the next request Waking up in 0.9 seconds. Waking up in 19.0 seconds. rad_recv: Access-Request packet from host 172.25.18.123 port 39869, id=98, length=215 Sending duplicate proxied request to home server 172.25.200.161 port 1812 - ID: 123 Sending Access-Request of id 123 to 172.25.200.161 port 1812 NAS-Port-Type = Wireless-802.11 Calling-Station-Id = 40:61:86:9C:6D:F9 Called-Station-Id = hotspot1 NAS-Port-Id = wlan1 User-Name = apepa NAS-Port = 2150629460 Acct-Session-Id = 80300054 Framed-IP-Address = 10.29.66.3 Vendor-14988-Attr-10 = 0x0a1d4203 CHAP-Challenge = 0xb68620a7e997208ee43593bf739602b6 CHAP-Password = 0x563096c0c85e3e1b1bec92d585dc44496b Service-Type = Login-User WISPr-Logoff-URL = http://10.29.66.1/logout; NAS-Identifier = AP Test Vincenzo NAS-IP-Address = 172.25.18.123 Message-Authenticator := 0x Proxy-State = 0x3938 Waking up in 16.9 seconds. rad_recv: Access-Request packet from host 172.25.18.123 port 39869, id=98, length=215 Sending duplicate proxied request to home server 172.25.200.161 port 1812 - ID: 123 Sending Access-Request of id 123 to 172.25.200.161 port 1812 NAS-Port-Type = Wireless-802.11 Calling-Station-Id = 40:61:86:9C:6D:F9 Called-Station-Id = hotspot1 NAS-Port-Id = wlan1 User-Name = apepa NAS-Port = 2150629460 Acct-Session-Id = 80300054 Framed-IP-Address = 10.29.66.3 Vendor-14988-Attr-10 = 0x0a1d4203 CHAP-Challenge = 0xb68620a7e997208ee43593bf739602b6 CHAP-Password = 0x563096c0c85e3e1b1bec92d585dc44496b Service-Type = Login-User WISPr-Logoff-URL = http://10.29.66.1/logout; NAS-Identifier = AP Test Vincenzo NAS-IP-Address = 172.25.18.123 Message-Authenticator := 0x Proxy-State = 0x3938 Waking up in 13.9 seconds. ASSERT FAILED event.c[1181]: We do not have threads, but the request is marked as queued or running in a child thread == NULL Abortito -- View this message in context: http://freeradius.1045715.n5.nabble.com/Assert-Failed-on-Proxing-tp4924319p4924319.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
On 21/10/11 11:10, andreapepa wrote: Hi all, As you can see from the attached log, i was tring to do some proxy test, the server crashed attempting to proxy against a not running freeradius proxy ( i was only testing proxy action not authentication on other FR servers) is it normal? Which version are you running? Similar bugs were fixed in older versions. If you're not already, upgrade to 2.1.12 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
andreapepa wrote: As you can see from the attached log, i was tring to do some proxy test, the server crashed attempting to proxy against a not running freeradius proxy ( i was only testing proxy action not authentication on other FR servers) is it normal? Upgrade. This was fixed many months ago. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
ii freeradius 2.1.10+dfsg-2a high-performance and highly configurable RADIUS server ii freeradius-common2.1.10+dfsg-2FreeRADIUS common files ii freeradius-postgresql2.1.10+dfsg-2PostgreSQL module for FreeRADIUS server ii freeradius-utils 2.1.10+dfsg-2FreeRADIUS client utilities these are the packages installed on a debian 6 by apt-get -- View this message in context: http://freeradius.1045715.n5.nabble.com/Assert-Failed-on-Proxing-tp4924319p4924546.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
http://wiki.freeradius.org/Debian can i go for it? -- View this message in context: http://freeradius.1045715.n5.nabble.com/Assert-Failed-on-Proxing-tp4924319p4924551.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
http://packages.debian.org/search?keywords=freeradius in this link i can't find any version to upgrade from 2.1.10, can you teel me how to upgrade to 2.1.12? Thanks -- View this message in context: http://freeradius.1045715.n5.nabble.com/Assert-Failed-on-Proxing-tp4924319p4924574.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
andreapepa wrote: http://packages.debian.org/search?keywords=freeradius in this link i can't find any version to upgrade from 2.1.10, can you teel me how to upgrade to 2.1.12? http://wiki.freeradius.org/ It has instructions for building Debian packages. Build a package for 2.1.12, and install it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
On 21/10/11 13:33, andreapepa wrote: http://packages.debian.org/search?keywords=freeradius in this link i can't find any version to upgrade from 2.1.10, can you teel me how to upgrade to 2.1.12? Install the compiler and development libraries Download the source unpack it ./configure make make install This is basic Unix questions, not FreeRADIUS-specific. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
obviously, Phil... my questions , not well explained, was about upgrading the package. i can be sure that with this procedure i will have freeradius upgrade or two version of FR installed ? maybe this is another basic question.. but are you sure that i will get no problem with any dependencies? Thanks a lot -- View this message in context: http://freeradius.1045715.n5.nabble.com/Assert-Failed-on-Proxing-tp4924319p4924856.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
andreapepa wrote: i can be sure that with this procedure i will have freeradius upgrade or two version of FR installed ? You will have only the new version installed. maybe this is another basic question.. but are you sure that i will get no problem with any dependencies? Yes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Assert Failed on Proxing
On Fri, Oct 21, 2011 at 9:28 PM, andreapepa andrea.p...@trentinonetwork.it wrote: obviously, Phil... my questions , not well explained, was about upgrading the package. i can be sure that with this procedure i will have freeradius upgrade or two version of FR installed ? If you install a new version from source using simple ./configure make make install, you'll most likely end up with two version of FR, with the new one in /usr/local/ If you upgrade it it with a package (either created yourself, or use someone else's), you have only one FR fersion. To build your own package: http://wiki.freeradius.org/Build#Building+Debian+packages . Judging from your question, this is the best option for you. If you're feeling lazy and know how to use Ubuntu's packages on debian, try my unofficial ppa on https://launchpad.net/~freeradius/+archive/stable. One of them (natty or lucid version) should work for you. maybe this is another basic question.. but are you sure that i will get no problem with any dependencies? If you use package they will tell you if you have dependency problem, and (on most cases) can automatically install the dependency. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen 0
I've committed a fix which changes the assert to a run-time check. It won't correct the underlying issue, but it will keep the server running. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen 0
On 06/05/11 10:17, Alan DeKok wrote: I've committed a fix which changes the assert to a run-time check. It won't correct the underlying issue, but it will keep the server running. Could you spot any code path which can lead to length 0? I looked and couldn't see how it was possible. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen 0
Phil Mayers wrote: Could you spot any code path which can lead to length 0? I looked and couldn't see how it was possible. I don't see how it's possible, either. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen 0
Hi All,
Sorry for the sketchy details
We got an
ASSERT FAILED xlat.c[1048]: outlen 0
with a PEAP user. The bit of the -X I have is as below, and the soh virtual
server config is attached. I have no further details at the moment because
the client has gone away (and I've disabled SoH in the EAP module config in
case they come back and knock it over again while I'm away).
The same set-up has been fine with many other SoH clients previously.
Can anyone point me in the right direction? The only think that came to
mind was the packet getting a bit big with all those attributes?
Thanks,
James
[updated] returns updated
+++- if ((Calling-Station-Id) %{Calling-Station-Id} =~
/^%{config:policy.mac-addr}$/i) returns updated
+++ ... skipping else for request 750: Preceding if was taken
++- policy create.uob-stripped-mac returns updated
SoH-Supported = yes
SoH-MS-Machine-OS-vendor = Microsoft
SoH-MS-Machine-OS-version = 6
SoH-MS-Machine-OS-release = 0
SoH-MS-Machine-OS-build = 6000
SoH-MS-Machine-SP-version = 0
SoH-MS-Machine-SP-release = 0
SoH-MS-Machine-Processor = x86
SoH-MS-Machine-Name = AlexanderPC
SoH-MS-Correlation-Id =
0x81aa82cd69f946f2bae142fd0fbfcc3e01cc09847027078c
SoH-MS-Machine-Role = client
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=1
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=0 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=1
up2date=0 enabled=0
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=0 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = auto-updates ok action=install
by-policy=1
SoH-MS-Windows-Health-Status = security-updates error no-wsus-srv
FreeRADIUS-Proxied-To = 127.0.0.1
User-Name = abc...@bris.ac.uk
Calling-Station-Id = 00:1b:77:xx:xx:xx
Called-Station-Id = 00:3a:98:9d:17:30:eduroam
NAS-Port = 29
NAS-IP-Address = 172.17.107.207
NAS-Identifier = wism7
Airespace-Wlan-Id = 3
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 448
ASSERT FAILED xlat.c[1048]: outlen 0
--
James J J Hooper
Network Specialist, University of Bristol
http://www.wireless.bristol.ac.uk
--
Config bits:
server eduroamlocal-soh {
authorize {
if (SoH-Supported == no) {
update config {
Auth-Type = Accept
}
}
else {
detail-bsql
update config {
Auth-Type = Accept
}
detail detail-bsql {
detailfile =
${radacctdir}/%{%{Virtual-Server}:-UNKNOWN}-bsql/detail-bsql.log
detailperm = 0600
header = %t
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen 0
On 04/05/11 10:42, James J J Hooper wrote:
Hi All,
Sorry for the sketchy details
We got an
ASSERT FAILED xlat.c[1048]: outlen 0
with a PEAP user. The bit of the -X I have is as below, and the soh
virtual server config is attached. I have no further details at the
moment because the client has gone away (and I've disabled SoH in the
EAP module config in case they come back and knock it over again while
I'm away).
The same set-up has been fine with many other SoH clients previously.
Can anyone point me in the right direction? The only think that came
to mind was the packet getting a bit big with all those attributes?
Thanks,
James
[updated] returns updated
+++- if ((Calling-Station-Id) %{Calling-Station-Id} =~
/^%{config:policy.mac-addr}$/i) returns updated
+++ ... skipping else for request 750: Preceding if was taken
++- policy create.uob-stripped-mac returns updated
Is that all? It jumps straight from the above to dumping the SoH packet?
SoH-Supported = yes
SoH-MS-Machine-OS-vendor = Microsoft
SoH-MS-Machine-OS-version = 6
SoH-MS-Machine-OS-release = 0
SoH-MS-Machine-OS-build = 6000
SoH-MS-Machine-SP-version = 0
SoH-MS-Machine-SP-release = 0
SoH-MS-Machine-Processor = x86
SoH-MS-Machine-Name = AlexanderPC
SoH-MS-Correlation-Id = 0x81aa82cd69f946f2bae142fd0fbfcc3e01cc09847027078c
SoH-MS-Machine-Role = client
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=1
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
Ok, something has gone wildly wrong there Unless they really do have
3 firewall, 7 AV and 8 anti-spyware products installed!
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=0 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=1
up2date=0 enabled=0
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=0 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = auto-updates ok action=install by-policy=1
SoH-MS-Windows-Health-Status = security-updates error no-wsus-srv
FreeRADIUS-Proxied-To = 127.0.0.1
User-Name = abc...@bris.ac.uk
Calling-Station-Id = 00:1b:77:xx:xx:xx
Called-Station-Id = 00:3a:98:9d:17:30:eduroam
NAS-Port = 29
NAS-IP-Address = 172.17.107.207
NAS-Identifier = wism7
Airespace-Wlan-Id = 3
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 448
ASSERT FAILED xlat.c[1048]: outlen 0
Config bits:
server eduroamlocal-soh {
authorize {
if (SoH-Supported == no) {
update config {
Auth-Type = Accept
}
}
else {
detail-bsql
What's the config for this module?
update config {
Auth-Type = Accept
}
detail detail-bsql {
detailfile =
${radacctdir}/%{%{Virtual-Server}:-UNKNOWN}-bsql/detail-bsql.log
detailperm = 0600
header = %t
}
-
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: FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen 0
On 04/05/11 10:42, James J J Hooper wrote:
Hi All,
Sorry for the sketchy details
We got an
ASSERT FAILED xlat.c[1048]: outlen 0
with a PEAP user. The bit of the -X I have is as below, and the soh
virtual server config is attached. I have no further details at the
moment because the client has gone away (and I've disabled SoH in the
EAP module config in case they come back and knock it over again while
I'm away).
The same set-up has been fine with many other SoH clients previously.
Can anyone point me in the right direction? The only think that came
to mind was the packet getting a bit big with all those attributes?
From what I can tell, that's a pretty hard error condition to produce.
xlat.c:1048 is inside xlat_copy, which is the default escaping
function when radius_xlat is called with a NULL final argument.
The assert means that there was no room left in the output buffer, but
the very first check inside the while() loop in radius_xlat is:
while (*p) {
/* Calculate freespace in output */
freespace = outlen - (q - out);
if (freespace = 1)
break;
A quick look at the code gives me the impression it should be pretty
hard to trigger this error condition; I can't see how freespace 1 ever
allows xlat_copy to be called.
Thanks,
James
[updated] returns updated
+++- if ((Calling-Station-Id) %{Calling-Station-Id} =~
/^%{config:policy.mac-addr}$/i) returns updated
+++ ... skipping else for request 750: Preceding if was taken
++- policy create.uob-stripped-mac returns updated
The above policy: where is that? It's clearly not in your SoH virtual
server - is this the inner-tunnel stuff? Can we see the config? I
suspect something in the SoH is triggering this when it dumps the AVPs.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen 0
On 04/05/2011 11:24, Phil Mayers wrote:
On 04/05/11 10:42, James J J Hooper wrote:
[updated] returns updated
+++- if ((Calling-Station-Id) %{Calling-Station-Id} =~
/^%{config:policy.mac-addr}$/i) returns updated
+++ ... skipping else for request 750: Preceding if was taken
++- policy create.uob-stripped-mac returns updated
Is that all? It jumps straight from the above to dumping the SoH packet?
Yes
SoH-Supported = yes
SoH-MS-Machine-OS-vendor = Microsoft
SoH-MS-Machine-OS-version = 6
SoH-MS-Machine-OS-release = 0
SoH-MS-Machine-OS-build = 6000
SoH-MS-Machine-SP-version = 0
SoH-MS-Machine-SP-release = 0
SoH-MS-Machine-Processor = x86
SoH-MS-Machine-Name = AlexanderPC
SoH-MS-Correlation-Id = 0x81aa82cd69f946f2bae142fd0fbfcc3e01cc09847027078c
SoH-MS-Machine-Role = client
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = firewall ok snoozed=0 microsoft=1
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
Ok, something has gone wildly wrong there Unless they really do have 3
firewall, 7 AV and 8 anti-spyware products installed!
Indeed - We all know how messed up clients can get, so this one is
probably due for some TLC (if I can get them to come in).
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=0 enabled=1
SoH-MS-Windows-Health-Status = antivirus ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=0
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=1
up2date=0 enabled=0
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=0 enabled=1
SoH-MS-Windows-Health-Status = antispyware ok snoozed=0 microsoft=0
up2date=1 enabled=1
SoH-MS-Windows-Health-Status = auto-updates ok action=install by-policy=1
SoH-MS-Windows-Health-Status = security-updates error no-wsus-srv
FreeRADIUS-Proxied-To = 127.0.0.1
User-Name = abc...@bris.ac.uk
Calling-Station-Id = 00:1b:77:xx:xx:xx
Called-Station-Id = 00:3a:98:9d:17:30:eduroam
NAS-Port = 29
NAS-IP-Address = 172.17.107.207
NAS-Identifier = wism7
Airespace-Wlan-Id = 3
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 448
ASSERT FAILED xlat.c[1048]: outlen 0
Config bits:
server eduroamlocal-soh {
authorize {
if (SoH-Supported == no) {
update config {
Auth-Type = Accept
}
}
else {
detail-bsql
What's the config for this module?
As below i.e. a plain old detail module
update config {
Auth-Type = Accept
}
detail detail-bsql {
detailfile =
${radacctdir}/%{%{Virtual-Server}:-UNKNOWN}-bsql/detail-bsql.log
detailperm = 0600
header = %t
}
-James
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen 0
On 04/05/2011 11:37, Phil Mayers wrote:
On 04/05/11 10:42, James J J Hooper wrote:
Hi All,
Sorry for the sketchy details
We got an
ASSERT FAILED xlat.c[1048]: outlen 0
with a PEAP user. The bit of the -X I have is as below, and the soh
virtual server config is attached. I have no further details at the
moment because the client has gone away (and I've disabled SoH in the
EAP module config in case they come back and knock it over again while
I'm away).
The same set-up has been fine with many other SoH clients previously.
Can anyone point me in the right direction? The only think that came
to mind was the packet getting a bit big with all those attributes?
From what I can tell, that's a pretty hard error condition to produce.
xlat.c:1048 is inside xlat_copy, which is the default escaping function
when radius_xlat is called with a NULL final argument.
The assert means that there was no room left in the output buffer, but the
very first check inside the while() loop in radius_xlat is:
while (*p) {
/* Calculate freespace in output */
freespace = outlen - (q - out);
if (freespace = 1)
break;
A quick look at the code gives me the impression it should be pretty hard
to trigger this error condition; I can't see how freespace 1 ever allows
xlat_copy to be called.
[updated] returns updated
+++- if ((Calling-Station-Id) %{Calling-Station-Id} =~
/^%{config:policy.mac-addr}$/i) returns updated
+++ ... skipping else for request 750: Preceding if was taken
++- policy create.uob-stripped-mac returns updated
The above policy: where is that? It's clearly not in your SoH virtual
server - is this the inner-tunnel stuff? Can we see the config? I suspect
something in the SoH is triggering this when it dumps the AVPs.
Both inner and outer configs start:
--
server eduroamlocal-inner {
authorize {
create.uob-stripped-mac
preprocess
--
server eduroamlocal {
authorize {
create.uob-stripped-mac
preprocess
--
where create.uob-stripped-mac is:
--
create.uob-stripped-mac {
if((Calling-Station-Id) %{Calling-Station-Id} =~
/^%{config:policy.mac-addr}$/i) {
update request {
UOB-Stripped-MAC :=
%{tolower:%{1}:%{2}:%{3}:%{4}:%{5}:%{6}}
}
updated
}
else {
noop
}
}
--
-James
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
On Mon, Feb 21, 2011 at 5:27 PM, Alan DeKok al...@deployingradius.comwrote: adx grave wrote: I got this after server HUP and it just die. The same error appeared after i manually restart the server but it continue to work just fine. A bug? Or maybe something wrong with my config? Any hint to where should i look? See doc/bugs Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html I've tried to reproduce the crash several times but failed. Although the error is still there, the server run perfectly fine until exactly one week from the first crash (HUP signal). It seem that the server receive a HUP signal every week at the same time at 6:25 am and this morning it happened again. At the same time the radius log get rotated. I'll try to follow the instruction in doc/bugs later but is there any configuration option that instruct the server to HUP once a week? The most likely place I can think of is logrotate which give /etc/init.d/freeradius reload /dev/null every week. Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
adx grave wrote: I got this after server HUP and it just die. The same error appeared after i manually restart the server but it continue to work just fine. A bug? Or maybe something wrong with my config? Any hint to where should i look? See doc/bugs Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Error: ASSERT FAILED modcall.c[106]: (p-type MOD_SINGLE) (p-type = MOD_POLICY)
Hi list, I got this after server HUP and it just die. The same error appeared after i manually restart the server but it continue to work just fine. A bug? Or maybe something wrong with my config? Any hint to where should i look? Freeradius 2.1.10. Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: ASSERT FAILED threads.c[406]
On Jul 26, 2010, at 8:00 PM, Meyers, Dan wrote:
and what's happening in
the perl is still something I need to investigate (and is probably
thread related), or should the fix also stop me getting unresponsive
children in the perl accounting method?
Using threaded perl with DB is a little tricky. You have to use for each perl
thread his own separate connection to DB. You can achieve this by using sub
CLONE {} which is calling on every new thread creation, or you just can use
perl without threads.
Best Regards,
Boian Jordanov
Head of Voice Department
tel. +359 2 4004 723
tel. +359 2 4004 002
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: ASSERT FAILED threads.c[406]
Meyers, Dan wrote: Will do :) Just to check I've understood properly - Do you expect the new version to just fix the ASSERT FAILED error, and what's happening in the perl is still something I need to investigate (and is probably thread related), Yes. or should the fix also stop me getting unresponsive children in the perl accounting method? No. If the SQL database is slow, no amount of poking the RADIUS server will fix that. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Error: ASSERT FAILED threads.c[406]
Quick bit of background. We're using FreeRADIUS in combination with rlm_perl for network access control at our site. Everything was running fine on FreeBSD 8.0 with FreeRADIUS 2.1.8 compiled from ports and Perl 5.8 compiled to be non-threaded and not support multiplicity. We got new higher spec servers from Dell, and sadly the only *nix OS that currently supports the RAID card in them seems to be Ubuntu Server 10.4, so we're now on that. Perl is compiled (as it is by default on Ubuntu) with threads and multiplicity, but some testing by hammering the server from multiple different machines using radclient and some test packets from a file seemed to show that (unlike the last time we tried, which I believe was on FreeRADIUS 2.1.3) using threaded perl was stable and worked fine with rlm_perl in FreeRADIUS (it used to lock up eventually). Ran fine for a week or so, but in the last few days we've had it crash twice, both times with the same message. The logs initially fill with messages of the sort: Sat Jul 24 01:05:08 2010 : Error: WARNING: Unresponsive child for request 128145, in module perl component accounting and Sat Jul 24 01:05:08 2010 : Info: WARNING: Child is hung for request 128145. We'll end up with 32 of the former type of error message (we're currently running with 32 threads configured in the thread_pool in radius.conf), interspersed with the latter, then a stack of the latter type of error (Always for the same set of requests, i.e. one of the ones we got an initial error for, but we'll get the second error multiple times for a given request). Then eventually we get Sat Jul 24 01:05:27 2010 : Error: ASSERT FAILED threads.c[406]: (*request)-magic == REQUEST_MAGIC All our accounting module does in perl is convert the incoming radius hash to yaml and then attempt to write it to a database with a timestamp. I am strongly suspecting that the initial problem is to do with threading in combination with the DBD::MySQL module in perl or the MySQL client rather than FreeRADIUS, despite our testing seeming to show it was OK. But I do not think that final ASSERT FAILED error should be being generated as a result of the former issue. I am trying to understand what is going on. Is FreeRADIUS attempting to kill the deadlocked threads and being unable to do so? Thanks Dan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: ASSERT FAILED threads.c[406]
Meyers, Dan wrote: Ran fine for a week or so, but in the last few days we've had it crash twice, both times with the same message. The logs initially fill with messages of the sort: Sat Jul 24 01:05:08 2010 : Error: WARNING: Unresponsive child for request 128145, in module perl component accounting Oops. We'll end up with 32 of the former type of error message (we're currently running with 32 threads configured in the thread_pool in radius.conf), interspersed with the latter, then a stack of the latter type of error (Always for the same set of requests, i.e. one of the ones we got an initial error for, but we'll get the second error multiple times for a given request). Then eventually we get Sat Jul 24 01:05:27 2010 : Error: ASSERT FAILED threads.c[406]: (*request)-magic == REQUEST_MAGIC That looks like a bug which will be fixed in 2.1.10. See http://git.freeradius.org, branch v2.1.x. Download that and install it. It should fix the problem. If so, please say so. All our accounting module does in perl is convert the incoming radius hash to yaml and then attempt to write it to a database with a timestamp. I am strongly suspecting that the initial problem is to do with threading in combination with the DBD::MySQL module in perl or the MySQL client rather than FreeRADIUS, despite our testing seeming to show it was OK. But I do not think that final ASSERT FAILED error should be being generated as a result of the former issue. I am trying to understand what is going on. Is FreeRADIUS attempting to kill the deadlocked threads and being unable to do so? It's a corner case that wasn't being handled properly. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Error: ASSERT FAILED threads.c[406]
Will do :) Just to check I've understood properly - Do you expect the new version to just fix the ASSERT FAILED error, and what's happening in the perl is still something I need to investigate (and is probably thread related), or should the fix also stop me getting unresponsive children in the perl accounting method? Thanks Dan Meyers, Dan wrote: Ran fine for a week or so, but in the last few days we've had it crash twice, both times with the same message. The logs initially fill with messages of the sort: Sat Jul 24 01:05:08 2010 : Error: WARNING: Unresponsive child for request 128145, in module perl component accounting Oops. snip Sat Jul 24 01:05:27 2010 : Error: ASSERT FAILED threads.c[406]: (*request)-magic == REQUEST_MAGIC That looks like a bug which will be fixed in 2.1.10. See http://git.freeradius.org, branch v2.1.x. Download that and install it. It should fix the problem. If so, please say so. snip It's a corner case that wasn't being handled properly. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
freeradius 2.1.8 dies Error: ASSERT FAILED event.c[1084]: home-ev != NULL
I recently upgraded our freeradius servers to 2.1.8 and over the past month it has died on one of the servers two times (spaced about two weeks apart I think). So fairly infrequently. A bit of background, We use this server predominantly to proxy requests. Every day for about 15 minutes, the two main home servers we proxy to stop responding (they are doing backups or maintenance during this time) so for those 15 minutes our clients (LNS/NAS) would be sending a very large number of accounting interim packets and some stop packets and would be resending these while the home servers are down. Some relevant proxy home server settings we currently use for the main home servers we proxy to: response_window = 14 zombie_period = 40 status_check = status-server check_interval = 30 num_answers_to_alive = 3 The times that freeradius has died has been near the end of the 15 minutes of the home servers downtime. The last time this happened, I noticed logs in the attached file. Ones that sound relevant as follows: Sun Mar 14 17:30:15 2010 : Proxy: Marking home server 10.0.1.48 port 1646 as zombie (it looks like it is dead). Sun Mar 14 17:30:16 2010 : Proxy: Marking home server 10.0.1.47 port 1646 as zombie (it looks like it is dead). Sun Mar 14 17:30:19 2010 : Proxy: Marking home server 10.0.1.47 port 1645 as zombie (it looks like it is dead). Sun Mar 14 17:30:19 2010 : Error: No response to status check 903535 for home server 10.0.1.48 port 1646 Sun Mar 14 17:30:20 2010 : Error: No response to status check 903536 for home server 10.0.1.47 port 1646 ... Sun Mar 14 17:30:32 2010 : Error: Internal sanity check failed for child state ... Fri Mar 19 17:30:54 2010 : Proxy: Failed to create a new socket for proxying requests. Fri Mar 19 17:30:54 2010 : Proxy: Failed to create a new socket for proxying requests. Fri Mar 19 17:30:54 2010 : Proxy: Failed to create a new socket for proxying requests. ... Fri Mar 19 17:30:56 2010 : Error: ASSERT FAILED event.c[1084]: home-ev != NULL That last one is where it dies I think. That last error seems a bit similar (but a bit different) to the following thread: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg58052.html Re: ASSERT FAILED event.c in 2.1.7 Alan DeKok Fri, 25 Sep 2009 01:19:40 -0700 Maja Wolniewicz wrote: After the upgrade from 2.1.6 to 2.1.7 my two servers died 3-4 times daily with the following error: Thu Sep 24 19:07:13 2009 : Error: Received conflicting packet from client AP-8 port 32777 - ID: 240 due to unfinished request 2396. Giving up on old request. Thu Sep 24 19:07:13 2009 : Error: ASSERT FAILED event.c[2682]: request-ev != NULL I have to return to 2.1.6, which works smoothly. The simplest thing to do in the short term is to delete the assertion. Alan DeKok. That one was found to be a bug and was fixed - I don't know if my case is a bug though. Another thread that sounds useful for this is: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg59985.html ... Until then, configuring status-checks local detail files will definitely help. I would recommend doing that *anyways* for network stability. Alan DeKok. I don't currently use the robust proxy accounting that that thread suggests. I expect that would probably work around the issue of freeradius crashing in this case and I will give that a go. Just posting this to let you know that it _might_ be a bug and to ask for advice about whether you think this is a bug or not, and if I should follow up on that, or if you think it is just my configuration that needs some changes and what areas I should concentrate on if that is the case? Regards, Anthony Sun Mar 14 17:30:15 2010 : Proxy: Marking home server 10.0.1.48 port 1646 as zombie (it looks like it is dead). Sun Mar 14 17:30:16 2010 : Proxy: Marking home server 10.0.1.47 port 1646 as zombie (it looks like it is dead). Sun Mar 14 17:30:19 2010 : Proxy: Marking home server 10.0.1.47 port 1645 as zombie (it looks like it is dead). Sun Mar 14 17:30:19 2010 : Error: No response to status check 903535 for home server 10.0.1.48 port 1646 Sun Mar 14 17:30:20 2010 : Error: No response to status check 903536 for home server 10.0.1.47 port 1646 Sun Mar 14 17:30:23 2010 : Error: No response to status check 61094 for home server 10.0.1.47 port 1645 Sun Mar 14 17:30:31 2010 : Error: rlm_radutmp: Logout entry for NAS lns02 port 2520 has wrong ID Sun Mar 14 17:30:32 2010 : Error: Internal sanity check failed for child state Sun Mar 14 17:30:32 2010 : Error: Reply from home server 10.0.1.48 port 1646 - ID: 224 arrived too late for request 903469. Try increasing 'retry_delay' or 'max_request_time' Sun Mar 14 17:30:33 2010 : Proxy: Marking home server 10.0.1.48 port 1645 as zombie (it looks like it is dead). Sun Mar 14 17:30:34 2010 : Error: Internal sanity check failed for child state Sun Mar 14 17:30:34 2010 : Error: Reply from home server 10.0.1.48 port
Re: freeradius 2.1.8 dies Error: ASSERT FAILED event.c[1084]: home-ev != NULL
fab junkmail wrote: I recently upgraded our freeradius servers to 2.1.8 and over the past month it has died on one of the servers two times (spaced about two weeks apart I think). So fairly infrequently. OK. A bit of background, We use this server predominantly to proxy requests. Every day for about 15 minutes, the two main home servers we proxy to stop responding (they are doing backups or maintenance during this time) so for those 15 minutes our clients (LNS/NAS) would be sending a very large number of accounting interim packets and some stop packets and would be resending these while the home servers are down. You can configure the proxy to log accounting packets to disk when the home server is down. See raddb/sites-available/robust-proxy-accounting Sun Mar 14 17:30:15 2010 : Proxy: Marking home server 10.0.1.48 port 1646 as zombie (it looks like it is dead). Sun Mar 14 17:30:16 2010 : Proxy: Marking home server 10.0.1.47 port 1646 as zombie (it looks like it is dead). Sun Mar 14 17:30:19 2010 : Proxy: Marking home server 10.0.1.47 port 1645 as zombie (it looks like it is dead). Sun Mar 14 17:30:19 2010 : Error: No response to status check 903535 for home server 10.0.1.48 port 1646 Sun Mar 14 17:30:20 2010 : Error: No response to status check 903536 for home server 10.0.1.47 port 1646 ... Sun Mar 14 17:30:32 2010 : Error: Internal sanity check failed for child state Hmm... that's not good. Fri Mar 19 17:30:54 2010 : Proxy: Failed to create a new socket for proxying requests. Why is it running out of sockets? This shouldn't happen. Fri Mar 19 17:30:54 2010 : Proxy: Failed to create a new socket for proxying requests. Fri Mar 19 17:30:54 2010 : Proxy: Failed to create a new socket for proxying requests. ... Fri Mar 19 17:30:56 2010 : Error: ASSERT FAILED event.c[1084]: home-ev != NULL Well... after all of the previous errors, it's not surprising that something *worse* eventually goes wrong. It's like driving your car for 45 minutes after the tires are flat: not a good idea. That last one is where it dies I think. Yes. That one was found to be a bug and was fixed - I don't know if my case is a bug though. It's a bug, but the other problems you're seeing should be fixed, too. I don't currently use the robust proxy accounting that that thread suggests. I expect that would probably work around the issue of freeradius crashing in this case and I will give that a go. Yes. Just posting this to let you know that it _might_ be a bug and to ask for advice about whether you think this is a bug or not, and if I should follow up on that, or if you think it is just my configuration that needs some changes and what areas I should concentrate on if that is the case? You have a NAS which is sending large amounts of traffic to a proxy when the home server is down. The proxy isn't configured to do anything useful with the packets. This is a bug in the *architecture*. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius 2.1.8 dies Error: ASSERT FAILED event.c[1084]: home-ev != NULL
Hi Alan, Thanks for your response. Alan DeKok wrote: You can configure the proxy to log accounting packets to disk when the home server is down. See raddb/sites-available/robust-proxy-accounting Ok I will definitely do this then. Fri Mar 19 17:30:54 2010 : Proxy: Failed to create a new socket for proxying requests. Why is it running out of sockets? This shouldn't happen. Not sure but there is a _lot_ of attempted proxying going on - maybe it just went over the system limits like open file limits or something? In any case it probably won't be a problem when I implement the robust-proxy-accounting. You have a NAS which is sending large amounts of traffic to a proxy when the home server is down. The proxy isn't configured to do anything useful with the packets. This is a bug in the *architecture*. Understood. Thanks for your help Alan. Regards, Anthony - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius 2.1.8 dies Error: ASSERT FAILED event.c[1084]: home-ev != NULL
fab junkmail wrote: Why is it running out of sockets? This shouldn't happen. Not sure but there is a _lot_ of attempted proxying going on - maybe it just went over the system limits like open file limits or something? In any case it probably won't be a problem when I implement the robust-proxy-accounting. Likely, yes. If the server is overloaded and unable to proxy packets... who knows what can happen. The *intent* is to have it still work, but it's a poorly tested code path. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ASSERT FAILED event.c in 2.1.7
Alexander Clouter wrote: Bah you gave me the same wimpy advice :) Why fix a problem when you can ignore it? Realistically... I've updated the code. 2.1.8 won't have this issue. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ASSERT FAILED event.c in 2.1.7
After the upgrade from 2.1.6 to 2.1.7 my two servers died 3-4 times daily with the following error: Thu Sep 24 19:07:13 2009 : Error: Received conflicting packet from client AP-8 port 32777 - ID: 240 due to unfinished request 2396. Giving up on old request. Thu Sep 24 19:07:13 2009 : Error: ASSERT FAILED event.c[2682]: request-ev != NULL I have to return to 2.1.6, which works smoothly. Greetings, Maja -- Maja Gorecka-Wolniewicz m...@umk.pl PGP key: http://www.home.umk.pl/~mgw/pgp_pub_key.asc Uczelniane Centrum Information Communication InformatyczneTechnology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University Coll. Maximum, pl. Rapackiego 1, 87-100 Torun, Poland tel.: +48 56-611-27-40 fax: +48 56-622-18-50 tel. kom.: +48-693032574 smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ASSERT FAILED event.c in 2.1.7
Maja Wolniewicz wrote: After the upgrade from 2.1.6 to 2.1.7 my two servers died 3-4 times daily with the following error: Thu Sep 24 19:07:13 2009 : Error: Received conflicting packet from client AP-8 port 32777 - ID: 240 due to unfinished request 2396. Giving up on old request. Thu Sep 24 19:07:13 2009 : Error: ASSERT FAILED event.c[2682]: request-ev != NULL I have to return to 2.1.6, which works smoothly. The simplest thing to do in the short term is to delete the assertion. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ASSERT FAILED event.c in 2.1.7
Alan DeKok al...@deployingradius.com wrote: Maja Wolniewicz wrote: After the upgrade from 2.1.6 to 2.1.7 my two servers died 3-4 times daily with the following error: Thu Sep 24 19:07:13 2009 : Error: Received conflicting packet from client AP-8 port 32777 - ID: 240 due to unfinished request 2396. Giving up on old request. Thu Sep 24 19:07:13 2009 : Error: ASSERT FAILED event.c[2682]: request-ev != NULL I have to return to 2.1.6, which works smoothly. The simplest thing to do in the short term is to delete the assertion. Bah you gave me the same wimpy advice :) https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=23 Cheers -- Alexander Clouter .sigmonster says: Short people get rained on last. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.3 and ASSERT FAILED event.c
Chris Howley wrote:
I encountered the following problem when the server received an
Access-Challenge packet
from a proxy server. Any help in fixing this problem would be appreciated.
See doc/bugs for giving additional information, such as the rest of
the back trace.
Also, a lot more of the debug log might help.
Waking up in 0.9 seconds.
rad_recv: Access-Challenge packet from host 194.82.174.185 port 1812, id=76,
length=81
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
EAP-Message = 0x010300061920
Message-Authenticator = 0x193c8361dc660dd940460f693d6ebf9c
State = 0xad8b0646ad881f6aaefeee6ec7165a25
Proxy-State = 0x313730
+- entering group post-proxy {...}
[post_proxy_log]expand:
/usr/local/var/log/radius/radacct/%Y-%m-%d/post-proxy-detail-%H:00 -
/usr/local/var/log/radius/radacct/2009-02-24/post-proxy-detail-16:00
[post_proxy_log]
/usr/local/var/log/radius/radacct/%Y-%m-%d/post-proxy-detail-%H:00 expands to
/usr/local/var/log/radius/radacct/2009-02-24/post-proxy-detail-16:00
[post_proxy_log]expand: %{Packet-Src-IP-Address} - %t - 10.12.80.101
- Tue Feb 24 16:02:50 2009
++[post_proxy_log] returns ok
[attr_filter.post-proxy]expand: %{Realm} - jrs
attr_filter: Matched entry DEFAULT at line 103
++[attr_filter.post-proxy] returns updated
[eap] No pre-existing handler found
++[eap] returns noop
ASSERT FAILED event.c[3593]: fun != NULL
Abort (core dumped)
This is a catastrophic error indicating that the server has a request
it doesn't know how to handle.
The only way that this could happen is:
a) buffer over-run somewhere
b) source code modifications
The code that receives a proxied response sets fun, and doesn't do a
whole lot else before it hits that assertion. If you're seeing this in
debugging mode (i.e. no threads), then there *very* few things that can
go wrong here.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FR 2.1.3 and ASSERT FAILED event.c
Alan,
Environment: SunOS 5.10 and FR 2.1.3 (stable)
I encountered the following problem when the server received an
Access-Challenge packet
from a proxy server. Any help in fixing this problem would be appreciated.
Thanks,
Chris
Waking up in 0.9 seconds.
rad_recv: Access-Challenge packet from host 194.82.174.185 port 1812, id=76,
length=81
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
EAP-Message = 0x010300061920
Message-Authenticator = 0x193c8361dc660dd940460f693d6ebf9c
State = 0xad8b0646ad881f6aaefeee6ec7165a25
Proxy-State = 0x313730
+- entering group post-proxy {...}
[post_proxy_log]expand:
/usr/local/var/log/radius/radacct/%Y-%m-%d/post-proxy-detail-%H:00 -
/usr/local/var/log/radius/radacct/2009-02-24/post-proxy-detail-16:00
[post_proxy_log]
/usr/local/var/log/radius/radacct/%Y-%m-%d/post-proxy-detail-%H:00 expands to
/usr/local/var/log/radius/radacct/2009-02-24/post-proxy-detail-16:00
[post_proxy_log]expand: %{Packet-Src-IP-Address} - %t - 10.12.80.101 -
Tue Feb 24 16:02:50 2009
++[post_proxy_log] returns ok
[attr_filter.post-proxy]expand: %{Realm} - jrs
attr_filter: Matched entry DEFAULT at line 103
++[attr_filter.post-proxy] returns updated
[eap] No pre-existing handler found
++[eap] returns noop
ASSERT FAILED event.c[3593]: fun != NULL
Abort (core dumped)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ASSERT FAILED
As snmp is not available right now, I am looking in how to deal with statistics, status_server and played a bit. This way I was able to kill freeradius... First I noticed: radclient: dict_init: /usr/share/freeradius//dictionary.freeradius[47]: dict_addattr: attribute name too long I commented out a few of the long-named values. Now with cat x | radclient -d /usr/share/freeradius/ 127.0.0.1 status adminsecret, where x contains: Message-Authenticator = 0x00 FreeRADIUS-Statistics-Type=1 I got: rad_recv: Status-Server packet from host 127.0.0.1 port 33453, id=117, length=50 Message-Authenticator = 0x32f28212809676b99d5943988a714aa8 FreeRADIUS-Statistics-Type = Authentication ASSERT FAILED stats.c[318]: request-listener-type == RAD_LISTEN_NONE Abgebrochen Norbert Wegener - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ASSERT FAILED
Hi, As snmp is not available right now, I am looking in how to deal with statistics, status_server and played a bit. This way I was able to kill freeradius... First I noticed: radclient: dict_init: /usr/share/freeradius//dictionary.freeradius[47]: dict_addattr: attribute name too long I commented out a few of the long-named values. Now with cat x | radclient -d /usr/share/freeradius/ 127.0.0.1 status adminsecret, where x contains: Message-Authenticator = 0x00 FreeRADIUS-Statistics-Type=1 I got: rad_recv: Status-Server packet from host 127.0.0.1 port 33453, id=117, length=50 Message-Authenticator = 0x32f28212809676b99d5943988a714aa8 FreeRADIUS-Statistics-Type = Authentication ASSERT FAILED stats.c[318]: request-listener-type == RAD_LISTEN_NONE Abgebrochen have you enabled the statistics virtual server? copy or link the entry in sites-available/ alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ASSERT FAILED
Norbert Wegener wrote: As snmp is not available right now, I am looking in how to deal with statistics, status_server and played a bit. This way I was able to kill freeradius... Whoops. The intent was to allow Status-Server to any port, but to permit the statistics only to a status port. First I noticed: radclient: dict_init: /usr/share/freeradius//dictionary.freeradius[47]: dict_addattr: attribute name too long I commented out a few of the long-named values. Hmm... The if src/include/libradius.h has a DICT_ATTR with attrname[40], then you have an old copy of the source. This was fixed in a commit on June 19. rad_recv: Status-Server packet from host 127.0.0.1 port 33453, id=117, length=50 Message-Authenticator = 0x32f28212809676b99d5943988a714aa8 FreeRADIUS-Statistics-Type = Authentication ASSERT FAILED stats.c[318]: request-listener-type == RAD_LISTEN_NONE Abgebrochen Grab an update from the new CVS tree: cvs -d :pserver:[EMAIL PROTECTED]:/freeradius-server.git checkout -d radiusd master You should be able to just copy src/main/listen.c from there you your existing tree, so you don't have to do a full configure/make again. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ASSERT FAILED
[EMAIL PROTECTED] wrote: Hi, ... I got: rad_recv: Status-Server packet from host 127.0.0.1 port 33453, id=117, length=50 Message-Authenticator = 0x32f28212809676b99d5943988a714aa8 FreeRADIUS-Statistics-Type = Authentication ASSERT FAILED stats.c[318]: request-listener-type == RAD_LISTEN_NONE Abgebrochen have you enabled the statistics virtual server? copy or link the entry in sites-available/ In radiusd.conf: status_server = yes If you mean the status file from sites-available: It is linked to sites-enabled. Norbert Wegener alan - 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: ASSERT FAILED
Alan DeKok wrote: Norbert Wegener wrote: As snmp is not available right now, I am looking in how to deal with statistics, status_server and played a bit. This way I was able to kill freeradius... Whoops. The intent was to allow Status-Server to any port, but to permit the statistics only to a status port. First I noticed: radclient: dict_init: /usr/share/freeradius//dictionary.freeradius[47]: dict_addattr: attribute name too long I commented out a few of the long-named values. Hmm... The if src/include/libradius.h has a DICT_ATTR with attrname[40], then you have an old copy of the source. This was fixed in a commit on June 19. rad_recv: Status-Server packet from host 127.0.0.1 port 33453, id=117, length=50 Message-Authenticator = 0x32f28212809676b99d5943988a714aa8 FreeRADIUS-Statistics-Type = Authentication ASSERT FAILED stats.c[318]: request-listener-type == RAD_LISTEN_NONE Abgebrochen Grab an update from the new CVS tree: cvs -d :pserver:[EMAIL PROTECTED]:/freeradius-server.git checkout -d radiusd master You should be able to just copy src/main/listen.c from there you your existing tree, so you don't have to do a full configure/make again. Thanks, works now. Norbert Wegener 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: assert failed event.c and perl performance
Hi, I have re-tested it with the lastes CVS, it's working fine. Thanks for your work on FreeRadius :) Regards, Julien Leloup Axione 130/132 Boulevard Camélinat 92240 MALAKOFF FRANCE Alan DeKok a écrit : Julien Leloup wrote: The same configuration, in FreeRadius 2.0.1 worked fine, but when I recompiled Perl 5.8.8 with IThreads support, I also upgraded FreeRadius in 2.0.3 and now I'm going through an error, only when the home server is not alive, or not responding : Grab the latest CVS. It has a fix. 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: assert failed event.c and perl performance
Julien Leloup wrote: The same configuration, in FreeRadius 2.0.1 worked fine, but when I recompiled Perl 5.8.8 with IThreads support, I also upgraded FreeRadius in 2.0.3 and now I'm going through an error, only when the home server is not alive, or not responding : Grab the latest CVS. It has a fix. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
assert failed event.c and perl performance
Hi,
I'm running FreeRadius 2.0.3 under FreeBSD 6.3, in a proxy
configuration. This server is using rlm_perl in a post-proxy phase to
realize some operations on Access-Accept attributes, with the use of a
MySQL database.
The same configuration, in FreeRadius 2.0.1 worked fine, but when I
recompiled Perl 5.8.8 with IThreads support, I also upgraded FreeRadius
in 2.0.3 and now I'm going through an error, only when the home server
is not alive, or not responding :
Rejecting request 0 due to lack of any response from home server x.x.x.x
port 1645
There was no response configured: rejecting request 0
Found Post-Auth-Type Reject
+- entering group REJECT
expand: %{User-Name} - x
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Sending Access-Reject of id 215 to x.x.x.x port 49727
Finished request 0.
ASSERT FAILED event.c[956]: request-next_callback != NULL
Abort
This error is happening even if I use a non-IThread Perl, or if I remove
the use of rlm_perl in post-proxy, so I'm pretty sure it's not related
to the use of the thread configuration of Perl.
Does anyone having the same problem ? I haven't found a trace of this
kind of bug between 2.0.1 and 2.0.3 versions of FreeRadius, only a
discussion on this mailing list from september 2007.
Subsidiary question : I'm not a perl, or freeradius performance expert,
so I'm not sure if it's necessary to use a thread configuration of Perl
to handle something like 40.000 proxied requests (in a Armageddon
scenario), with a decent server. What do you think about it ?
Best regards,
Julien Leloup
Axione
130/132 Boulevard Camélinat
92240 MALAKOFF
FRANCE
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
