Problems with freeradius 1.1.5 (2.0.0) 20070322 with postgresql (SIGHUP => segmentation fault)
Hello freeradius-users, I'm running Freeradius 20070322 snapshot with postgresql backend. (I tried older versions too) I have 3 questions for you, all related to $subject. Everything is working fine (the radius is getting the nas clients from the database, doing db auth/acct, etc.) until we send a -HUP to the radiusd.. First one: 8x------8x----- $ /radius/sbin/radiusd -fsX $ killall -HUP radiusd rlm_sql (sql): Closing sqlsocket 4 rlm_sql (sql): Closing sqlsocket 3 rlm_sql (sql): Closing sqlsocket 2 rlm_sql (sql): Closing sqlsocket 1 rlm_sql (sql): Closing sqlsocket 0 read_config_files: reading realms Thu Mar 22 16:21:23 2007 : Info: rlm_sql (sql): Driver rlm_sql_postgresql (module rlm_sql_postgresql) loaded and linked Thu Mar 22 16:21:23 2007 : Info: rlm_sql (sql): Attempting to connect to radius@127.0.0.1:5432/dbradius Segmentation fault No core file.. I solved this problem by commenting out the "we do other magic" in mainconfig.c lines 1059->1064. This will disable debug level change on the fly facility, it's not that important anyway 8x-----8x------ Second: 8x-----8x------ rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 3 , fields = 5 rlm_sql (sql): Read entry nasname=1.2.3.4,shortname=nume,secret=secret rlm_sql (sql): Adding client 1.2.3.4 (nume) to clients list Segmentation fault (core dumped) #0 rbtree_insert (tree=0x7d4c4c55, Data=0x80025808) at rbtree.c:246 246 Current = tree->Root; (gdb) bt #0 rbtree_insert (tree=0x7d4c4c55, Data=0x80025808) at rbtree.c:246 #1 0x8000685d in client_add (clients=0x800fbb18, client=0x80025808) at client.c:231 #2 0xb7db29ca in rlm_sql_instantiate (conf=0x8012efc8, instance=0x7d4c4c55) at rlm_sql.c:347 #3 0x8000f77c in find_module_instance (modules=0x8012e5e0, instname=0x80130100 "sql") at modules.c:322 #4 0x80010243 in setup_modules (reload=1) at modules.c:917 #5 0x8000ed65 in read_mainconfig (reload=1) at mainconfig.c:1162 #6 0x80012dc0 in main (argc=2, argv=0xbfdb1a34) at radiusd.c:560 I add DEBUG2("OLD: %p",(void *)old_clients); DEBUG2("NEW: %p",(void *)clients); right before mainconfig.clients = clients; clients_free(old_clients); in mainparse.c Start radiusd -fsX OLD: (nil) NEW: 0x800fbb18 killall -HUP radiusd: OLD: 0x800fbb18 NEW: 0x800fbb18 rlm_sql (sql): Adding client 1.2.3.4 (nume) to clients list Segmentation fault (core dumped) So, we free the same location.. I guess the problem is in the clients_parse_section which doesnt return a new address space. clients.c - if (clients) return clients; + if (clients) clients_free(clients); mainconfig.c - clients_free(old_clients); + if ((void *)old_clients != (void *)clients) + clients_free(old_clients); solved the problem. Do I still need the clients_free(old_clients)? 8x----------8x------------ Three: 8x------------------------ There is any other way to make the radius re-reread its clients from database, without an expensive HUP (and not so easy to send when you add entries to db)? 8x------------------------ Thanks for scrolling this down.. Best wishes, Claudiu FILIP claudiu@globtel.ro Phone : +40344880100 http://www.globtel.ro Fax: +40344880113
Claudiu Filip wrote: ...
Second: 8x-----8x------ rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 3 , fields = 5 rlm_sql (sql): Read entry nasname=1.2.3.4,shortname=nume,secret=secret rlm_sql (sql): Adding client 1.2.3.4 (nume) to clients list Segmentation fault (core dumped)
OK. I don't put clients into SQL, so I haven't tested that portion of the code. ...
So, we free the same location.. I guess the problem is in the clients_parse_section which doesnt return a new address space.
A better solution is this: - remove the "read clients from SQL" code in src/modules/rlm_sql. - add configuration to the "clients" section, e.g.: client 192.168.0.0/16 { query = "%{sql: SELECT ....} } And have it do the SELECT, and parse the result at run time. It will take a bit of work to add that, but it's a much better solution. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
O/H Alan DeKok έγραψε:
Claudiu Filip wrote: ...
Second: 8x-----8x------ rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 3 , fields = 5 rlm_sql (sql): Read entry nasname=1.2.3.4,shortname=nume,secret=secret rlm_sql (sql): Adding client 1.2.3.4 (nume) to clients list Segmentation fault (core dumped)
OK. I don't put clients into SQL, so I haven't tested that portion of the code. ...
So, we free the same location.. I guess the problem is in the clients_parse_section which doesnt return a new address space.
A better solution is this:
- remove the "read clients from SQL" code in src/modules/rlm_sql. - add configuration to the "clients" section, e.g.:
client 192.168.0.0/16 { query = "%{sql: SELECT ....} }
Hmm that would mean stil having to add client entris in the clients.conf. We 'd like to avoid that when using sql. Something like: clients.conf: per_socket_clients { clients_query = "%{sql: SELECT .... } }
And have it do the SELECT, and parse the result at run time. It will take a bit of work to add that, but it's a much better solution.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Kostas Kalevras Network Operations Center - National Technical University of Athens http://kkalev.wordpress.com/
Kostas Kalevras wrote:
Hmm that would mean stil having to add client entris in the clients.conf. We 'd like to avoid that when using sql.
Yes. The reason is DoS attacks. My idea was to limit the number of IP's looked up in SQL by network. So if a particular network is getting lots of "new" clients, it may be a DoS attack, and the server can just start dropping the requests. In other words, it's OK for known clients to cause the server to do lots of SQL lookups. It's not OK for random people on the net to cause the server to do lots of SQL lookups. If there's a way to restrict the lookups to avoid DoS attacks, I'm all for it. Maybe something like doing lookups of new clients only once a second. That should rate-limit DoS attacks to something manageable, and still allow new clients to be discovered quickly. So adding 30 new clients would require at minimum 30s of time, but I that shouldn't be much of a problem... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (3)
-
Alan DeKok -
Claudiu Filip -
Kostas Kalevras