Fwd: Child is hung (max_request)
Hi Team, We need your help to fix our radius server error. I kindly request you to help us on the same. We are facing 'Child is hung' message in our radius server and we have to restart radius server to become normal. As per our analysis the error message comes whenever there are more load on the server. *Configuration: * max_request_time = 30 cleanup_delay = 5 *max_requests = 12800* *max_queue_size = 131072* start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 Our system TPS is 100 (at max 120). Since we have kept max_request as 12,800 and max_request_time as 30 seconds, we will be able to support max backlog 3000 (TPS x max_request_time). That is our system can clear first 3000 requests in the queue before it faces 'time expire' (max_request_time). However we have set max_request as 12,800 during high load, system is facing 'child is hung' when the backlog grows more than 3000. Is our above understanding correct? If it is correct, we can resolve our issue by setting max_request as 3000 i.e. during high load, we will not face 'child is hung ' and no need to restart radius server to become normal. Looking forward for your reply. -- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
Set those values as much as you like, or won't speed up the backend which is causing you the issue. Look at the backend components and work on those (mysql by any chance? ) All you are doing is making a fatter pipe to the slow backend, which may actually make the problem worse. alan
Hi Alan, Thanks a lot for your immediate help on Radius server issue. Basically we are trying a Radius to Diameter and Diameter to Radius converter. Radius server take radius request and only for accouting request (not for access), it will send it to another module via TCP/IP (local server) and the module to convert it to diameter request to send it to IN server. The same module will response to Radius server for any response comes from IN. So Radius server can support only 100 TPS at max. Root cause for "Child is hung" is we have fatter pipe and most requests getting time out without picked by Radius worker thread. Instead of doing that, we can set the value to low (3000 = TPS * max_request_time [= 30 seconds]). Is my understanding correct? (as I explained in my first email). Because when radius server faces "child is hung", we need to restart to bring it normal. Please let me know whether it is a good idea to set the max_request to 3000 so that radius server will not face "child is hung" and no need to restart the server to resolve the same. On Fri, Nov 21, 2014 at 2:33 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Set those values as much as you like, or won't speed up the backend which is causing you the issue. Look at the backend components and work on those (mysql by any chance? )
All you are doing is making a fatter pipe to the slow backend, which may actually make the problem worse.
alan
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
srithar jeevadurai wrote:
Radius server take radius request and only for accouting request (not for access), it will send it to another module via TCP/IP (local server) and the module to convert it to diameter request to send it to IN server. The same module will response to Radius server for any response comes from IN.
So Radius server can support only 100 TPS at max.
Then don't send more that 100 TPS to the RADIUS server. Otherwise, it won't work.
Because when radius server faces "child is hung", we need to restart to bring it normal.
For v2, please try the v2.x.x branch. I've put a patch in which may help this.
Please let me know whether it is a good idea to set the max_request to 3000 so that radius server will not face "child is hung" and no need to restart the server to resolve the same.
It doesn't solve the problem. It just delays the problem. Alan DeKok.
Hi Alan, ============================================================================== We are using Radius 2.2.1. Can we fix the child hung by putting any patch ? For my understanding of Radius server behavior May I know the possible root causes for "Child is hung" ? In our scenario, I believe that when backlog is growing, some point of time each request faces "max_request_time" - out so it is giving child is hung message i.e. the request is in queue but no worker thread has picked it. ==============================================================================
Please let me know whether it is a good idea to set the max_request to 3000 so that radius server will not face "child is hung" and no need to restart the server to resolve the same.
It doesn't solve the problem. It just delays the problem. May I know why we will not be able to solve and it will delays the problem please? ============================================================================== On Fri, Nov 21, 2014 at 10:28 PM, Alan DeKok <aland@deployingradius.com> wrote:
srithar jeevadurai wrote:
Radius server take radius request and only for accouting request (not for access), it will send it to another module via TCP/IP (local server) and the module to convert it to diameter request to send it to IN server. The same module will response to Radius server for any response comes from IN.
So Radius server can support only 100 TPS at max.
Then don't send more that 100 TPS to the RADIUS server. Otherwise, it won't work.
Because when radius server faces "child is hung", we need to restart to bring it normal.
For v2, please try the v2.x.x branch. I've put a patch in which may help this.
Please let me know whether it is a good idea to set the max_request to 3000 so that radius server will not face "child is hung" and no need to restart the server to resolve the same.
It doesn't solve the problem. It just delays the problem.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
srithar jeevadurai wrote:
We are using Radius 2.2.1. Can we fix the child hung by putting any patch ?
If you're going to patch it yourself, you'll need to look at github. Or, download the link I sent and use that.
For my understanding of Radius server behavior
May I know the possible root causes for "Child is hung" ?
A bug. The root causes are buried inside of the server. Since you're not familiar with the server code, any explanation won't help.
In our scenario, I believe that when backlog is growing, some point of time each request faces "max_request_time" - out so it is giving child is hung message i.e. the request is in queue but no worker thread has picked it.
No.
May I know why we will not be able to solve and it will delays the problem please?
If the problem is that the home server is down, increasing the internal queue size won't help. The home server will still be down. Alan DeKok.
Hi Alan, Thanks a lot for your response. May I know the patch link to apply for Radius version 2.2.1.? if I download latest stable version and rebuild the server (using our customized rlm module) then would that not required to apply patch? May I know latest stable version of FreeRadius (3.0.5 or 2.2.6) and the bug free ? On Fri, Nov 21, 2014 at 11:36 PM, Alan DeKok <aland@deployingradius.com> wrote:
srithar jeevadurai wrote:
We are using Radius 2.2.1. Can we fix the child hung by putting any patch ?
If you're going to patch it yourself, you'll need to look at github. Or, download the link I sent and use that.
For my understanding of Radius server behavior
May I know the possible root causes for "Child is hung" ?
A bug. The root causes are buried inside of the server. Since you're not familiar with the server code, any explanation won't help.
In our scenario, I believe that when backlog is growing, some point of time each request faces "max_request_time" - out so it is giving child is hung message i.e. the request is in queue but no worker thread has picked it.
No.
May I know why we will not be able to solve and it will delays the problem please?
If the problem is that the home server is down, increasing the internal queue size won't help. The home server will still be down.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
Why are you making this so unnecessary complicated and convoluted for yourself!? Just use 2.2.6
srithar jeevadurai wrote:
May I know the patch link to apply for Radius version 2.2.1.?
See github. If you're going to hack up version 2.2.1, you're on your own.
if I download latest stable version and rebuild the server (using our customized rlm module) then would that not required to apply patch?
That's what I said.
May I know latest stable version of FreeRadius (3.0.5 or 2.2.6) and the bug free ?
I said the patch was in the v2.x.x branch in git. So... why ask if the patch is elsewhere? Go look at the github link I sent out. Alan DeKok.
On 21.11.2014 14:13, srithar jeevadurai wrote:
Radius server take radius request and only for accouting request (not for access), it will send it to another module via TCP/IP (local server) and the module to convert it to diameter request to send it to IN server. The same module will response to Radius server for any response comes from IN.
Your translation module is better to listen RADIUS, not home-grown protocol. In this case you can configure freeradius to proxy RADIUS requests to your module. freeradius can proxy RADIUS requests efficiently, without blocking a thread in wait for RADIUS response.
Hi LLiya, Thanks for your reply. If I understand your reply correctly. Our current implementation is like radius worker thread calls our customized module of Radius (rlm_raddia) to send request to diameter client (dia client will send the request to IN and reponse will be sent back to radius thread from dia client). It is a blocking call of Radius worker thread. If we implement, radius server as proxy then it will take request from NAS and send it to dia client (without waiting for response from dia client) which is non blocking call of radius worker thread. Dia client has to send response to radius server and radius server to send the repsonse to NAS. The only change here is rad-worker thread is no need to wait after sending request to dia client. Sending request and processing respose from dia client will happen idependedlly by FreeRad. If my above understanding is correct, Can we get a sample module code to send radius request to external process (here it is dia client) and process response from external process (idependedlly without waiting req-res). I hope that we would have used any IPC like TCP/IP or message queue etc. I need to know how to start with proxy radius server impementation for radius-diameter converter. It would be great if you can give me a document link on the same please. I thankful for your help on this. Thanks a lot in advance. On Sat, Nov 22, 2014 at 2:24 PM, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 21.11.2014 14:13, srithar jeevadurai wrote:
Radius server take radius request and only for accouting request (not for access), it will send it to another module via TCP/IP (local server) and the module to convert it to diameter request to send it to IN server. The same module will response to Radius server for any response comes from IN.
Your translation module is better to listen RADIUS, not home-grown protocol. In this case you can configure freeradius to proxy RADIUS requests to your module. freeradius can proxy RADIUS requests efficiently, without blocking a thread in wait for RADIUS response.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
srithar jeevadurai wrote:
If I understand your reply correctly. Our current implementation is like radius worker thread calls our customized module of Radius (rlm_raddia) to send request to diameter client (dia client will send the request to IN and reponse will be sent back to radius thread from dia client). It is a blocking call of Radius worker thread.
That design is wrong. The server should *never* block when it proxies packets. When you make the thread block, you are *guaranteeing* that the entire server will stop working. The server core implements proxying as an asynchronous operation. Any proxying *must* be asynchronous.
If we implement, radius server as proxy then it will take request from NAS and send it to dia client (without waiting for response from dia client) which is non blocking call of radius worker thread. Dia client has to send response to radius server and radius server to send the repsonse to NAS. The only change here is rad-worker thread is no need to wait after sending request to dia client. Sending request and processing respose from dia client will happen idependedlly by FreeRad.
Or, you could just add native Diameter support to the server.
If my above understanding is correct, Can we get a sample module code to send radius request to external process (here it is dia client) and process response from external process (idependedlly without waiting req-res). I hope that we would have used any IPC like TCP/IP or message queue etc.
Doing that requires major changes to the server core.
I need to know how to start with proxy radius server impementation for radius-diameter converter. It would be great if you can give me a document link on the same please.
There are no such implementation guides on the net. For a reason. The various software products are either commercial, or open source. For the open source products, you can just read the source code. For commercial ones... the product is their property, and they don't tell you how to write a competing product. You will need to figure this out on your own. Alan DeKok.
On 22.11.2014 18:01, srithar jeevadurai wrote:
Hi LLiya,
Thanks for your reply.
If I understand your reply correctly. Our current implementation is like radius worker thread calls our customized module of Radius (rlm_raddia) to send request to diameter client (dia client will send the request to IN and reponse will be sent back to radius thread from dia client). It is a blocking call of Radius worker thread.
Yes, your current implementation uses custom freeradius module that implements in-house protocol client. All freeradius modules are blocking and your module is not an exception.
If we implement, radius server as proxy then it will take request from NAS and send it to dia client (without waiting for response from dia client) which is non blocking call of radius worker thread. Dia client has to send response to radius server and radius server to send the repsonse to NAS. The only change here is rad-worker thread is no need to wait after sending request to dia client. Sending request and processing respose from dia client will happen idependedlly by FreeRad.
Yes, RADIUS proxy functionality of freeradius is non-blocking.
If my above understanding is correct, Can we get a sample module code to send radius request to external process (here it is dia client) and process response from external process (idependedlly without waiting req-res). I hope that we would have used any IPC like TCP/IP or message queue etc.
RADIUS proxy functionality does not need any freeradius module. RADIUS proxy functionality is already implemented in freeradius core. RADIUS proxy functionality sends RADIUS requests to external RADIUS server (called "home" server). If your preacct section sets control:Proxy-To-Realm attribute for the accounting request received by freeradius from NAS, freeradius core will proxy this accounting request to the home server associated with designated realm. When the answer comes from home server freeradius core will proxy this answer back to the NAS. Example configuration of freeradius proxy: # raddb/proxy.conf home_server radius-diameter-translator-1 { type = acct ipaddr = 127.0.0.1 port = 4013 secret = secret response_window = 3 no_response_fail = yes zombie_period = 86400 # 1 day revive_interval = 0 status_check = none } home_server_pool radius-diameter-translator { home_server = radius-diameter-translator-1 } realm radius-diameter-translator { acct_pool = radius_diameter_translator } # raddb/sites-available/default ... preacct { # Proxy all Accounting-Requests to radius-diameter-translator realm update control { Proxy-To-Realm := radius-diameter-translator } } ... Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following: NAS radiusd r-d-t diameter-server | | | | |RADIUS ACR | | | |------------>|RADIUS ACR | | | |------------>|Diameter ACR | | | |-------------->| | | | Diameter ACA| | | RADIUS ACA|<--------------| | RADIUS ACA|<------------| | |<------------| | |
I need to know how to start with proxy radius server impementation for radius-diameter converter. It would be great if you can give me a document link on the same please.
Proxy functionality is documented in raddb/proxy.conf.
Hi LLiya, It is very helpful. We will implement our converter module as you mentioned above. On Mon, Nov 24, 2014 at 12:28 PM, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 22.11.2014 18:01, srithar jeevadurai wrote:
Hi LLiya,
Thanks for your reply.
If I understand your reply correctly. Our current implementation is like radius worker thread calls our customized module of Radius (rlm_raddia) to send request to diameter client (dia client will send the request to IN and reponse will be sent back to radius thread from dia client). It is a blocking call of Radius worker thread.
Yes, your current implementation uses custom freeradius module that implements in-house protocol client. All freeradius modules are blocking and your module is not an exception.
If we implement, radius server as proxy then it will take request from
NAS and send it to dia client (without waiting for response from dia client) which is non blocking call of radius worker thread. Dia client has to send response to radius server and radius server to send the repsonse to NAS. The only change here is rad-worker thread is no need to wait after sending request to dia client. Sending request and processing respose from dia client will happen idependedlly by FreeRad.
Yes, RADIUS proxy functionality of freeradius is non-blocking.
If my above understanding is correct, Can we get a sample module code to
send radius request to external process (here it is dia client) and process response from external process (idependedlly without waiting req-res). I hope that we would have used any IPC like TCP/IP or message queue etc.
RADIUS proxy functionality does not need any freeradius module. RADIUS proxy functionality is already implemented in freeradius core. RADIUS proxy functionality sends RADIUS requests to external RADIUS server (called "home" server). If your preacct section sets control:Proxy-To-Realm attribute for the accounting request received by freeradius from NAS, freeradius core will proxy this accounting request to the home server associated with designated realm. When the answer comes from home server freeradius core will proxy this answer back to the NAS.
Example configuration of freeradius proxy:
# raddb/proxy.conf home_server radius-diameter-translator-1 { type = acct ipaddr = 127.0.0.1 port = 4013 secret = secret response_window = 3 no_response_fail = yes zombie_period = 86400 # 1 day revive_interval = 0 status_check = none } home_server_pool radius-diameter-translator { home_server = radius-diameter-translator-1 } realm radius-diameter-translator { acct_pool = radius_diameter_translator }
# raddb/sites-available/default ... preacct { # Proxy all Accounting-Requests to radius-diameter-translator realm update control { Proxy-To-Realm := radius-diameter-translator } } ...
Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following:
NAS radiusd r-d-t diameter-server | | | | |RADIUS ACR | | | |------------>|RADIUS ACR | | | |------------>|Diameter ACR | | | |-------------->| | | | Diameter ACA| | | RADIUS ACA|<--------------| | RADIUS ACA|<------------| | |<------------| | |
I need to know how to start with proxy radius server impementation for
radius-diameter converter. It would be great if you can give me a document link on the same please.
Proxy functionality is documented in raddb/proxy.conf.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
Iliya Peregoudov wrote:
Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following:
i.e. he needs to implement a RADIUS proxy. Just like FreeRADIUS. Take it from me, that's a lot of work. Anyone who asks for design diagrams on how to implement a RADIUS server has about 5 years of full-time work ahead of them. Alan DeKok.
On 24.11.2014 16:14, Alan DeKok wrote:
Iliya Peregoudov wrote:
Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following:
i.e. he needs to implement a RADIUS proxy. Just like FreeRADIUS.
Take it from me, that's a lot of work. Anyone who asks for design diagrams on how to implement a RADIUS server has about 5 years of full-time work ahead of them.
There is nothing inherently sophisticated in the RADIUS protocol itself. Implementing a RADIUS-to-Diameter translator is not inherently harder than implementing anything-else-to-Diameter translator. Topic starter has already implemented something-else-to-Diameter translator as a standalone process. To integrate it with RADIUS he has to implement RADIUS-to-something-else translator as a freeradius module, and this module does not work well. The problem with freeradius is that it was not designed to be used as extensible protocol translator. One cannot write a freeradius module that will translate RADIUS to any other protocol in non-blocking manner because freeradius module interface is blocking. So mentioned earlier freeradius module *can not* work well.
To make it simple, Is it possible to do following thing will FreeRadius? 1) collect auth request and response by itself. 2) collect accounting request and send it via TCP/IP to another process in the same host (say rad to dia converter). 3) collect response from the external process on same host (rad to dia converter) and send as radius response. In that way, I can use freeRadius as upfront module to handle the incoming radius request and FreeRadius server will process request and response idependently i.e. asyncronus. On Mon, Nov 24, 2014 at 8:35 PM, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 24.11.2014 16:14, Alan DeKok wrote:
Iliya Peregoudov wrote:
Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following:
i.e. he needs to implement a RADIUS proxy. Just like FreeRADIUS.
Take it from me, that's a lot of work. Anyone who asks for design diagrams on how to implement a RADIUS server has about 5 years of full-time work ahead of them.
There is nothing inherently sophisticated in the RADIUS protocol itself. Implementing a RADIUS-to-Diameter translator is not inherently harder than implementing anything-else-to-Diameter translator.
Topic starter has already implemented something-else-to-Diameter translator as a standalone process. To integrate it with RADIUS he has to implement RADIUS-to-something-else translator as a freeradius module, and this module does not work well.
The problem with freeradius is that it was not designed to be used as extensible protocol translator. One cannot write a freeradius module that will translate RADIUS to any other protocol in non-blocking manner because freeradius module interface is blocking. So mentioned earlier freeradius module *can not* work well.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
srithar jeevadurai wrote:
To make it simple,
Is it possible to do following thing will FreeRadius?
No. It's not possible right now.
1) collect auth request and response by itself. 2) collect accounting request and send it via TCP/IP to another process in the same host (say rad to dia converter). 3) collect response from the external process on same host (rad to dia converter) and send as radius response.
In that way, I can use freeRadius as upfront module to handle the incoming radius request and FreeRadius server will process request and response idependently i.e. asyncronus.
Implementing a robust proxy is *much* more difficult than just reading and writing packets. There are many additional things you need to do. The complexity in FreeRADIUS is there for a reason. It's *needed*. It's not just complexity for the sake of complexity. Alan DeKok.
On 24.11.2014 18:18, srithar jeevadurai wrote:
Is it possible to do following thing will FreeRadius?
1) collect auth request and response by itself. 2) collect accounting request and send it via TCP/IP to another process in the same host (say rad to dia converter). 3) collect response from the external process on same host (rad to dia converter) and send as radius response.
Yes, it is possible if the RADIUS protocol is used between freeradius process and translator process. Because only RADIUS proxying is implemented in freeradius in non-blocking manner.
On 24 Nov 2014, at 10:31, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 24.11.2014 18:18, srithar jeevadurai wrote:
Is it possible to do following thing will FreeRadius?
1) collect auth request and response by itself. 2) collect accounting request and send it via TCP/IP to another process in the same host (say rad to dia converter). 3) collect response from the external process on same host (rad to dia converter) and send as radius response.
Yes, it is possible if the RADIUS protocol is used between freeradius process and translator process. Because only RADIUS proxying is implemented in freeradius in non-blocking manner.
But then you're just writing a generic RADIUS to Diameter proxy, there's no FreeRADIUS specific functionality. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 24.11.2014 19:13, Arran Cudbard-Bell wrote:
On 24 Nov 2014, at 10:31, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 24.11.2014 18:18, srithar jeevadurai wrote:
Is it possible to do following thing will FreeRadius?
1) collect auth request and response by itself. 2) collect accounting request and send it via TCP/IP to another process in the same host (say rad to dia converter). 3) collect response from the external process on same host (rad to dia converter) and send as radius response.
Yes, it is possible if the RADIUS protocol is used between freeradius process and translator process. Because only RADIUS proxying is implemented in freeradius in non-blocking manner.
But then you're just writing a generic RADIUS to Diameter proxy, there's no FreeRADIUS specific functionality.
Yes, because freeradius in fact cannot help in building any protocol translator except of RADIUS to RADIUS proxy.
Hi Alan, LLiya, Arran Thanks a lot for your reply. Now I am clear on freeRadius usage. Once again thanks a lot for your time and knowledge sharing. On Mon, Nov 24, 2014 at 9:49 PM, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 24.11.2014 19:13, Arran Cudbard-Bell wrote:
On 24 Nov 2014, at 10:31, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 24.11.2014 18:18, srithar jeevadurai wrote:
Is it possible to do following thing will FreeRadius?
1) collect auth request and response by itself. 2) collect accounting request and send it via TCP/IP to another process in the same host (say rad to dia converter). 3) collect response from the external process on same host (rad to dia converter) and send as radius response.
Yes, it is possible if the RADIUS protocol is used between freeradius process and translator process. Because only RADIUS proxying is implemented in freeradius in non-blocking manner.
But then you're just writing a generic RADIUS to Diameter proxy, there's no FreeRADIUS specific functionality.
Yes, because freeradius in fact cannot help in building any protocol translator except of RADIUS to RADIUS proxy.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
Hi Team, I need one more information regarding 'radius.log' file. We enable FreeRadius server to do logging in radius.log file however the file is keeping growing in GB (in 15 days). Is there any way by changing the freeRadius configuration to switch the log file on daily basis? Please provide steps to change the configuration as well please. Or we have use logadm OS utility to switch logs on daily basis? Need your expert advise for the same. Thanks in advance for your reply. Regards, Srithar On Tue, Nov 25, 2014 at 11:22 AM, srithar jeevadurai < srijeevadurai1@gmail.com> wrote:
Hi Alan, LLiya, Arran
Thanks a lot for your reply. Now I am clear on freeRadius usage. Once again thanks a lot for your time and knowledge sharing.
On Mon, Nov 24, 2014 at 9:49 PM, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 24.11.2014 19:13, Arran Cudbard-Bell wrote:
On 24 Nov 2014, at 10:31, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 24.11.2014 18:18, srithar jeevadurai wrote:
Is it possible to do following thing will FreeRadius?
1) collect auth request and response by itself. 2) collect accounting request and send it via TCP/IP to another process in the same host (say rad to dia converter). 3) collect response from the external process on same host (rad to dia converter) and send as radius response.
Yes, it is possible if the RADIUS protocol is used between freeradius process and translator process. Because only RADIUS proxying is implemented in freeradius in non-blocking manner.
But then you're just writing a generic RADIUS to Diameter proxy, there's no FreeRADIUS specific functionality.
Yes, because freeradius in fact cannot help in building any protocol translator except of RADIUS to RADIUS proxy.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
On Wed, Nov 26, 2014 at 12:32 PM, srithar jeevadurai < srijeevadurai1@gmail.com> wrote:
Hi Team,
I need one more information regarding 'radius.log' file.
We enable FreeRadius server to do logging in radius.log file however the file is keeping growing in GB (in 15 days).
Is there any way by changing the freeRadius configuration to switch the log file on daily basis? Please provide steps to change the configuration as well please.
Or we have use logadm OS utility to switch logs on daily basis?
On supported packages, OS logrotate handles that, and the package provides a suitable config file, e.g. https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/redhat/freeradiu... for redhat-based ones. -- Fajar
Hi Fajar Thanks for your immediate reply. We are using solaris so we will be using logadm to rotate radius.log file. Can you please help us on the below query please? In our old setup logs [info], [Auth], [Error] messages are coming in the radius.log however we installed a new setup for testing, In that environment, we are able to see only [Auth] request only. Do we need to do any configuration change for the same? I request you to help us on the same. Old environment: Wed Nov 26 07:04:01 2014 : Auth: Login OK: [void] (from client 80.214.246.50 port 138538 cli 33754003481) Wed Nov 26 07:04:01 2014 :* Info: *Sending Access-Accept of id 87 to 80.214.246.50 port 24512 Wed Nov 26 07:04:01 2014 : Auth: Login OK: [void] (from client 80.214.246.50 port 620370 cli 33754522678) Wed Nov 26 07:04:01 2014 :* Info:* Sending Access-Accept of id 249 to 80.214.246.50 port 26400 Wed Nov 26 07:04:01 2014 : *Info: *Sending Accounting-Response of id 181 to 80.214.246.50 port 24208 Wed Nov 26 07:04:01 2014 : Auth: Login OK: [wap] (from client 80.214.246.50 port 354491 cli 33760384253) Wed Nov 26 07:04:01 2014 : Info: Sending Access-Accept of id 115 to 80.214.246.50 port 25328 Wed Nov 26 07:04:01 2014 : Auth: Login OK: [void] (from client 80.214.246.50 port 1063454 cli 33752451480) Wed Nov 26 07:04:01 2014 : Info: Sending Access-Accept of id 177 to 80.214.246.50 port 28112 Wed Nov 26 07:04:01 2014 : Info: Sending Accounting-Response of id 217 to 80.214.246.50 port 28288 Wed Nov 26 07:04:01 2014 : Info: Sending Accounting-Response of id 138 to 80.214.246.50 port 26752 Wed Nov 26 07:04:01 2014 : Auth: Login OK: [void] (from client 80.214.246.50 port 272074 cli 33752493319) Wed Nov 26 07:04:01 2014 : Info: Sending Access-Accept of id 58 to 80.214.246.50 port 25040 Wed Nov 26 07:04:01 2014 : Auth: Login OK: [wap] (from client 80.214.246.50 port 969236 cli 33754531480) Test environment: Wed Nov 26 06:57:38 2014 : Auth: Login OK: [rim] (from client 80.214.246.205 port 246270 cli 33751967609) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [wap] (from client 80.214.246.205 port 625396 cli 33751989192) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 622003 cli 33752154248) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 360576 cli 33752187516) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 258311 cli 33752251095) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 22914 cli 33755275343) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 418816 cli 33755182392) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [fr.lebara.mobi] (from client 80.214.246.205 port 355407 cli 33669191153) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 254720 cli 33752305854) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [rim] (from client 80.214.246.205 port 263735 cli 33752438645) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 1186388 cli 33761327963) Wed Nov 26 06:57:38 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 690043 cli 33754020443) Wed Nov 26 06:57:39 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 247805 cli 33755161856) Wed Nov 26 06:57:39 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 347615 cli 33754015697) Wed Nov 26 06:57:39 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 1137224 cli 33752778880) Wed Nov 26 06:57:39 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 622833 cli 33755319447) Wed Nov 26 06:57:39 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 811037 cli 33762997149) Wed Nov 26 06:57:39 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 1010223 cli 33752564689) Wed Nov 26 06:57:39 2014 : Auth: Login OK: [void] (from client 80.214.246.205 port 244300 cli 33755028608) On Wed, Nov 26, 2014 at 11:23 AM, Fajar A. Nugraha <list@fajar.net> wrote:
On Wed, Nov 26, 2014 at 12:32 PM, srithar jeevadurai < srijeevadurai1@gmail.com> wrote:
Hi Team,
I need one more information regarding 'radius.log' file.
We enable FreeRadius server to do logging in radius.log file however the file is keeping growing in GB (in 15 days).
Is there any way by changing the freeRadius configuration to switch the log file on daily basis? Please provide steps to change the configuration as well please.
Or we have use logadm OS utility to switch logs on daily basis?
On supported packages, OS logrotate handles that, and the package provides a suitable config file, e.g. https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/redhat/freeradiu... for redhat-based ones.
-- Fajar
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
In our old setup logs [info], [Auth], >[Error] messages are coming in the >radius.log however we installed a new setup for >testing, In that environment, we are >able to see only [Auth] request only. Do we need to do any configuration >change for the same?
If you look at the freeradius configuration files you will see what you need to change to alter logging . In this case read the config of your old server and that of your new and do spot the difference. Alan
Iliya Peregoudov wrote:
There is nothing inherently sophisticated in the RADIUS protocol itself. Implementing a RADIUS-to-Diameter translator is not inherently harder than implementing anything-else-to-Diameter translator.
The issue is less that, than other topics. If you have to ask "How do I write a daemon in C", the answer is "it takes a long time". Doing a *basic* implementation of something is easy. Doing a *robust* implementation is much harder.
Topic starter has already implemented something-else-to-Diameter translator as a standalone process. To integrate it with RADIUS he has to implement RADIUS-to-something-else translator as a freeradius module, and this module does not work well.
We're working in separating out the RADIUS portions from FreeRADIUS. e.g. it already does VMPS and DHCP. Adding full Diameter support is in progress.
The problem with freeradius is that it was not designed to be used as extensible protocol translator. One cannot write a freeradius module that will translate RADIUS to any other protocol in non-blocking manner because freeradius module interface is blocking. So mentioned earlier freeradius module *can not* work well.
Yes. The modules are *intended* to be blocking. And will *always* be blocking. The modules are protocol-agnostic interfaces to databases. Any other design is wrong, for a host of reasons. Protocol translation / proxying is something which belongs somewhere else. In v3, there are new "proto_dhcp" plugins, which have an API different from the module API. The result is that those plugins can implement protocols. Alan DeKok.
On 24 Nov 2014, at 10:05, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 24.11.2014 16:14, Alan DeKok wrote:
Iliya Peregoudov wrote:
Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following:
i.e. he needs to implement a RADIUS proxy. Just like FreeRADIUS.
Take it from me, that's a lot of work. Anyone who asks for design diagrams on how to implement a RADIUS server has about 5 years of full-time work ahead of them.
There is nothing inherently sophisticated in the RADIUS protocol itself. Implementing a RADIUS-to-Diameter translator is not inherently harder than implementing anything-else-to-Diameter translator.
Topic starter has already implemented something-else-to-Diameter translator as a standalone process. To integrate it with RADIUS he has to implement RADIUS-to-something-else translator as a freeradius module, and this module does not work well.
The problem with freeradius is that it was not designed to be used as extensible protocol translator. One cannot write a freeradius module that will translate RADIUS to any other protocol in non-blocking manner because freeradius module interface is blocking. So mentioned earlier freeradius module *can not* work well.
Yep FreeRADIUS ends up being completely synchronous so you can only have max workers packets in flight at the same time. The protocol translator is the direction we want to take the project though. It ensures that FreeRADIUS will continue to be useful even if the RADIUS protocol itself loses popularity. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi Team, I have understanded the proxy implementation. We are going to revamp our application with following design. I would like to know whether we will face any challenge in our design i.e. freeRadius stack wise. 1) GGSN to send request to Radius proxy (listening on standard ports 1812 and 1813). 2) Radius proxy to accept only auth and allocate IP address and response to auth request. 3) Radius proxy to forward acct request to home_server pool ( may be 2-3 home server on same server with different user id and port for acct request instead of 1813). 4) Home_server to handle only acct request and fwd it to rad-dia converter (diaclient). diaclient to convert rad request to dia request and send to IN. diaclient to send response back to corresponding home server and home server to send response back to Radius proxy. Same Host: 1 Radius Proxy, 3 Home-Servers (different user id and port no for acct req), 1 diaclient. Assumption: 1) 2-3 home servers can be configured and run on same host with different user name and port number for acct request. 2) Radius proxy to choose acct-start to be sent among home_servers and forward further accouting request (i.e. updates and stop) to same home_servers. i.e. load balancing can be automatically handled by Radius proxy. 3) Radius proxy server can be modified to allocate IP address and response to auth request (only for auth) and for acct-request it has to forward it to home_server. which configuration directs R-proxy to handle auth request by itself by calling customized module and forward acct to home_server. It will be great help if you can provide us same configuration for proxy to handle auth and forward acct to home_servers. Thanks in advance for your reply. Please let us know if there is any risk or not right approach in above explaned design. Regards, Srithar On Mon, Nov 24, 2014 at 12:28 PM, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 22.11.2014 18:01, srithar jeevadurai wrote:
Hi LLiya,
Thanks for your reply.
If I understand your reply correctly. Our current implementation is like radius worker thread calls our customized module of Radius (rlm_raddia) to send request to diameter client (dia client will send the request to IN and reponse will be sent back to radius thread from dia client). It is a blocking call of Radius worker thread.
Yes, your current implementation uses custom freeradius module that implements in-house protocol client. All freeradius modules are blocking and your module is not an exception.
If we implement, radius server as proxy then it will take request from
NAS and send it to dia client (without waiting for response from dia client) which is non blocking call of radius worker thread. Dia client has to send response to radius server and radius server to send the repsonse to NAS. The only change here is rad-worker thread is no need to wait after sending request to dia client. Sending request and processing respose from dia client will happen idependedlly by FreeRad.
Yes, RADIUS proxy functionality of freeradius is non-blocking.
If my above understanding is correct, Can we get a sample module code to
send radius request to external process (here it is dia client) and process response from external process (idependedlly without waiting req-res). I hope that we would have used any IPC like TCP/IP or message queue etc.
RADIUS proxy functionality does not need any freeradius module. RADIUS proxy functionality is already implemented in freeradius core. RADIUS proxy functionality sends RADIUS requests to external RADIUS server (called "home" server). If your preacct section sets control:Proxy-To-Realm attribute for the accounting request received by freeradius from NAS, freeradius core will proxy this accounting request to the home server associated with designated realm. When the answer comes from home server freeradius core will proxy this answer back to the NAS.
Example configuration of freeradius proxy:
# raddb/proxy.conf home_server radius-diameter-translator-1 { type = acct ipaddr = 127.0.0.1 port = 4013 secret = secret response_window = 3 no_response_fail = yes zombie_period = 86400 # 1 day revive_interval = 0 status_check = none } home_server_pool radius-diameter-translator { home_server = radius-diameter-translator-1 } realm radius-diameter-translator { acct_pool = radius_diameter_translator }
# raddb/sites-available/default ... preacct { # Proxy all Accounting-Requests to radius-diameter-translator realm update control { Proxy-To-Realm := radius-diameter-translator } } ...
Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following:
NAS radiusd r-d-t diameter-server | | | | |RADIUS ACR | | | |------------>|RADIUS ACR | | | |------------>|Diameter ACR | | | |-------------->| | | | Diameter ACA| | | RADIUS ACA|<--------------| | RADIUS ACA|<------------| | |<------------| | |
I need to know how to start with proxy radius server impementation for
radius-diameter converter. It would be great if you can give me a document link on the same please.
Proxy functionality is documented in raddb/proxy.conf.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
Hi Team, Can anyone help on below request please? Regards, Srithar On Sat, Mar 21, 2015 at 8:50 PM, srithar jeevadurai < srijeevadurai1@gmail.com> wrote:
Hi Team,
I have understanded the proxy implementation. We are going to revamp our application with following design.
I would like to know whether we will face any challenge in our design i.e. freeRadius stack wise.
1) GGSN to send request to Radius proxy (listening on standard ports 1812 and 1813). 2) Radius proxy to accept only auth and allocate IP address and response to auth request. 3) Radius proxy to forward acct request to home_server pool ( may be 2-3 home server on same server with different user id and port for acct request instead of 1813). 4) Home_server to handle only acct request and fwd it to rad-dia converter (diaclient). diaclient to convert rad request to dia request and send to IN. diaclient to send response back to corresponding home server and home server to send response back to Radius proxy.
Same Host: 1 Radius Proxy, 3 Home-Servers (different user id and port no for acct req), 1 diaclient.
Assumption: 1) 2-3 home servers can be configured and run on same host with different user name and port number for acct request. 2) Radius proxy to choose acct-start to be sent among home_servers and forward further accouting request (i.e. updates and stop) to same home_servers. i.e. load balancing can be automatically handled by Radius proxy. 3) Radius proxy server can be modified to allocate IP address and response to auth request (only for auth) and for acct-request it has to forward it to home_server. which configuration directs R-proxy to handle auth request by itself by calling customized module and forward acct to home_server. It will be great help if you can provide us same configuration for proxy to handle auth and forward acct to home_servers.
Thanks in advance for your reply. Please let us know if there is any risk or not right approach in above explaned design.
Regards, Srithar
On Mon, Nov 24, 2014 at 12:28 PM, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 22.11.2014 18:01, srithar jeevadurai wrote:
Hi LLiya,
Thanks for your reply.
If I understand your reply correctly. Our current implementation is like radius worker thread calls our customized module of Radius (rlm_raddia) to send request to diameter client (dia client will send the request to IN and reponse will be sent back to radius thread from dia client). It is a blocking call of Radius worker thread.
Yes, your current implementation uses custom freeradius module that implements in-house protocol client. All freeradius modules are blocking and your module is not an exception.
If we implement, radius server as proxy then it will take request from
NAS and send it to dia client (without waiting for response from dia client) which is non blocking call of radius worker thread. Dia client has to send response to radius server and radius server to send the repsonse to NAS. The only change here is rad-worker thread is no need to wait after sending request to dia client. Sending request and processing respose from dia client will happen idependedlly by FreeRad.
Yes, RADIUS proxy functionality of freeradius is non-blocking.
If my above understanding is correct, Can we get a sample module code to
send radius request to external process (here it is dia client) and process response from external process (idependedlly without waiting req-res). I hope that we would have used any IPC like TCP/IP or message queue etc.
RADIUS proxy functionality does not need any freeradius module. RADIUS proxy functionality is already implemented in freeradius core. RADIUS proxy functionality sends RADIUS requests to external RADIUS server (called "home" server). If your preacct section sets control:Proxy-To-Realm attribute for the accounting request received by freeradius from NAS, freeradius core will proxy this accounting request to the home server associated with designated realm. When the answer comes from home server freeradius core will proxy this answer back to the NAS.
Example configuration of freeradius proxy:
# raddb/proxy.conf home_server radius-diameter-translator-1 { type = acct ipaddr = 127.0.0.1 port = 4013 secret = secret response_window = 3 no_response_fail = yes zombie_period = 86400 # 1 day revive_interval = 0 status_check = none } home_server_pool radius-diameter-translator { home_server = radius-diameter-translator-1 } realm radius-diameter-translator { acct_pool = radius_diameter_translator }
# raddb/sites-available/default ... preacct { # Proxy all Accounting-Requests to radius-diameter-translator realm update control { Proxy-To-Realm := radius-diameter-translator } } ...
Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following:
NAS radiusd r-d-t diameter-server | | | | |RADIUS ACR | | | |------------>|RADIUS ACR | | | |------------>|Diameter ACR | | | |-------------->| | | | Diameter ACA| | | RADIUS ACA|<--------------| | RADIUS ACA|<------------| | |<------------| | |
I need to know how to start with proxy radius server impementation for
radius-diameter converter. It would be great if you can give me a document link on the same please.
Proxy functionality is documented in raddb/proxy.conf.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
We've had alike issues but had this fixed with the pushed patch towards 2.2.6 from Alan. It's in the repositories but sadly 2.2.7 is not released yet On Tue, Mar 24, 2015 at 9:41 AM, srithar jeevadurai <srijeevadurai1@gmail.com> wrote:
Hi Team,
Can anyone help on below request please?
Regards, Srithar
On Sat, Mar 21, 2015 at 8:50 PM, srithar jeevadurai < srijeevadurai1@gmail.com> wrote:
Hi Team,
I have understanded the proxy implementation. We are going to revamp our application with following design.
I would like to know whether we will face any challenge in our design i.e. freeRadius stack wise.
1) GGSN to send request to Radius proxy (listening on standard ports 1812 and 1813). 2) Radius proxy to accept only auth and allocate IP address and response to auth request. 3) Radius proxy to forward acct request to home_server pool ( may be 2-3 home server on same server with different user id and port for acct request instead of 1813). 4) Home_server to handle only acct request and fwd it to rad-dia converter (diaclient). diaclient to convert rad request to dia request and send to IN. diaclient to send response back to corresponding home server and home server to send response back to Radius proxy.
Same Host: 1 Radius Proxy, 3 Home-Servers (different user id and port no for acct req), 1 diaclient.
Assumption: 1) 2-3 home servers can be configured and run on same host with different user name and port number for acct request. 2) Radius proxy to choose acct-start to be sent among home_servers and forward further accouting request (i.e. updates and stop) to same home_servers. i.e. load balancing can be automatically handled by Radius proxy. 3) Radius proxy server can be modified to allocate IP address and response to auth request (only for auth) and for acct-request it has to forward it to home_server. which configuration directs R-proxy to handle auth request by itself by calling customized module and forward acct to home_server. It will be great help if you can provide us same configuration for proxy to handle auth and forward acct to home_servers.
Thanks in advance for your reply. Please let us know if there is any risk or not right approach in above explaned design.
Regards, Srithar
On Mon, Nov 24, 2014 at 12:28 PM, Iliya Peregoudov <iperegudov@cboss.ru> wrote:
On 22.11.2014 18:01, srithar jeevadurai wrote:
Hi LLiya,
Thanks for your reply.
If I understand your reply correctly. Our current implementation is like radius worker thread calls our customized module of Radius (rlm_raddia) to send request to diameter client (dia client will send the request to IN and reponse will be sent back to radius thread from dia client). It is a blocking call of Radius worker thread.
Yes, your current implementation uses custom freeradius module that implements in-house protocol client. All freeradius modules are blocking and your module is not an exception.
If we implement, radius server as proxy then it will take request from
NAS and send it to dia client (without waiting for response from dia client) which is non blocking call of radius worker thread. Dia client has to send response to radius server and radius server to send the repsonse to NAS. The only change here is rad-worker thread is no need to wait after sending request to dia client. Sending request and processing respose from dia client will happen idependedlly by FreeRad.
Yes, RADIUS proxy functionality of freeradius is non-blocking.
If my above understanding is correct, Can we get a sample module code to
send radius request to external process (here it is dia client) and process response from external process (idependedlly without waiting req-res). I hope that we would have used any IPC like TCP/IP or message queue etc.
RADIUS proxy functionality does not need any freeradius module. RADIUS proxy functionality is already implemented in freeradius core. RADIUS proxy functionality sends RADIUS requests to external RADIUS server (called "home" server). If your preacct section sets control:Proxy-To-Realm attribute for the accounting request received by freeradius from NAS, freeradius core will proxy this accounting request to the home server associated with designated realm. When the answer comes from home server freeradius core will proxy this answer back to the NAS.
Example configuration of freeradius proxy:
# raddb/proxy.conf home_server radius-diameter-translator-1 { type = acct ipaddr = 127.0.0.1 port = 4013 secret = secret response_window = 3 no_response_fail = yes zombie_period = 86400 # 1 day revive_interval = 0 status_check = none } home_server_pool radius-diameter-translator { home_server = radius-diameter-translator-1 } realm radius-diameter-translator { acct_pool = radius_diameter_translator }
# raddb/sites-available/default ... preacct { # Proxy all Accounting-Requests to radius-diameter-translator realm update control { Proxy-To-Realm := radius-diameter-translator } } ...
Your radius-diameter-translator module should listen RADIUS protocol on UDP/4013 port. Translator should implement RADIUS server (receive requests, send responses) and Diameter client (send requests, receive answers). Flow diagram is following:
NAS radiusd r-d-t diameter-server | | | | |RADIUS ACR | | | |------------>|RADIUS ACR | | | |------------>|Diameter ACR | | | |-------------->| | | | Diameter ACA| | | RADIUS ACA|<--------------| | RADIUS ACA|<------------| | |<------------| | |
I need to know how to start with proxy radius server impementation for
radius-diameter converter. It would be great if you can give me a document link on the same please.
Proxy functionality is documented in raddb/proxy.conf.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852
-- Regards, Srithar Durairaj Alternate Mail I.D: srijeevadurai1@yahoo.co.in Mobile: +919886251852 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 24.03.2015 11:41, srithar jeevadurai wrote:
1) GGSN to send request to Radius proxy (listening on standard ports 1812 and 1813). 2) Radius proxy to accept only auth and allocate IP address and response to auth request.
Is far as I understand you want to implement proxy server using FreeRADIUS. If you plan to dynamically allocate addresses (e.g. not static subscriber--address binding), you also have to deallocate addresses on Accounting-Request/Stop. Address allocation/deallocation needs address database modification. Database access on accounting handling path is better to be postpone using raddb/sites-available/decoupled-accounting. Database access on authentication handling path cannot be postponed. High database latency can lead to radiusd request queue to overflow on request spikes. Request queue in radiusd is used for both authentication and accounting requests. When queue overflows radiusd starts dropping incoming requests, both authentication and accounting. If you do not want to lose accounting due to troubles with authentication, you better to run two radiusd processes, first listening on 1812 port and handling authentication and second listening on 1813 port and handling accounting.
3) Radius proxy to forward acct request to home_server pool ( may be 2-3 home server on same server with different user id and port for acct request instead of 1813). 4) Home_server to handle only acct request and fwd it to rad-dia converter (diaclient). diaclient to convert rad request to dia request and send to IN. diaclient to send response back to corresponding home server and home server to send response back to Radius proxy.
It is not clear why do you need home servers. What will they do? Will they proxy accounting requests to rad-dia converter? Proxy server can proxy RADIUS requests directly to rad-dia converter.
participants (8)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Fajar A. Nugraha -
Iliya Peregoudov -
Jonathan -
Nick Lowe -
srithar jeevadurai