Hi, I am using the free radius 2.1.3. I have a module rlm_xxx and have initialized it as thread safe. I have configured the start_servers as 3. The issue I am having is as follows. I see that a new instance is getting created when the first one is busy handling a request. (I do this this by adding a sleep in the module and printing the threadid) I am expecting the xxx_instantiate function to get called each time a new instance is created (reading in the documentation). This does not happen. I am actually connecting to a server in the instantiate function and storing the socket id in the *instance, so that I can use it later in the authenticate etc. But it seems that the socket id is the same for all the instances. *instance seems to be shared by all the instances ?? Am I missing something/configuration, your help is grately appreciated. Thanks in advance for your inputs. Thanks, Latha.
On 19 February 2010, at 15:24, Latha Krishnamurthi wrote:
I am using the free radius 2.1.3. I have a module rlm_xxx and have initialized it as thread safe. I have configured the start_servers as 3. The issue I am having is as follows.
I see that a new instance is getting created when the first one is busy handling a request. (I do this this by adding a sleep in the module and printing the threadid) I am expecting the xxx_instantiate function to get called each time a new instance is created (reading in the documentation). This does not happen. I am actually connecting to a server in the instantiate function and storing the socket id in the *instance, so that I can use it later in the authenticate etc.
But it seems that the socket id is the same for all the instances. *instance seems to be shared by all the instances ??
Am I missing something/configuration, your help is grately appreciated.
I believe this is an issue of terminology. Instantiation in this case refers to the configuration process prior to the start of the server accepting Radius requests. It does not refer to instantiation of new threads. I am not aware of any hook you can use for instatiation of new threads. In one of the older version rlm_example files is the following comment: * If the module needs to temporarily modify it's instantiation * data, the type should be changed to RLM_TYPE_THREAD_UNSAFE. * The server will then take care of ensuring that the module * is single-threaded.
Thankyou very much for your prompt reply. I was referring to this documentation. http://wiki.freeradius.org/Modules2
The xxx_instantiate module is called each time a new instance is started. Generally this >>module is used to establish the data for the instance that needs to be retained during the >>life of the instance. For example, reading the configuration variables. cf_section_parse>>(conf, data, module_config) is used to do this function. Setup struct rlm_xxx_t to hold data that needs to be accessed by all instances of the >>rlm. This data is not necessarily the same for each instance. There is a separate copy >>for each instance. For example, this is the place to store configuration variables that will >>be provided in FreeRADIUS.conf. It is described like I can have the module specific data in the instance and use it in the life time of the instance. So if I need to use a unique socket connection for each thread, I have no place to store the instance specific data ? I need to have a global pool and lock it with mutex ?? (looks like rlm_ldap does something similar ?) Thanks in advance LK --- On Fri, 2/19/10, Doug Hardie <bc979@lafn.org> wrote:
From: Doug Hardie <bc979@lafn.org> Subject: Re: modules instantiation To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Date: Friday, February 19, 2010, 3:49 PM On 19 February 2010, at 15:24, Latha Krishnamurthi wrote:
I am using the free radius 2.1.3. I have a module rlm_xxx and have initialized it as thread safe. I have configured the start_servers as 3. The issue I am having is as follows. I see that a new instance is getting created when the first one is busy handling a request. (I do this this by adding a sleep in the module and printing the threadid) I am expecting the xxx_instantiate function to get called each time a new instance is created (reading in the documentation). This does not happen. I am actually connecting to a server in the instantiate function and storing the socket id in the *instance, so that I can use it later in the authenticate etc. But it seems that the socket id is the same for all the instances. *instance seems to be shared by all the instances ?? Am I missing something/configuration, your help is grately appreciated.
I believe this is an issue of terminology. Instantiation in this case refers to the configuration process prior to the start of the server accepting Radius requests. It does not refer to instantiation of new threads. I am not aware of any hook you can use for instatiation of new threads. In one of the older version rlm_example files is the following comment: * If the module needs to temporarily modify it's instantiation * data, the type should be changed to RLM_TYPE_THREAD_UNSAFE. * The server will then take care of ensuring that the module * is single-threaded. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 19 February 2010, at 17:35, Latha Krishnamurthi wrote:
Thankyou very much for your prompt reply. I was referring to this documentation.
http://wiki.freeradius.org/Modules2
The xxx_instantiate module is called each time a new instance is started. Generally this >>module is used to establish the data for the instance that needs to be retained during the >>life of the instance. For example, reading the configuration variables. cf_section_parse>>(conf, data, module_config) is used to do this function.
Setup struct rlm_xxx_t to hold data that needs to be accessed by all instances of the >>rlm. This data is not necessarily the same for each instance. There is a separate copy >>for each instance. For example, this is the place to store configuration variables that will >>be provided in FreeRADIUS.conf.
Well, it sure seemed clear when I wrote it, but now I tend to agree that its a bit misleading. Those words were lifted from the original version 1 document and perhaps something changed with version 2, but I don't recall any such changes. In any case, it does need a revision.
It is described like I can have the module specific data in the instance and use it in the life time of the instance.
So if I need to use a unique socket connection for each thread, I have no place to store the instance specific data ? I need to have a global pool and lock it with mutex ?? (looks like rlm_ldap does something similar ?)
Alan responded with something I was not aware of. I suspect thats the way you need to go.
Thanks in advance LK
--- On Fri, 2/19/10, Doug Hardie <bc979@lafn.org> wrote:
From: Doug Hardie <bc979@lafn.org> Subject: Re: modules instantiation To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Date: Friday, February 19, 2010, 3:49 PM
On 19 February 2010, at 15:24, Latha Krishnamurthi wrote:
I am using the free radius 2.1.3. I have a module rlm_xxx and have initialized it as thread safe. I have configured the start_servers as 3. The issue I am having is as follows.
I see that a new instance is getting created when the first one is busy handling a request. (I do this this by adding a sleep in the module and printing the threadid) I am expecting the xxx_instantiate function to get called each time a new instance is created (reading in the documentation). This does not happen. I am actually connecting to a server in the instantiate function and storing the socket id in the *instance, so that I can use it later in the authenticate etc.
But it seems that the socket id is the same for all the instances. *instance seems to be shared by all the instances ??
Am I missing something/configuration, your help is grately appreciated.
I believe this is an issue of terminology. Instantiation in this case refers to the configuration process prior to the start of the server accepting Radius requests. It does not refer to instantiation of new threads. I am not aware of any hook you can use for instatiation of new threads. In one of the older version rlm_example files is the following comment:
* If the module needs to temporarily modify it's instantiation * data, the type should be changed to RLM_TYPE_THREAD_UNSAFE. * The server will then take care of ensuring that the module * is single-threaded.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Latha Krishnamurthi wrote:
I see that a new instance is getting created when the first one is busy handling a request. (I do this this by adding a sleep in the module and printing the threadid) I am expecting the xxx_instantiate function to get called each time a new instance is created (reading in the documentation).
No. The module is NOT having "a new instance created". A module "instance" is defined by a module configuration. One configuration: one instance. The "instance" data is *constant*. The module gets called multiple times simultaneously from multiple threads when multiple requests are received.
This does not happen. I am actually connecting to a server in the instantiate function and storing the socket id in the *instance, so that I can use it later in the authenticate etc.
Why? Is that connection changing the way the module behaves?
But it seems that the socket id is the same for all the instances. *instance seems to be shared by all the instances ??
Am I missing something/configuration, your help is grately appreciated.
If you need to store data that is associated with a particulare *request*, and is valid only for the lifetime of a request, see request_data_add(), and request_data_get(). Alan DeKok.
Hi! I have a question regarding to the default_eap_type setting for ttls configuration in file eap.conf. From TTLS protocol, it is not necessary to do authentication in the tunnel and it is the user who decides and initiates which eap type to use inside tunnel. What the default_eap_type is used for? Thanks! Gina Zhang
Hi, Is it possible to do authorization through the identity in inner tunnel? Thanks, Gina Zhang
Alan, Thanks for the quick response! I did look there before I sent the first email. I think that I should add something In authorize section like update request. But I don't know the details. Could you advise? Thanks, Gina -----Original Message----- From: freeradius-users-bounces+gina.zhang=alcatel-lucent.com@lists.freeradius. org [mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent.com@lists.fre eradius.org] On Behalf Of Alan Buxey Sent: Monday, February 22, 2010 4:53 PM To: FreeRadius users mailing list Subject: Re: Authorization through inner identity Hi,
Hi,
Is it possible to do authorization through the identity in inner tunnel?
check out the authorize {} section in the inner-tunnel virtual server in FreeRADIUS 2.x - thats what its there for alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
I did look there before I sent the first email. I think that I should add something In authorize section like update request.
well, that all dependds on what you want to achieve. the current listed modules in tat section all behave as per normal and deal with the basic yes/no of authorization and access policy. alan
Alan, All I want to do is to use inner username to lookup the database table to authorize. Thanks, Gina -----Original Message----- From: freeradius-users-bounces+gina.zhang=alcatel-lucent.com@lists.freeradius. org [mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent.com@lists.fre eradius.org] On Behalf Of Alan Buxey Sent: Monday, February 22, 2010 5:12 PM To: FreeRadius users mailing list Subject: Re: Authorization through inner identity Hi,
I did look there before I sent the first email. I think that I should add something In authorize section like update request.
well, that all dependds on what you want to achieve. the current listed modules in tat section all behave as per normal and deal with the basic yes/no of authorization and access policy. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Alan,
All I want to do is to use inner username to lookup the database table to authorize.
so long as you call the relevant SQL module in the authorize {} section of innter-tunnel then the default config will work fine for you. - once the server is in inner-tunnel (called via EAP) it will only be dealing with the inner username (unless you've done something crazy/weird with the config!) alan
Alan, Thanks for all the help! I need to modify my question. I am using mschapv2 inside ttls tunnel. Upon receipt of the MS-CHAP2-Success AVP, the client is able to authenticate the FR. If the authentication succeeds, the client sends and EAP-TTLS packet to FR containing no data. Only upon receiving this packet, FR authorize. But at this point, the request packet contains no inner tunnel identity. Is there anyway to config FR to authorize according to the inner-tunnel indentity in this case? Regards, Gina -----Original Message----- From: freeradius-users-bounces+gina.zhang=alcatel-lucent.com@lists.freeradius. org [mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent.com@lists.fre eradius.org] On Behalf Of Alan Buxey Sent: Tuesday, February 23, 2010 3:41 AM To: FreeRadius users mailing list Subject: Re: Authorization through inner identity Hi,
Alan,
All I want to do is to use inner username to lookup the database table
to authorize.
so long as you call the relevant SQL module in the authorize {} section of innter-tunnel then the default config will work fine for you. - once the server is in inner-tunnel (called via EAP) it will only be dealing with the inner username (unless you've done something crazy/weird with the config!) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ZHANG Gina wrote:
I have a question regarding to the default_eap_type setting for ttls configuration in file eap.conf. From TTLS protocol, it is not necessary to do authentication in the tunnel
Huh? It is absolutely necessary to do authentication in the tunnel.
and it is the user who decides and initiates which eap type to use inside tunnel.
No. The server ALWAYS initiates an EAP rtype.
What the default_eap_type is used for?
The comments in eap.conf explain this. Alan DeKok.
Thankyou will try that. --- On Fri, 2/19/10, Alan DeKok <aland@deployingradius.com> wrote: From: Alan DeKok <aland@deployingradius.com> Subject: Re: modules instantiation To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Date: Friday, February 19, 2010, 6:07 PM Latha Krishnamurthi wrote:
I see that a new instance is getting created when the first one is busy handling a request. (I do this this by adding a sleep in the module and printing the threadid) I am expecting the xxx_instantiate function to get called each time a new instance is created (reading in the documentation).
No. The module is NOT having "a new instance created". A module "instance" is defined by a module configuration. One configuration: one instance. The "instance" data is *constant*. The module gets called multiple times simultaneously from multiple threads when multiple requests are received.
This does not happen. I am actually connecting to a server in the instantiate function and storing the socket id in the *instance, so that I can use it later in the authenticate etc.
Why? Is that connection changing the way the module behaves?
But it seems that the socket id is the same for all the instances. *instance seems to be shared by all the instances ?? Am I missing something/configuration, your help is grately appreciated.
If you need to store data that is associated with a particulare *request*, and is valid only for the lifetime of a request, see request_data_add(), and request_data_get(). Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I tried to correct the wiki's description but was not able to do so. I can log in fine and it says I can edit the file. However, after making the changes save just gives a blank screen and the changes never appear in the text. In the modules2 file change: The xxx_instantiate module is called each time a new instance is started. Generally this module is used to establish the data for the instance that needs to be retained during the life of the instance. For example, reading the configuration variables. cf_section_parse(conf, data, module_config) is used to do this function. to: The xxx_instantiate module is called each time a new instance is started during the initial configuration process. Generally this module is used to establish the data for the instance that needs to be retained during the life of the instance. For example, reading the configuration variables. cf_section_parse(conf, data, module_config) is used to do this function. Note that the instantiate module is not called each time a new instantiation of the module is started during run time. The data established during the instantiate module is available to all instantiations during run time. If you need to store data that is associated with a particulare *request*, and is valid only for the lifetime of a request, see request_data_add(), and request_data_get().
This is very clear.Thanks. --- On Mon, 2/22/10, Doug Hardie <bc979@lafn.org> wrote: From: Doug Hardie <bc979@lafn.org> Subject: Re: modules instantiation To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Date: Monday, February 22, 2010, 10:56 PM I tried to correct the wiki's description but was not able to do so. I can log in fine and it says I can edit the file. However, after making the changes save just gives a blank screen and the changes never appear in the text. In the modules2 file change: The xxx_instantiate module is called each time a new instance is started. Generally this module is used to establish the data for the instance that needs to be retained during the life of the instance. For example, reading the configuration variables. cf_section_parse(conf, data, module_config) is used to do this function. to: The xxx_instantiate module is called each time a new instance is started during the initial configuration process. Generally this module is used to establish the data for the instance that needs to be retained during the life of the instance. For example, reading the configuration variables. cf_section_parse(conf, data, module_config) is used to do this function. Note that the instantiate module is not called each time a new instantiation of the module is started during run time. The data established during the instantiate module is available to all instantiations during run time. If you need to store data that is associated with a particulare *request*, and is valid only for the lifetime of a request, see request_data_add(), and request_data_get(). - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
Alan Buxey -
Alan DeKok -
Doug Hardie -
Latha Krishnamurthi -
ZHANG Gina