Hi, Found a bug in 2.1.9 (is is the Debian squeeze release), probably due to my mis-use of src_ipaddr in the home_server stanza. My proxy definition looks like: ---- templates { eduroam-proxy { type = auth+acct port = 1812 require_message_authenticator = yes status_check = status-server } eduroam-proxy6 { src_ipaddr = ${local.MY.addr.eduroam.v6} $template eduroam-proxy } eduroam-proxy4 { src_ipaddr = ${local.MY.addr.eduroam.v4} $template eduroam-proxy } } home_server jrs.0.v6 { ipv6addr = ${local.jrs.0.addr.v6} secret = ${local.jrs.0.secret} $template eduroam-proxy6 } home_server jrs.0.v4 { ipaddr = ${local.jrs.0.addr.v4} secret = ${local.jrs.0.secret} $template eduroam-proxy4 } [snipped] ---- This seems to cause FreeRADIUS to spin when opening the proxy sockets, the output ---- root@chlorine:/etc/freeradius# gdb /usr/sbin/freeradius GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabi". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/freeradius...Reading symbols from /usr/lib/debug/usr/sbin/freeradius...done. (no debugging symbols found)...done. (gdb) run -X Starting program: /usr/sbin/freeradius -X [snipped] listen { type = "acct" ipaddr = 212.219.238.5 port = 0 clients = "eduroam" } ^C <--- hangs Program received signal SIGINT, Interrupt. 0x0000e614 in fr_ipaddr_cmp () at misc.c:543 543 misc.c: No such file or directory. in misc.c (gdb) where #0 0x0000e614 in fr_ipaddr_cmp () at misc.c:543 #1 0x00019f44 in proxy_new_listener (ipaddr=0x137430, exists=1) at listen.c:1726 #2 0x0002eb90 in home_server_create_callback (ctx=0x140a98, data=<value optimized out>) at realms.c:2214 #3 0x40035930 in WalkNodeInOrder (X=0x137228, callback=0x2eb6c <home_server_create_callback>, context=0x140a98) at rbtree.c:544 #4 0x40035918 in WalkNodeInOrder (X=0x5c838, callback=0x2eb6c <home_server_create_callback>, context=0x140a98) at rbtree.c:540 #5 0x40035918 in WalkNodeInOrder (X=0x5ca08, callback=0x2eb6c <home_server_create_callback>, context=0x140a98) at rbtree.c:540 #6 0x0002eb24 in home_server_create_listeners (ctx=<value optimized out>) at realms.c:2244 #7 0x0001a6ac in listen_init (config=0x4c020, head=0xbee39b2c) at listen.c:2194 #8 0x0002ab40 in radius_event_init (cs=0x4c020, spawn_flag=0) at event.c:3599 #9 0x000223fc in main (argc=2, argv=<value optimized out>) at radiusd.c:328 (gdb) ---- If I remove the 'src_ipaddr' entries from my templates then things run as normal; however as my RADIUS server has ten IP addresses, without this it is completely un-usabled. If I move the 'src_ipaddr' entry explicitly into my 'home_server' stanza, then I get an assert(): ---- [snipped] listen { type = "acct" ipaddr = 212.219.238.5 port = 0 clients = "eduroam" } Listening on authentication address ::1 port 1812 as server eduroam Listening on authentication address 2001:630:1b:6003:372d:f782:e3d9:ae6 port 1812 as server eduroam Listening on authentication address 212.219.238.5 port 1812 as server eduroam Listening on accounting address 2001:630:1b:6003:372d:f782:e3d9:ae6 port 1813 as server eduroam Listening on accounting address 212.219.238.5 port 1813 as server eduroam Listening on proxy address ::1 port 1814 Listening on proxy address 2001:630:1b:6003:372d:f782:e3d9:ae6 port 55212 Listening on proxy address 2001:630:1b:6003:372d:f782:e3d9:ae6 port 39406 ASSERT FAILED event.c[3639]: proxy_fds[this->fd & 0x1f] == -1 Aborted ---- Further investigation shows that if I have more than one 'src_ipaddr' entry present, I get no assert() and things spin again. So the spin bug seems unrelated to my templating, but is triggered as the template creates multiple src_ipaddr's, whilst I cannot use a single src_ipaddr as I end up with an assert(). Cheers -- Alexander Clouter .sigmonster says: Optimization hinders evolution.
Alexander Clouter wrote:
Found a bug in 2.1.9 (is is the Debian squeeze release), probably due to my mis-use of src_ipaddr in the home_server stanza.
My proxy definition looks like:
Do you have *more* of a configuration? That one doesn't work as-is, and if I replace ${local...} with a real IP, the server starts up fine.
#0 0x0000e614 in fr_ipaddr_cmp () at misc.c:543
Well... that shouldn't hang. Maybe what's happening is that the binary tree is being modified while it's being iterated over.
If I remove the 'src_ipaddr' entries from my templates then things run as normal; however as my RADIUS server has ten IP addresses, without this it is completely un-usabled.
OK...
If I move the 'src_ipaddr' entry explicitly into my 'home_server' stanza, then I get an assert():
That can be fixed. See the attached patch (event.c). If it works, it should go into 2.1.10.
Further investigation shows that if I have more than one 'src_ipaddr' entry present, I get no assert() and things spin again.
More that one src_ipaddr... where? At all? Or more than one in the same home_server section? See also the realms.c patch. That may address the spinning issue. I'd like to release 2.1.10 ASAP, so if this could get tested soon... Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Alexander Clouter wrote:
Found a bug in 2.1.9 (is is the Debian squeeze release), probably due to my mis-use of src_ipaddr in the home_server stanza.
Occurs in the v2.1.x branch too, last commit 8fadcb9d1d7fa8c5b92cc0e5a21a5bbd3673de72, but I guess you already guessed this as there have been no recently tweaks to those relevant functions.
My proxy definition looks like:
Do you have *more* of a configuration?
Well yes, I do thank you very much. </don't-you-talk-to-me-like-that> Guess it was my fault not posting the entire tarball of /etc/freeradius here blatted onto the mailing list...sorry.
That one doesn't work as-is, and if I replace ${local...} with a real IP, the server starts up fine.
Well I included what I thought was enough to replicate the issue and get over what I was doing and how (I thought I had it pinned down to 'src_ipaddr' being the culprit). Obviously not as changing to hardcoded values at my end has no effect and I still get the spinning issue. Doing a dumb straight replacement of '${local.MY.addr.eduroam.v4}' to '212.219.238.5' and '${local.MY.addr.eduroam.v6}' to '2001:630:1b:6003:372d:f782:e3d9:ae6' in my template changes nothing. Doing a just as dumb removing the cascading templating and moving 'src_ipaddr = ...' directly into the home_server stanza also changes nothing. Doing an equally as dumb forgetting templating and duplicating everything needed into home_server also...<drum roll> changes nothing. http://stuff.digriz.org.uk/freeradius-hang.tar.bz2
If I move the 'src_ipaddr' entry explicitly into my 'home_server' stanza, then I get an assert():
That can be fixed. See the attached patch (event.c). If it works, it should go into 2.1.10.
Well the assert() issue is no more, so now we are just down to the spinning when you have more than one src_ipaddr...
Further investigation shows that if I have more than one 'src_ipaddr' entry present, I get no assert() and things spin again.
More that one src_ipaddr... where? At all? Or more than one in the same home_server section?
'At all', as yeah of cause multiple 'src_ipaddr' makes perfect sense within the same home_server stanza... *sigh* Thanks for your vote of confidence, if you had spent a minute looking at my original email you would have seen when you unroll the templating you get a *single* src_ipaddr key/value pair in each home_server. The spinning occurs when you have more than one src_ipaddr present across all your home_server definitions, regardless if they are for different address families. So even if for the first home_server you have v6 and the second home_server you have v4 src_ipaddr...it spins. Same happens for v6-v6 and v4-v4 combinations, and of course v6-v6-v4, v4-v4-v6, etc etc ad nausem. You'll see the 'unrolling' I have done in the 'LOCAL/proxy.conf' file of the linked to tarball above.
See also the realms.c patch. That may address the spinning issue.
Where's that patch? I cannot see anything in the git log for any branch so I'm guessing it's elsewhere (missing attachment?). Cheers -- Alexander Clouter .sigmonster says: Adults die young.
Alexander Clouter wrote:
Well yes, I do thank you very much. </don't-you-talk-to-me-like-that>
It's been a bad week. You have *no* idea.
Guess it was my fault not posting the entire tarball of /etc/freeradius here blatted onto the mailing list...sorry.
:)
I'll try to take a look over the next bit.
That can be fixed. See the attached patch (event.c). If it works, it should go into 2.1.10.
Well the assert() issue is no more, so now we are just down to the spinning when you have more than one src_ipaddr...
OK. I've committed the event.c patch.
'At all', as yeah of cause multiple 'src_ipaddr' makes perfect sense within the same home_server stanza... *sigh* Thanks for your vote of confidence, if you had spent a minute looking at my original email you would have seen when you unroll the templating you get a *single* src_ipaddr key/value pair in each home_server.
Yes... well...
The spinning occurs when you have more than one src_ipaddr present across all your home_server definitions, regardless if they are for different address families. So even if for the first home_server you have v6 and the second home_server you have v4 src_ipaddr...it spins. Same happens for v6-v6 and v4-v4 combinations, and of course v6-v6-v4, v4-v4-v6, etc etc ad nausem.
Well, I've tried it with v4 && v6 home servers. No hang was seen.
Where's that patch? I cannot see anything in the git log for any branch so I'm guessing it's elsewhere (missing attachment?).
Attached now. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
The spinning occurs when you have more than one src_ipaddr present across all your home_server definitions, regardless if they are for different address families. So even if for the first home_server you have v6 and the second home_server you have v4 src_ipaddr...it spins. Same happens for v6-v6 and v4-v4 combinations, and of course v6-v6-v4, v4-v4-v6, etc etc ad nausem.
Well, I've tried it with v4 && v6 home servers. No hang was seen.
Where's that patch? I cannot see anything in the git log for any branch so I'm guessing it's elsewhere (missing attachment?).
Attached now.
Still hangs... -- Alexander Clouter .sigmonster says: Duty, n: What one expects from others. -- Oscar Wilde
Alexander Clouter wrote:
Found a bug in 2.1.9 (is is the Debian squeeze release), probably due to my mis-use of src_ipaddr in the home_server stanza.
No... it turns out that with certain configurations, the server could turn a singly linked list into a circularly linked list. Oops. I've put a fix into git for 2.1.10. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Found a bug in 2.1.9 (is is the Debian squeeze release), probably due to my mis-use of src_ipaddr in the home_server stanza.
No... it turns out that with certain configurations, the server could turn a singly linked list into a circularly linked list. Oops.
I've put a fix into git for 2.1.10.
Testing and things work. Cheers -- Alexander Clouter .sigmonster says: It don't mean a THING if you ain't got that SWING!!
participants (2)
-
Alan DeKok -
Alexander Clouter