Ram, ty for the response, It doesn't seem to be having an effect until I restart the server. I know I have set this up in the past with no issues, is there anything obvious I could be missing? I will take a look again and if I am still having problems post the server debug etc. Paul. On 7/27/07, ram <talk2ram@gmail.com> wrote:

On 7/27/07, Paul Lambert < paul.lambert@gmail.com> wrote:

...

Hi all,

I think I might be being a little dense but when I add a NAS to my SQL database, it doesn't appear to be enabled until I restart my radius server.

Is there a way to automatically activate a new NAS device that I add to the SQL database?

NAS adding should be realtime i belive

i dont think you need to restart radius for that

ram

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Paul All of these questions have been discussed MANY times on the list. Please check the archives.. Peter On Sat 28 Jul 2007, Paul Lambert wrote:

Thanks,

I thought I might have been going crazy!!!

I however just tried hitting radiusd with a SIGHUP and it really didn't like it.... Output attached, I just got a segfault when I hit it with the next radius request.

Is there a cleaner way to make it re-read the nas list?

TIA Paul.

On 7/28/07, Peter Nixon <listuser@peternixon.net> wrote:

...

On Fri 27 Jul 2007, Paul Lambert wrote:

...

Hi all,

I think I might be being a little dense but when I add a NAS to my SQL database, it doesn't appear to be enabled until I restart my radius server.

Yep. Thats to way it's designed to protect against DoS attacks, otherwise every inbound packet from an unknown IP would trigger an SQL query which would mean killing a server would be possible with a few KB of spoofed UDP

packets..

...

Is there a way to automatically activate a new NAS device that I add to the SQL database?

cron ;-)

--

Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Peter Nixon http://peternixon.net/

Hi, I have now taken a look through the archives and I can't see a clean solution for reloading the nas without restarting. I assume this is what you were suggesting I do via cron? Paul. On 7/28/07, Paul Lambert <paul.lambert@gmail.com> wrote:

Peter,

Please accept my apologies for wasting your time.

Paul

On 7/28/07, Peter Nixon <listuser@peternixon.net > wrote:

...

Paul

All of these questions have been discussed MANY times on the list. Please check the archives..

Peter

On Sat 28 Jul 2007, Paul Lambert wrote:

...

Thanks,

I thought I might have been going crazy!!!

I however just tried hitting radiusd with a SIGHUP and it really didn't like it.... Output attached, I just got a segfault when I hit it with the next radius request.

Is there a cleaner way to make it re-read the nas list?

TIA Paul.

On 7/28/07, Peter Nixon <listuser@peternixon.net> wrote:

...

On Fri 27 Jul 2007, Paul Lambert wrote:

...

Hi all,

I think I might be being a little dense but when I add a NAS to my SQL database, it doesn't appear to be enabled until I restart my radius server.

Yep. Thats to way it's designed to protect against DoS attacks, otherwise every inbound packet from an unknown IP would trigger an SQL query which would mean killing a server would be possible with a few KB of spoofed UDP

packets..

...

Is there a way to automatically activate a new NAS device that I add to the SQL database?

cron ;-)

--

Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

--

Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Sat 28 Jul 2007, Paul Lambert wrote:

Hi,

I have now taken a look through the archives and I can't see a clean solution for reloading the nas without restarting. I assume this is what you were suggesting I do via cron?

Yep.. The short answer is that FreeRADIUS does not currently reload the nas table automatically, and does not currently support HUP properly. Not perfect, but thats the way it is. If you can think of a secure way to do either or both, and write a patch to implement it, we would be happy :-) Cheers -- Peter Nixon http://peternixon.net/

Yeah. That would be one way, but its kind of like saying we are going to introduce a new feature to a BMW that makes it dangerous at speeds over 100km so don't drive it on an autobahn... It is an issue that has been discussed previously and FreeRADIUS is unlikely to ever do an SQL SELECT of the nas table for every inbound packet. What may be possible is to reload the nas list at certain intervals (from cron is the easiest) but until/unless HUP handling is improved that is problematic for deployments that need to keep session state (ie. EAP users). If you dont use EAP, then there is no problem doing a full restart on a regular basis.. Cheers Peter On Sun 29 Jul 2007, Paul Lambert wrote:

Thanks for your help guys.

I guess a way to prevent the DoS is through the correct use of a firewall?

Kind regards, Paul.

On 7/28/07, Peter Nixon <listuser@peternixon.net> wrote:

...

On Sat 28 Jul 2007, Paul Lambert wrote:

...

Hi,

I have now taken a look through the archives and I can't see a clean solution for reloading the nas without restarting. I assume this is what you were suggesting I do via cron?

Yep.. The short answer is that FreeRADIUS does not currently reload the nas table automatically, and does not currently support HUP properly. Not perfect, but thats the way it is.

If you can think of a secure way to do either or both, and write a patch to implement it, we would be happy :-)

-- Peter Nixon http://peternixon.net/

A.L.M.Buxey@lboro.ac.uk said:

how about updating the NAS list from SQL via, for example, an SNMP write command or a special RADIUS command packet. both of these could have security protection to prevent DoS (eg the SNMP write from only certain locations (firewalled) and has password too of course... the RADIUS command packet could have a shared secret requirement and/or use the FR unlang/attribute protections for access/accept

I'd settle for having it reload on a configurable amount of time ... # time between NAS table reloads if using SQL # default is 1 hour # set to 0 to disable NAS table reloading nas_table_reload_time = 1h So each request FR handles would start with this pseudo-code ... if (nas_table_reload_time AND (last_nas_table_read < (NOW - nas_table_reload_time)) { reload_nas_table(); last_nas_table_read = NOW; } IMHO this would be a good compromise. Easy to implement (for someone like Alan!), very low impact on the server (with the default setting), and allows the admin to set the reload time that suits their site. I'd set mine to 24h, as I hardly ever change my NAS setup, but some folk might need 15m if they have high NAS turnover.

alan

-- hugh

On 2007-07-29 19:13, Arran Cudbard-Bell wrote:

Hugh Messenger wrote:

...

A.L.M.Buxey@lboro.ac.uk said:

...

how about updating the NAS list from SQL via, for example, an SNMP write command or a special RADIUS command packet. both of these could have security protection to prevent DoS (eg the SNMP write from only certain locations (firewalled) and has password too of course... the RADIUS command packet could have a shared secret requirement and/or use the FR unlang/attribute protections for access/accept

I agree with Alan B, SNMP write is the way to go with this. It's a nice standard mechanism which can be triggered by almost anything. Generally in most implementations of an SQL based NAS list, some script somewhere is going to be adding rows to the SQL table, and adding a few extra lines into that script to poke the server isn't going to be very hard in any high level interpreted language. I'd settle for having it reload on a configurable amount of time ...

# time between NAS table reloads if using SQL # default is 1 hour # set to 0 to disable NAS table reloading nas_table_reload_time = 1h

So each request FR handles would start with this pseudo-code ...

if (nas_table_reload_time AND (last_nas_table_read < (NOW - nas_table_reload_time)) { reload_nas_table(); last_nas_table_read = NOW; }

IMHO this would be a good compromise. Easy to implement (for someone like Alan!), very low impact on the server (with the default setting), and allows the admin to set the reload time that suits their site. I'd set mine to 24h, as I hardly ever change my NAS setup, but some folk might need 15m if they have high NAS turnover.

I can't help but think there might be something more complicated to this, else it would have been done already. The mechanism by which a reloading of SQL clients is triggered could be quite arbitrary, but changing memory structures whilst processing a packet could cause some nasty issues... But i'm not a C programmer, and Alan Is.

Alan if you could explain the technical reason behind the difficulty in adding this feature, users might be in a better posistion to offer suggestions / patches.

I don't know freeradius source code very well but after briefly looking into the rlm_sql.c I think it is possible. It seems that currently rlm_sql simply adds one client after another: while(rlm_sql_fetch_row(sqlsocket, inst) == 0) { (...) c = rad_malloc(sizeof(RADCLIENT)); memset(c, 0, sizeof(RADCLIENT)); (...) c->next = mainconfig.clients; mainconfig.clients = c; } So, currently it may be hard to remove old ones since it is unknown if they comes from rlm_sql or a client file. I see two solutions: save somewhere original "mainconfig.clients" pointer or mark using additional flag clients with rlm_sql origin. Switching beetwen old and new nas table could be atomic and we can keep the old one for a while (for example to the next scheduled reload) to be sure that no one else is using it (client_find() and client_walk() callers). Best regards, Krzysztof Olędzki

On Mon 30 Jul 2007, Stefan Winter wrote:

Hi,

...

It is an issue that has been discussed previously and FreeRADIUS is unlikely to ever do an SQL SELECT of the nas table for every inbound packet. What may be possible is to reload the nas list at certain intervals (from cron is the easiest) but until/unless HUP handling is improved that is problematic for deployments that need to keep session state (ie. EAP users). If you dont use EAP, then there is no problem doing a full restart on a regular basis..

regular checks still would be a waste of resources most of the time (how often do you add a NAS?). How about:

- doing the SQL query when it encounters a request from a new, unknown IP address, - RATE-LIMITED to once per minute or so.

That would make re-reading event-driven, and not make the server be DoS'ed when a wave of fake requests comes in. Not sure how difficult to implement this though...

Yes. I think this would be a reasonable option, which should default to off. This should of course be rate limitted to one re-read per minute for the whole server, not per source IP as spoofing UDP packets it obviously not terribly difficult.. -- Peter Nixon http://peternixon.net/

Krzysztof Olędzki wrote:

I'm not sure it this is a good idea. What if you need to change for example a shared secret?

Poke it with radclient from a host that is not in the client table? -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com

Hi Paul, Saturday, July 28, 2007, 6:08:23 PM, you wrote:

I however just tried hitting radiusd with a SIGHUP and it really didn't like it.... Output attached, I just got a segfault when I hit it with the next radius request.

Currently, I'm able to run a SIGHUPed freeradius 20070420 snapshot, with postgresql backend. If you search through the archives, I've sent a rude email to the list back in March 2007 (containing 3 questions in one message).. I'm sorry for that email, but I'll be very happy (even now) to get an advice about the workarounds. The server seems to run ok so far, without any problems but I didnt put too much stress on it. My solution to let the freeradius handle a SIGHUP was: 1)

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

2)

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)?

...

Is there a way to automatically activate a new NAS device that I add to the SQL database? cron ;-)

My advice is to create a database trigger on INSERTs, UPDATEs, DELETEs. For example, my postgresql trigger written in plperlu: CREATE OR REPLACE FUNCTION restart_radiusd() RETURNS TRIGGER AS $rr_rad$ system("/usr/bin/sudo /usr/bin/killall -HUP radiusd"); return; $rr_rad$ LANGUAGE plperlu; DROP TRIGGER IF EXISTS need_to_restart_radiusd ON nas_table; CREATE TRIGGER need_to_restart_radiusd AFTER INSERT OR UPDATE OR DELETE ON nas_table FOR EACH STATEMENT EXECUTE PROCEDURE restart_radiusd(); /etc/sudoers: postgresqluser ALL=(radiususer) NOPASSWD: /usr/bin/killall -HUP radiusd This way, you will restart freeradius only when needed. You said that your backend is mysql, you will probably be able to come up with the mysql version, but your main issue is not that. SIGHUP must work. Best regards, Claudiu Filip @: claudiu@globtel.ro Http://www.globtel.ro T:+40344880100 F:+40344880113

Then pipe the susdo command though ssh... -Peter On Tue 31 Jul 2007, Santiago Balaguer García wrote:

I have one question to this, you suposed that RADIUS and DataBase services are in the same machine, what happens if these services are in severa or there are replicate servers?

...

My advice is to create a database trigger on INSERTs, UPDATEs, DELETEs. For example, my postgresql trigger written in plperlu:

CREATE OR REPLACE FUNCTION restart_radiusd() RETURNS TRIGGER AS $rr_rad$          system("/usr/bin/sudo /usr/bin/killall -HUP radiusd");          return; $rr_rad$ LANGUAGE plperlu; DROP TRIGGER IF EXISTS need_to_restart_radiusd ON nas_table; CREATE TRIGGER need_to_restart_radiusd AFTER INSERT OR UPDATE OR DELETE ON nas_table FOR EACH STATEMENT EXECUTE PROCEDURE restart_radiusd();

/etc/sudoers: postgresqluser      ALL=(radiususer) NOPASSWD: /usr/bin/killall -HUP radiusd

This way, you will restart freeradius only when needed. You said that your backend is mysql, you will probably be able to come up with the mysql version, but your main issue is not that. SIGHUP must work.

Coches nuevos, coches de ocasión, coches de Km 0 Si piensas en cambiar de coche, MSN Motor.

-- Peter Nixon http://peternixon.net/

Thanks for that Claudiu - I'll have to see what I can do :) Handling the sighup would be a big deal. I am adding my NAS via a php script so I can easily ask it to give the server a kick once i've added a NAS. It may be that I can live with an hourly cron job - will have to see. In theory there could be a lot of NAS deviced being added... Paul. On 7/31/07, Claudiu Filip <claudiu@globtel.ro> wrote:

Hi Santiago,

Tuesday, July 31, 2007, 11:21:36 AM, you wrote:

...

I have one question to this, you suposed that RADIUS and DataBase services are in the same machine, what happens if these services are in severa or there are replicate servers?

Most probably you will have the radius and the database on separate machines. If you have replication or if you have many updates (a farm of dyndns radius clients) or if you dont want to HUP the server too often, you will have to create a simple program to just NOTIFY another application responsible with HUPing the freeradius.

Example from a fantasy world: == database trigger ============

CREATE OR REPLACE FUNCTION restart_radiusd() RETURNS TRIGGER AS $rr_rad$ use IO::Socket; my($sock, $SERVER_IP, $SERVER_PORT); $SERVER_IP = '1.2.3.4'; $SERVER_PORT = 1818; $sock = IO::Socket::INET->new(Proto => 'udp', PeerPort => $SERVER_PORT, PeerAddr => $SERVER_IP); $sock->send("please restart"); return; $rr_rad$ LANGUAGE plperlu;

===============================

This trigger will send an udp packet to 1.2.3.4:1818 with the text "please restart". On the 1.2.3.4 end, we'll have a little gipsy opening the door every min_restart_interval seconds to check for stickies.. He's very sensitive and we must be polite to him.

== freeradius machine ========= #!/usr/bin/perl use IO::Socket; my ($server, $request, $server_port, $min_restart_interval, $need_to_restart, $msg_max_length, $message);

$min_restart_interval = 300; #seconds $server_port = 1818; $need_to_restart = 0; $msg_max_length = 1024;

$server = IO::Socket::INET->new(LocalPort => $server_port, Proto => "udp") or die "Couldn't bind udp server on port $server_port : $@\n";

$SIG{ALRM} = sub { if ($need_to_restart == 1) { system("/usr/bin/sudo /usr/bin/killall -HUP radiusd"); $need_to_restart = 0; } alarm $min_restart_interval; }; alarm $min_restart_interval; while (1) { $request = $server->recv($message, $msg_max_length); $need_to_restart = 1 if ($message =~ /please/); } ===============================

In the real world, you also have many other ways, like using ssh, RPC - rsh... If you are paranoic about opening a port, i guess you can also make freeradius to shoot itself in the leg by using rlm_exec and %{Client-IP-Address}.

Best regards,

Claudiu Filip @: claudiu@globtel.ro Http://www.globtel.ro T:+40344880100 F:+40344880113

...

...

My advice is to create a database trigger on INSERTs, UPDATEs, DELETEs. For example, my postgresql trigger written in plperlu:

CREATE OR REPLACE FUNCTION restart_radiusd() RETURNS TRIGGER AS $rr_rad$ system("/usr/bin/sudo /usr/bin/killall -HUP radiusd"); return; $rr_rad$ LANGUAGE plperlu; DROP TRIGGER IF EXISTS need_to_restart_radiusd ON nas_table; CREATE TRIGGER need_to_restart_radiusd AFTER INSERT OR UPDATE OR DELETE ON nas_table FOR EACH STATEMENT EXECUTE PROCEDURE restart_radiusd();

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html