Re: Multiple instances of attribute in tunnelled reply
Thanks very much, I wish that the version 2.1.9 will be released soon. Sunhualing On Wed, Apr 14, 2010 at 3:02 PM, Alan DeKok wrote: > sunhualing wrote: > > Hi Alan DeKok: > >Are you sure it is the PEAP module,not the TTLS module? why? > >And when will the 2.1.9 be released? thank you very much! > > They both have the same code, and they both should be fixed. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
sunhualing wrote: > Hi Alan DeKok: >Are you sure it is the PEAP module,not the TTLS module? why? >And when will the 2.1.9 be released? thank you very much! They both have the same code, and they both should be fixed. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Hi Alan DeKok: Are you sure it is the PEAP module,not the TTLS module? why? And when will the 2.1.9 be released? thank you very much! sunhualing On Wed, Apr 14, 2010 at 10:59 AM, Alan DeKok wrote: > sunhualing wrote: > > Hello everyone: > > I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to > > get a problem that some attribute missing in the > > Access-Accept message, while it appears in the first Access-Challenge > > message. I still find that those attributes appear > > tunneled reply , i use the debug mode. > >Search the mail list , i find that similiar problem appears two years > > ago, here is the mail. > >Any suggestion is welcome, thanks a log > > Hmm... the fix is likely to edit the source code of the PEAP module. > I'll take a look at it for 2.1.9. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
sunhualing wrote: > Hello everyone: > I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to > get a problem that some attribute missing in the > Access-Accept message, while it appears in the first Access-Challenge > message. I still find that those attributes appear > tunneled reply , i use the debug mode. >Search the mail list , i find that similiar problem appears two years > ago, here is the mail. >Any suggestion is welcome, thanks a log Hmm... the fix is likely to edit the source code of the PEAP module. I'll take a look at it for 2.1.9. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of attribute in tunnelled reply
Hello everyone: I am using a freeradius-2.1.8, with eap-ttls mschap v2. I happen to get a problem that some attribute missing in the Access-Accept message, while it appears in the first Access-Challenge message. I still find that those attributes appear tunneled reply , i use the debug mode. Search the mail list , i find that similiar problem appears two years ago, here is the mail. Any suggestion is welcome, thanks a log sunhualing Hi, We formulate our reply inside of the virtual server dealing with EAP and send it back to the outer server. This is the only way I could think of to insert the Inner identity into the Access-Accept. It all works fine... however it seems there's a bug when dealing with multiple instances of the same attribute. For example: users / sql DEFAULT Service-Type == Framed-User, Realm == 'local', SS-Flags =~ "^.1$" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = 603, Reply-Message = "User %{%{Stripped-User-Name}:-%{User-Name}} authenticated for ResNet access on NAS:%{%{NAS-Identifier}:-Uknown NAS} SSID:%{%{Called-Station-SSID}:-none}.", HP-IP-FILTER-RAW = 'deny in 41 from any to any', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.1', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.2', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.3', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.4', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.5', Fall-Through = no Ends up being sent as the response: # server default-inner PEAP: Got tunneled reply RADIUS code 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x User-Name = "ac221" PEAP: Processing from tunneled session code 0x845cb10 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x User-Name = "ac221" PEAP: Tunneled authentication was successful. rlm_eap_peap: SUCCESS Saving tunneled attributes for later So when it's actually used in the Access-Accept packet it appears as: Sending Access-Accept of id 173 to 139.184.8.16 port 1024 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" HP-Ip-Filter-Raw = "deny in 41 from any to any" User-Name = "ac...@sussex.ac.uk" MS-MPPE-Recv-Key = 0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03 MS-MPPE-Send-Key = 0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696 EAP-Message = 0x034a0004 Message-Authenticator = 0x Finished request 9. What's really weird is in the previous rounds of EAP, the attributes retain the += operator, it's only in the one where the EAP-Success message is returned where all the operators are stripped out. Relevant EAP bits: eap { ... ttls { ... copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "default-inner" } } Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Lost entries from reply with multiple instances of the same attribute
Konstantin KABASSANOV wrote: Konstantin KABASSANOV wrote: Some months ago I mentioned a problem observed while sending Access- Accept with multiple Cisco-AVPair="ssid=..." entries. Even if fields are correctly retrieved from the LDAP server, only the first occurrence of the attribute is sent in the packet. Can you tell me if recent developments have solved this issue? This issue has been solved for almost 4 years now. Read ldap.attrmap. Alan, I'd be very happy if it was true, but: Even if my radius server gets the following from the rlm_ldap: rlm_ldap: looking for reply items in directory... rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = "ssid=mywifi1" rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = "ssid=mywifi2" Read the comments in "ldap.attrmap". Specifically you're going to want: replyItem Cisco-AVPair wireless += i.e. you need to use the "operator" field - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Lost entries from reply with multiple instances of the same attribute
> Konstantin KABASSANOV wrote: > > Some months ago I mentioned a problem observed while sending Access- > Accept > > with multiple Cisco-AVPair="ssid=..." entries. Even if fields are > correctly > > retrieved from the LDAP server, only the first occurrence of the > attribute > > is sent in the packet. Can you tell me if recent developments have > solved > > this issue? > > This issue has been solved for almost 4 years now. Read > ldap.attrmap. > Alan, I'd be very happy if it was true, but: Even if my radius server gets the following from the rlm_ldap: rlm_ldap: looking for reply items in directory... rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = "ssid=mywifi1" rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = "ssid=mywifi2" the outgoing access-accept packet contains only the first entry: rlm_ldap: LDAP attribute wireless as RADIUS attribute Cisco-AVPair = "ssid=mywifi1" FYI the version I use for radius is 2.0.4 so I don't think it is more than 4 years old. In an email sent in April 2008, I saw somebody with a similar problem with another attribute and there was an information that the bug was corrected only in unlang. Am I wrong? Konstantin smime.p7s Description: S/MIME cryptographic signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Lost entries from reply with multiple instances of the same attribute
Konstantin KABASSANOV wrote: > Some months ago I mentioned a problem observed while sending Access-Accept > with multiple Cisco-AVPair="ssid=..." entries. Even if fields are correctly > retrieved from the LDAP server, only the first occurrence of the attribute > is sent in the packet. Can you tell me if recent developments have solved > this issue? This issue has been solved for almost 4 years now. Read ldap.attrmap. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Lost entries from reply with multiple instances of the same attribute
Hi, Some months ago I mentioned a problem observed while sending Access-Accept with multiple Cisco-AVPair="ssid=..." entries. Even if fields are correctly retrieved from the LDAP server, only the first occurrence of the attribute is sent in the packet. Can you tell me if recent developments have solved this issue? Thanks. Konstantin _ Konstantin KABASSANOV LIP6/CNRS 104, avenue du Président Kennedy, 75016 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: [EMAIL PROTECTED] Web: http://www.kabassanov.com Certificate: http://igc.services.cnrs.fr/CNRS-Standard/recherche.html _ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of attribute in tunnelled reply
Hi, I think that I have a similar problem when freeradius has to send Access-Accept with multiple Cisco-AVPair="ssid=..." entries. Do you think it will be fixed in the near future ? Thanks. Konstantin _ Konstantin KABASSANOV LIP6/CNRS 104, avenue du Président Kennedy, 75016 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: [EMAIL PROTECTED] Web: http://www.kabassanov.com Certificate: http://igc.services.cnrs.fr/CNRS-Standard/recherche.html _ smime.p7s Description: S/MIME cryptographic signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Alan DeKok wrote: Arran Cudbard-Bell wrote: Hi, We formulate our reply inside of the virtual server dealing with EAP and send it back to the outer server. This is the only way I could think of to insert the Inner identity into the Access-Accept. ... update outer.reply { User-Name := "foo" } ... Hmm, it's complicated... there are authorisation issues too. It all works fine... however it seems there's a bug when dealing with multiple instances of the same attribute. Ah the code in "unlang" was fixed to correct this problem. The basic API used in the basic RADIUS library wasn't fixed. Ok... I'll take a look at it when I get back from my current trip. Ok that helps, didn't realise it was fixed in unlang; least I can get some dynamic ACL testing done. What's really weird is in the previous rounds of EAP, the attributes retain the += operator, it's only in the one where the EAP-Success message is returned where all the operators are stripped out. Yes. "copy everything", versus "merge via operators". Yep. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thanks, Arran -- Arran Cudbard-Bell ([EMAIL PROTECTED]) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Arran Cudbard-Bell wrote: > Hi, > > We formulate our reply inside of the virtual server dealing with EAP and > send it back to the outer server. This is the only way I could think of > to insert the Inner identity into the Access-Accept. ... update outer.reply { User-Name := "foo" } ... > It all works > fine... however it seems there's a bug when dealing with multiple > instances of the same attribute. Ah the code in "unlang" was fixed to correct this problem. The basic API used in the basic RADIUS library wasn't fixed. Ok... I'll take a look at it when I get back from my current trip. > What's really weird is in the previous rounds of EAP, the attributes > retain the += operator, it's only in the one where the EAP-Success > message is returned where all the operators are stripped out. Yes. "copy everything", versus "merge via operators". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of attribute in tunnelled reply
Erg, Still no closer to fixing this / finding a work around. Is anyone else using a similar configuration and finding this issue? Arran Arran Cudbard-Bell wrote: Hi, We formulate our reply inside of the virtual server dealing with EAP and send it back to the outer server. This is the only way I could think of to insert the Inner identity into the Access-Accept. It all works fine... however it seems there's a bug when dealing with multiple instances of the same attribute. For example: users / sql DEFAULT Service-Type == Framed-User, Realm == 'local', SS-Flags =~ "^.1$" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = 603, Reply-Message = "User %{%{Stripped-User-Name}:-%{User-Name}} authenticated for ResNet access on NAS:%{%{NAS-Identifier}:-Uknown NAS} SSID:%{%{Called-Station-SSID}:-none}.", HP-IP-FILTER-RAW = 'deny in 41 from any to any', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.1', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.2', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.3', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.4', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.5', Fall-Through = no Ends up being sent as the response: # server default-inner PEAP: Got tunneled reply RADIUS code 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x User-Name = "ac221" PEAP: Processing from tunneled session code 0x845cb10 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x User-Name = "ac221" PEAP: Tunneled authentication was successful. rlm_eap_peap: SUCCESS Saving tunneled attributes for later So when it's actually used in the Access-Accept packet it appears as: Sending Access-Accept of id 173 to 139.184.8.16 port 1024 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" HP-Ip-Filter-Raw = "deny in 41 from any to any" User-Name = "[EMAIL PROTECTED]" MS-MPPE-Recv-Key = 0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03 MS-MPPE-Send-Key = 0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696 EAP-Message = 0x034a0004 Message-Authenticator = 0x Finished request 9. What's really weird is in the previous rounds of EAP, the attributes retain the += operator, it's only in the one where the EAP-Success message is returned where all the operators are stripped out. Relevant EAP bits: eap { ... ttls { ... copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "default-inner" } } Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of attribute in tunnelled reply
Hi, We formulate our reply inside of the virtual server dealing with EAP and send it back to the outer server. This is the only way I could think of to insert the Inner identity into the Access-Accept. It all works fine... however it seems there's a bug when dealing with multiple instances of the same attribute. For example: users / sql DEFAULT Service-Type == Framed-User, Realm == 'local', SS-Flags =~ "^.1$" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = 603, Reply-Message = "User %{%{Stripped-User-Name}:-%{User-Name}} authenticated for ResNet access on NAS:%{%{NAS-Identifier}:-Uknown NAS} SSID:%{%{Called-Station-SSID}:-none}.", HP-IP-FILTER-RAW = 'deny in 41 from any to any', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.1', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.2', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.3', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.4', HP-IP-FILTER-RAW += 'permit in ip from any to 10.0.8.5', Fall-Through = no Ends up being sent as the response: # server default-inner PEAP: Got tunneled reply RADIUS code 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x User-Name = "ac221" PEAP: Processing from tunneled session code 0x845cb10 2 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" Reply-Message = "User ac221 authenticated for ResNet access on NAS:hp-e-engg1-1-dev-8021x-sw1 SSID:none." HP-Ip-Filter-Raw = "deny in 41 from any to any" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.1" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.2" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.3" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.4" HP-Ip-Filter-Raw = "permit in ip from any to 10.0.8.5" EAP-Message = 0x03490004 Message-Authenticator = 0x User-Name = "ac221" PEAP: Tunneled authentication was successful. rlm_eap_peap: SUCCESS Saving tunneled attributes for later So when it's actually used in the Access-Accept packet it appears as: Sending Access-Accept of id 173 to 139.184.8.16 port 1024 Service-Type = Framed-User Framed-MTU = 1480 Framed-Routing = None Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "603" HP-Ip-Filter-Raw = "deny in 41 from any to any" User-Name = "[EMAIL PROTECTED]" MS-MPPE-Recv-Key = 0xdec383f4a269cb3d8fcf59cd9e351971c3a9a3683a7c245144a0b852634c7a03 MS-MPPE-Send-Key = 0xb9f49bba9f9020deaa745c6ea0e8f5b92e72e2fc5b6465aed4a9231f10edd696 EAP-Message = 0x034a0004 Message-Authenticator = 0x Finished request 9. What's really weird is in the previous rounds of EAP, the attributes retain the += operator, it's only in the one where the EAP-Success message is returned where all the operators are stripped out. Relevant EAP bits: eap { ... ttls { ... copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "default-inner" } } Thanks, Arran -- Arran Cudbard-Bell ([EMAIL PROTECTED]) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_sql multiple instances handling of
Hi, I have a problem where I need a lot of threads to catch accounting data, a lot of threads means a lot of DB handles. Alas this means more than 256 db handles which is the limit for rlm_sql. My thoughts therefore was to instantiate multiple rlm_sql modules to increase the number of db handles availible.However I am wondering on how to now use this. This system is purely for accounting. If I say put in the accounting stanza:sql1sql2sqlnWill the accounting packet be sent to all sql instanses in turn, or just the 1st one that succeeds ? and then not any further ? Will a "no free db handles" error from sql1 lead to sql2 being attempted ?Thanks in advance - Graeme Hinchliffe (BSc) Core Systems Designer Zen Internet (http://www.zen.co.uk/) Direct: 0845 058 9074 Main : 0845 058 9000 Fax : 0845 058 9005 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Multiple instances of the exec module
K. Many thanks for clarifying... Les -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] rg] On Behalf Of K. Hoercher Sent: 13 October 2006 14:44 PM To: FreeRadius users mailing list Subject: Re: Multiple instances of the exec module On 10/13/06, Les Brinkworth <[EMAIL PROTECTED]> wrote: > How does one define two instances of exec with different names that > can be called from other sections? Aaah, now it gets a bit more clear to me. You should take into account the comments at the beginning of the modules{} section. That would lead to something like: > Code snippet from Modules section of radiusd.conf... > exec doacctfoo { > wait = yes > program = "handlebillingrequests.exe ACCR:%Z" > input_pairs = request > output_pairs = reply > packet_type = Accounting-Request > } > > ...This executes for an accounting request > > If I then add the same code to the authorize section... ah no, that won't work. you just put it into the modules{} too with analogous change: > exec dorequestfoo { > wait = yes > program = "handlebillingrequests.exe AUTR:%Z" > input_pairs = request > output_pairs = reply > packet_type = Access-Request > } > > ...it results in the following when I run debug > radiusd.conf[1527] Unknown module rcode 'wait'. > radiusd.conf[1513] Failed to parse authorize section. Ok, that confuses freeradius way to much, as that is not the place to define module instances (see above), especially when another one (the unnamed one) already is present. But you can now put the named defined ones in the appropriate section e.g. authorize { ... dorequestfoo ... } accounting { ... doacctfoo ... } There might be other ways of doing it, (using the same module, but changing the called program, so it can cope with both tasks accordingly) but keeping it simple at first and following the recommendations in the comments looks preferable, at least until you get some working config. regards K. Hoercher - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of the exec module
On 10/13/06, Les Brinkworth <[EMAIL PROTECTED]> wrote: How does one define two instances of exec with different names that can be called from other sections? Aaah, now it gets a bit more clear to me. You should take into account the comments at the beginning of the modules{} section. That would lead to something like: Code snippet from Modules section of radiusd.conf... exec doacctfoo { wait = yes program = "handlebillingrequests.exe ACCR:%Z" input_pairs = request output_pairs = reply packet_type = Accounting-Request } ...This executes for an accounting request If I then add the same code to the authorize section... ah no, that won't work. you just put it into the modules{} too with analogous change: exec dorequestfoo { wait = yes program = "handlebillingrequests.exe AUTR:%Z" input_pairs = request output_pairs = reply packet_type = Access-Request } ...it results in the following when I run debug radiusd.conf[1527] Unknown module rcode 'wait'. radiusd.conf[1513] Failed to parse authorize section. Ok, that confuses freeradius way to much, as that is not the place to define module instances (see above), especially when another one (the unnamed one) already is present. But you can now put the named defined ones in the appropriate section e.g. authorize { ... dorequestfoo ... } accounting { ... doacctfoo ... } There might be other ways of doing it, (using the same module, but changing the called program, so it can cope with both tasks accordingly) but keeping it simple at first and following the recommendations in the comments looks preferable, at least until you get some working config. regards K. Hoercher - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Multiple instances of the exec module
assword = "demo" tls: dh_file = "../etc/raddb/certs/FreeRADIUS.net/DemoCerts/dh" tls: random_file = "../etc/raddb/certs/FreeRADIUS.net/DemoCerts/random" tls: fragment_size = 1024 tls: include_length = yes tls: check_crl = no tls: check_cert_cn = "%{User-Name}" rlm_eap_tls: Loading the certificate file as a chain rlm_eap: Loaded and initialized type tls ttls: default_eap_type = "md5" ttls: copy_request_to_tunnel = no ttls: use_tunneled_reply = yes rlm_eap: Loaded and initialized type ttls peap: default_eap_type = "mschapv2" peap: copy_request_to_tunnel = no peap: use_tunneled_reply = no peap: proxy_tunneled_request_as_eap = yes rlm_eap: Loaded and initialized type peap mschapv2: with_ntdomain_hack = no rlm_eap: Loaded and initialized type mschapv2 Module: Instantiated eap (eap) Module: Loaded preprocess preprocess: huntgroups = "../etc/raddb/huntgroups" preprocess: hints = "../etc/raddb/hints" preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = no preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = yes Module: Instantiated preprocess (preprocess) radiusd.conf[1527] Unknown module rcode 'wait'. radiusd.conf[1513] Failed to parse authorize section. C:\Program Files\FreeRADIUS.net-1.1.1-r0.0.1\bin> Thanks Les -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] rg] On Behalf Of K. Hoercher Sent: 13 October 2006 11:21 AM To: FreeRadius users mailing list Subject: Re: Multiple instances of the exec module On 10/13/06, Les Brinkworth <[EMAIL PROTECTED]> wrote: > I am lost as to where or maybe how this definition is done. If I > duplicate the exec module in the actual section, RadiusD complains > about 'wait' not being defined. Just a guess (as you didn't provide any output): The error (more of a warning) is something like "...Wait=yes but no output defined..."? So check for the subsequent comment in the definition of an exec instance called "echo". Which should also serve as an example how to define different instances, which would then be called in the "actual section" by their name. regards K. Hoercher - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of the exec module
On 10/13/06, Les Brinkworth <[EMAIL PROTECTED]> wrote: I am lost as to where or maybe how this definition is done. If I duplicate the exec module in the actual section, RadiusD complains about 'wait' not being defined. Just a guess (as you didn't provide any output): The error (more of a warning) is something like "...Wait=yes but no output defined..."? So check for the subsequent comment in the definition of an exec instance called "echo". Which should also serve as an example how to define different instances, which would then be called in the "actual section" by their name. regards K. Hoercher - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of the exec module
Hi All, I am new to FreeRadius and in fact Radius. Having spent some time playing with FreeRadius (Windows ver) I need to call an external program in the preacct, authorize & authenticate sections. While the code comment in the piece prior to the exec module states the following: # If you wish to execute an external program in more than # one section (e.g. 'authorize', 'pre_proxy', etc), then it # is probably best to define a different instance of the # 'exec' module for every section. I am lost as to where or maybe how this definition is done. If I duplicate the exec module in the actual section, RadiusD complains about 'wait' not being defined. Can anyone provide guidance? Many thanks Les Brinkworth - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances
Yep you were right Alan, it was a stupid misconfiguration. Cheers both of you. Mike On 10/14/05, Alan DeKok <[EMAIL PROTECTED]> wrote: > Mike Chamberlain <[EMAIL PROTECTED]> wrote: > > which specify ports 1812 and 1813 respectively, so I thought I'd be > > able to issue the following commands: > > > > radiusd -d /usr/local/etc/raddb > > radiusd -d /usr/local/etc/raddb2 > > > > This doesn't seem to work however, as the second command seems to have > > no effect, ie. I see the first radiusd process running but never the > > second. Can anyone help please? > > Have you tried running the server in debugging mode to see the > message it produces? It WILL tell you what's going wrong, and why. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances
Mike Chamberlain <[EMAIL PROTECTED]> wrote: > which specify ports 1812 and 1813 respectively, so I thought I'd be > able to issue the following commands: > > radiusd -d /usr/local/etc/raddb > radiusd -d /usr/local/etc/raddb2 > > This doesn't seem to work however, as the second command seems to have > no effect, ie. I see the first radiusd process running but never the > second. Can anyone help please? Have you tried running the server in debugging mode to see the message it produces? It WILL tell you what's going wrong, and why. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances
Hello there. This is probably a stupid question, but how do I run multiple instances of radiusd on the same machine, listening on different ports? I have two configuration directories: /usr/local/etc/raddb /usr/local/etc/raddb2 which specify ports 1812 and 1813 respectively, so I thought I'd be able to issue the following commands: 1812 is for authentication and 1813 for accounting. So, if you used the port configuration in radiusd.conf and set raddb to 1812, it will automatically use 1813 for accounting. radiusd -d /usr/local/etc/raddb radiusd -d /usr/local/etc/raddb2 That is the correct way to do that part. This doesn't seem to work however, as the second command seems to have no effect, ie. I see the first radiusd process running but never the second. Can anyone help please? Probably because you are trying to set port = 1813 on raddb2, which would make it listen to 1813 and 1814 - but 1813 is already taken on raddb. Easiest way to do it is to set raddb with port = 1812 and raddb2 with port = 1645 (1645 and 1646 are the old traditional radius ports. Those are pretty safe to use since a lot of people still run radius on those ports - you'll probably still see it commented out in /etc/services) -Dusty Doris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances
Hello there. This is probably a stupid question, but how do I run multiple instances of radiusd on the same machine, listening on different ports? I have two configuration directories: /usr/local/etc/raddb /usr/local/etc/raddb2 which specify ports 1812 and 1813 respectively, so I thought I'd be able to issue the following commands: radiusd -d /usr/local/etc/raddb radiusd -d /usr/local/etc/raddb2 This doesn't seem to work however, as the second command seems to have no effect, ie. I see the first radiusd process running but never the second. Can anyone help please? Thanks, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple instances of ldap module
Teo Romera <[EMAIL PROTECTED]> wrote: > In other words, how do you discriminate which ldap instance to use in > basis of the client that uses the radius server? Key off of the Client-IP-Address attribute. It contains the IP address of the client. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple instances of ldap module
Hello: I have been asked to mantain a recently installed freeradius server, but I am not the person who installed it and I am quite new to radius, and don't want to mess it up. This radius server makes use of the "ldap" module to make queries to an ldap server that we already have. Now, we have a new client, which needs a different configuration for the ldap module. It needs a different query than the rest of the clients. I've read the Autz-Type document which is in the distribution, and it seems that there is a way to "select between multiple instances of a module (ldap) which have been configured differently" (literally copied from that doc). Next in that document, there is an very simple example of what the radius.conf and users files should look like, here it is: radiusd.conf- authenticate{ Auth-Type customer1{ ldap1 } Auth-Type customer2{ ldap2 } } authorize{ preprocess suffix Autz-Type customer1{ ldap1 } Autz-Type customer2{ ldap2 } files } - users file--- DEFAULT Realm == "customer1", Autz-Type := customer1, Auth-Type := customer1 DEFAULT Realm == "customer2", Autz-Type := customer2, Auth-Type := customer2 If i have not missed anything, this examples decides whether the user should use the first or the second ldap instance looking at the user's realm. But, is there a way to choose the first instance for all but one of the radius clients and the second instance for the remaining client? In other words, how do you discriminate which ldap instance to use in basis of the client that uses the radius server? Thank you. -- Teo Romera <[EMAIL PROTECTED]> -- Teo Romera <[EMAIL PROTECTED]> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html