Re: (RADIATOR) Using Called ID to make connect 33.6k
Hello Matthew - Yes, but you will need to configure your NAS's to use Pre-Authentication to do it properly. Do your NAS's support Per-Authentication (and subsequently forcing a connect speed)? regards Hugh On Sunday, August 18, 2002, at 03:40 PM, mhobbs wrote: Hi Is it possible to set up Radiator so that when a customer dials up a differnet no. from the standard dial up no. ie standard is 02991 then they dial 029910001 that Radius sets up the call up at 33.6k only ? My current set up is below Realm DEFAULT AuthBy EMERALD .. /AuthBy /Realm SessionDatabase SQL .. /SessionDatabase Thanks for your help Matthew === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Accounting Handled
Hi, On Accounting Handled parameters can I still get an accounting stop? Is the Accounting Handled parameter is only use for retransmission request? Ray === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) SQL Database failover.
Title: Message Hi, Just a quick question. I've got a pretty straightforward configuration here. I have my radius servers pointed to 2 SQL databases. When database A goes down, Radiator switches over to database B. This works fine. My question is, is there anyway to go back to database A when it returns to operational? The current behaviour is to stay put at database B until it goes down too. FailureBackoffTime doesnt work in this way. Any ideas. Thanks. Achint.
(RADIATOR) DefaultLeasePeriod
Hi Hugh, Hi All, What happens when the DefaultLeasePeriod(say 86400 = 1 day) expires? Does the user get disconnected and the IP allocated to him/her reclaimed? Or is the user (correctly) allowed to stay connected? Let's assume that the checkattribute of the clients specifies that he/she can stay on for the whole day (Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1) Regards, Tunde I.
(RADIATOR) Re: DefaultLeasePeriod
Hello Tunde - The IP address in the address pool is marked as available when the DefaultLeasePeriod expires. There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration. regards Hugh On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote: Hi Hugh, Hi All, What happens when the DefaultLeasePeriod (say 86400 = 1 day) expires? Does the user get disconnected and the IP allocated to him/her reclaimed? Or is the user (correctly) allowed to stay connected? Let's assume that the checkattribute of the clients specifies that he/she can stay on for the whole day (Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1) Regards, Tunde I. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
Re: (RADIATOR) SQL Database failover.
Hello Achint - There is no way in Radiator itself to go back to using database A when it comes back. Note that you could just define two seperate AuthBy SQL clauses, but I don't know if this will work for you. Most operators tend to use a single database on some sort of high-availability hardware. regards Hugh On Monday, August 19, 2002, at 05:19 PM, Achint Saxena wrote: Hi, Just a quick question. I've got a pretty straightforward configuration here. I have my radius servers pointed to 2 SQL databases. When database A goes down, Radiator switches over to database B. This works fine. My question is, is there anyway to go back to database A when it returns to operational? The current behaviour is to stay put at database B until it goes down too. FailureBackoffTime doesnt work in this way. Any ideas. Thanks. Achint. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
Re: (RADIATOR) Accounting Handled
Hello Ray - The AccountingHandled parameter just causes an Accounting-Respnse to be sent immediately. You will still receive all accounting requests sent to this Radiator instance. regards Hugh On Monday, August 19, 2002, at 05:13 PM, [EMAIL PROTECTED] wrote: Hi, On Accounting Handled parameters can I still get an accounting stop? Is the Accounting Handled parameter is only use for retransmission request? Ray === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Re: DefaultLeasePeriod
Hi Hugh, One, I assume the checkattribute ( Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1) implies "always-on 24-7-365" access for the user? My aim is to allow clients with DSL access (alwayson-24-7-365)to remain on without radiatiorreclaiming the IP address allocated to themwhile they are still connected. What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-up access so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaim the IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes? Would setting the Defaultleaseperiod to "infinity" ( :-) or say a year, and leaving the LeaseReclaimInterval set to (say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clients when they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clients that are still online. Regards, Tunde Itayemi. - Original Message - From: Hugh Irvine To: Ayotunde Itayemi Cc: [EMAIL PROTECTED] Sent: Monday, August 19, 2002 12:31 PM Subject: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde -The IP address in the address pool is marked as available when the DefaultLeasePeriod expires.There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration.regardsHughOn Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote: Hi Hugh, Hi All,What happens when the DefaultLeasePeriod(say 86400 = 1 day) expires?Does the user get disconnected and the IP allocated to him/her reclaimed?Or is the user (correctly) allowed to stay connected?Let's assume that the checkattribute of the clients specifies that he/shecan stay on for the whole day (Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1)Regards,Tunde I.-- Radiator: the most portable, flexible and configurable RADIUS serveranywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.-Nets: internetwork inventory and management - graphical, extensible,flexible with hardware, software, platform and database independence.
RE: (RADIATOR) Re: DefaultLeasePeriod
Does anyone know how to set up clients, NAS etc to make the client use a DHCP server at the ISP? Is it as simple as doing a normal DHCP configuration in the client, and then set up your DHCP server? Or do you have to configure the NAS as well? Because such a setup would allow the client to renew its own IP address according to the lease time configured in the DHCP server. /Ingvar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Hi Hugh, One, I assume the checkattribute ( Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) implies always-on 24-7-365 access for the user? My aim is to allow clients with DSL access (alwayson-24-7-365) to remain on without radiatior reclaiming the IP address allocated to them while they are still connected. What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-up access so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaim the IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes? Would setting the Defaultleaseperiod to infinity ( :-) or say a year, and leaving the LeaseReclaimInterval set to (say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clients when they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clients that are still online. Regards, Tunde Itayemi. - Original Message - From: Hugh Irvine mailto:[EMAIL PROTECTED] To: Ayotunde Itayemi mailto:[EMAIL PROTECTED] Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Monday, August 19, 2002 12:31 PM Subject: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde - The IP address in the address pool is marked as available when the DefaultLeasePeriod expires. There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration. regards Hugh On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote: Hi Hugh, Hi All, What happens when the DefaultLeasePeriod (say 86400 = 1 day) expires? Does the user get disconnected and the IP allocated to him/her reclaimed? Or is the user (correctly) allowed to stay connected? Let's assume that the checkattribute of the clients specifies that he/she can stay on for the whole day (Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) Regards, Tunde I. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Re: DefaultLeasePeriod
Hello Tunde - By definition a customer with a permanent connection would not use a dynamic address. You should allocate such users static addresses instead. regards Hugh On Monday, August 19, 2002, at 10:10 PM, Ayotunde Itayemi wrote: Hi Hugh, One, I assume the checkattribute ( Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1) implies "always-on 24-7-365" access for the user? My aim is to allow clients with DSL access (alwayson-24-7-365) to remain on without radiatior reclaiming the IP address allocated to them while they are still connected. What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-up access so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaim the IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes? Would setting the Defaultleaseperiod to "infinity" ( :-) or say a year, and leaving the LeaseReclaimInterval set to (say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clients when they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clients that are still online. Regards, Tunde Itayemi. - Original Message - From: Hugh Irvine To: Ayotunde Itayemi Cc: [EMAIL PROTECTED] Sent: Monday, August 19, 2002 12:31 PM Subject: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde - The IP address in the address pool is marked as available when the DefaultLeasePeriod expires. There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration. regards Hugh On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote: Hi Hugh, Hi All, What happens when the DefaultLeasePeriod (say 86400 = 1 day) expires? Does the user get disconnected and the IP allocated to him/her reclaimed? Or is the user (correctly) allowed to stay connected? Let's assume that the checkattribute of the clients specifies that he/she can stay on for the whole day (Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1) Regards, Tunde I. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
Re: (RADIATOR) Re: DefaultLeasePeriod
Hello Ingvar - No I have never seen such a thing. This is because the end client device must start a session (usually PPP) *before* it can send TCP/UDP packets. regards Hugh On Monday, August 19, 2002, at 11:41 PM, Ingvar Berg (EAB) wrote: Does anyone know how to set up clients, NAS etc to make the client use a DHCP server at the ISP? Is it as simple as doing a normal DHCP configuration in the client, and then set up your DHCP server? Or do you have to configure the NAS as well? Because such a setup would allow the client to renew its own IP address according to the lease time configured in the DHCP server. /Ingvar -Original Message- From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Hi Hugh, One, I assume the checkattribute ( Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) implies always-on 24-7-365 access for the user? My aim is to allow clients with DSL access (alwayson-24-7-365) to remain on without radiatior reclaiming the IP address allocated to them while they are still connected. What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-up access so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaim the IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes? Would setting the Defaultleaseperiod to infinity ( :-) or say a year, and leaving the LeaseReclaimInterval set to (say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clients when they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clients that are still online. Regards, Tunde Itayemi. - Original Message - From: Hugh Irvine mailto:[EMAIL PROTECTED] To: Ayotunde Itayemi mailto:[EMAIL PROTECTED] Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Monday, August 19, 2002 12:31 PM Subject: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde - The IP address in the address pool is marked as available when the DefaultLeasePeriod expires. There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration. regards Hugh On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote: Hi Hugh, Hi All, What happens when the DefaultLeasePeriod (say 86400 = 1 day) expires? Does the user get disconnected and the IP allocated to him/her reclaimed? Or is the user (correctly) allowed to stay connected? Let's assume that the checkattribute of the clients specifies that he/she can stay on for the whole day (Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) Regards, Tunde I. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Re: DefaultLeasePeriod
Just thought that it would be A Nice Thing, if the NAS could act as a DHCP relay, and leave it to the client and the DHCP server to do this the standard way. (A Nice Thing usually exists already, and can be found, you just have to know where to search ;-). /Ingvar -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Hello Ingvar - No I have never seen such a thing. This is because the end client device must start a session (usually PPP) *before* it can send TCP/UDP packets. regards Hugh On Monday, August 19, 2002, at 11:41 PM, Ingvar Berg (EAB) wrote: Does anyone know how to set up clients, NAS etc to make the client use a DHCP server at the ISP? Is it as simple as doing a normal DHCP configuration in the client, and then set up your DHCP server? Or do you have to configure the NAS as well? Because such a setup would allow the client to renew its own IP address according to the lease time configured in the DHCP server. /Ingvar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Hi Hugh, One, I assume the checkattribute ( Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) implies always-on 24-7-365 access for the user? My aim is to allow clients with DSL access (alwayson-24-7-365) to remain on without radiatior reclaiming the IP address allocated to them while they are still connected. What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-up access so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaim the IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes? Would setting the Defaultleaseperiod to infinity ( :-) or say a year, and leaving the LeaseReclaimInterval set to (say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clients when they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clients that are still online. Regards, Tunde Itayemi. - Original Message - From: Hugh Irvine mailto:[EMAIL PROTECTED] To: Ayotunde Itayemi mailto:[EMAIL PROTECTED] Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Monday, August 19, 2002 12:31 PM Subject: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde - The IP address in the address pool is marked as available when the DefaultLeasePeriod expires. There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration. regards Hugh On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote: Hi Hugh, Hi All, What happens when the DefaultLeasePeriod (say 86400 = 1 day) expires? Does the user get disconnected and the IP allocated to him/her reclaimed? Or is the user (correctly) allowed to stay connected? Let's assume that the checkattribute of the clients specifies that he/she can stay on for the whole day (Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) Regards, Tunde I. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Re: DefaultLeasePeriod
Hi Hugh, Okay you are right. But what if I would like to ensure that the max time a client can stay on is a day? That is, even the "always-on" clients get disconnected at least once everyday? In such a case, what would my checkattributes and replyattributes be? Regards, Tunde I. - Original Message - From: Hugh Irvine To: Ayotunde Itayemi Cc: [EMAIL PROTECTED] Sent: Monday, August 19, 2002 2:48 PM Subject: Re: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde -By definition a customer with a permanent connection would not use a dynamic address.You should allocate such users static addresses instead.regardsHughOn Monday, August 19, 2002, at 10:10 PM, Ayotunde Itayemi wrote: Hi Hugh,One, I assume the checkattribute ( Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1)implies "always-on 24-7-365" access for the user?My aim is to allow clients with DSL access (alwayson-24-7-365)to remain on without radiatiorreclaiming theIP address allocated to themwhile they are still connected.What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-upaccess so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaimthe IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes?Would setting the Defaultleaseperiod to "infinity" ( :-) or say a year, and leaving the LeaseReclaimInterval set to(say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clientswhen they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clientsthat are still online.Regards,Tunde Itayemi.- Original Message -From: Hugh IrvineTo: Ayotunde ItayemiCc: [EMAIL PROTECTED]Sent: Monday, August 19, 2002 12:31 PMSubject: (RADIATOR) Re: DefaultLeasePeriodHello Tunde -The IP address in the address pool is marked as available when the DefaultLeasePeriod expires.There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration.regardsHughOn Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote:Hi Hugh, Hi All,What happens when the DefaultLeasePeriod(say 86400 = 1 day) expires?Does the user get disconnected and the IP allocated to him/her reclaimed?Or is the user (correctly) allowed to stay connected?Let's assume that the checkattribute of the clients specifies that he/shecan stay on for the whole day (Service-Type = Framed-User,Time ="Al-2400",Simultaneous-Use = 1)Regards,Tunde I.--Radiator: the most portable, flexible and configurable RADIUS serveranywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.-Nets: internetwork inventory and management - graphical, extensible,flexible with hardware, software, platform and database independence.-- Radiator: the most portable, flexible and configurable RADIUS serveranywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.-Nets: internetwork inventory and management - graphical, extensible,flexible with hardware, software, platform and database independence.
(RADIATOR) Attribute Number 79
Hello everyone, I'm testing our upgrade to 3.1 and I'm getting ERR: Attribute number 79 is not defined in your dictionary I get the error with the 'dictionary' file from the 3.1 release. At this point we're just testing with radpwtst so I didn't think it was a vendor specific attribute, but I also get the error with a concatenation of 'dictionary' and 'dictionary.usr' and 'dictionary.ascend2' (since we have both ascend and total control hardware). And I also get the error with the 'dictionary' file that we were using with Radiator 2.18.2. Thanks in advance, William === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Malformed request packet: Attribute 25 with length 1: ignored
Hugh, The class string is set in a PostAuthHook. We're now using Perl 5.6.1, Freetds 0.60 and DBD:Sybase 0.94. I was able to reproduce the problem outside of Radiator directly in Perl so I've concluded it's not a Radiator problem. When we were using Radiator 2.1.8.2, Perl 5.6.0, Freetds 0.52, DBD:Sybase 0.91 we weren't getting this error. As a work-around I modified the PostAuthHook to strip the null characters at the end of the strings. Perhaps you do this already in the Radiator 3.1 code. Thanks in advance, William -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Friday, August 16, 2002 10:02 PM To: William Hernandez Cc: Radiator (Radiator) Subject: Re: (RADIATOR) Malformed request packet: Attribute 25 with length 1: ignored Hello William - I will need to see a more complete trace 5 debug (including hex dumps) of the incoming request, the corresponding access accept and the subsequent accounting requests. I will also need a copy of the configuration file (no secrets) and a copy of the relevant user record. Just looking at what you have included, it looks like the Class attribute is being set incorrectly by your configuration. regards Hugh On Saturday, August 17, 2002, at 04:18 AM, William Hernandez wrote: Hello everyone, I've just installed Radiator 3.1 plus patches on RedHat 7.3. Our users are authenticating, but I'm getting the following on every request: Malformed request packet: Attribute 25 with length 1: ignored The trace 4 output has: Fri Aug 16 14:10:45 2002: DEBUG: User whr has content controls of xstop: A, R ALCO ALTER ANAR CHAT CRIMI CULTS DRUGS GAMB HATE OBSC PORN RRATED I, 1 Code: Access-Accept Identifier: 0 Authentic: 1234567890123456 Attributes: Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Netmask = 255.255.255.255 Framed-Compression = Van-Jacobson-TCP-IP Ascend-Idle-Limit = 900 Service-Type = Framed-User Framed-Protocol = MP Framed-IP-Netmask = 255.255.255.255 Framed-Compression = Van-Jacobson-TCP-IP Ascend-Maximum-Channels = 2 Ascend-Idle-Limit = 1200 Idle-Timeout = 1200 Session-Timeout = 31800 Class = xstop: A, R ALCO ALTER ANAR CHAT CRIMI CULTS DRUGS GAMB HATE OB SC PORN RRATED I, 1 0 000 000 0 000 000 0 00 0 000 000 0 000 000 Our dictionary file (a concatenation of dictionary and dictionary.ascend2) has: ATTRIBUTE Class 25 string What is causing the Malformed request packet? Thanks in advance, William === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Attribute Number 79
Hello everyone, Found the following in the archive which solved the problem. # Some experimental attributes from RFC 2869: ATTRIBUTE Prompt 76 integer ATTRIBUTE Connect-Info77 string ATTRIBUTE Configuration-Token 78 binary ATTRIBUTE EAP-Message 79 binary ATTRIBUTE Signature 80 binary ATTRIBUTE Message-Authenticator 80 binary ATTRIBUTE Acct-Interim-Interval 85 integer ATTRIBUTE Ascend-Owner-IP-Addr86 ipaddr ATTRIBUTE NAS-Port-Id 87 string ATTRIBUTE Framed-Pool 88 string Thanks, William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of William Hernandez Sent: Monday, August 19, 2002 10:42 AM To: Radiator (Radiator) Subject: (RADIATOR) Attribute Number 79 Hello everyone, I'm testing our upgrade to 3.1 and I'm getting ERR: Attribute number 79 is not defined in your dictionary I get the error with the 'dictionary' file from the 3.1 release. At this point we're just testing with radpwtst so I didn't think it was a vendor specific attribute, but I also get the error with a concatenation of 'dictionary' and 'dictionary.usr' and 'dictionary.ascend2' (since we have both ascend and total control hardware). And I also get the error with the 'dictionary' file that we were using with Radiator 2.18.2. Thanks in advance, William === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Re: DefaultLeasePeriod
Hello Ingvar, I think perhaps it will depend heavily on the capabilities of the NAS itself to do such a thing. If you are talking Cisco here, the NAS has all the same capabilities as a standard router. At least I can recall a setup we did once in the past where we allowed DHCP broadcast queries to leak from one LAN across a serial link and on the other side, to the DHCP server. There was a command named 'ip helper address' I think, don't recall very well, though. Perhaps this is a starting point for your quest :) Now, if you are talking about other NAS brands here, I won't be able to help. regards, cl. From: Ingvar Berg (EAB) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: (RADIATOR) Re: DefaultLeasePeriod Date: Mon, 19 Aug 2002 16:18:26 +0200 Just thought that it would be A Nice Thing, if the NAS could act as a DHCP relay, and leave it to the client and the DHCP server to do this the standard way. (A Nice Thing usually exists already, and can be found, you just have to know where to search ;-). /Ingvar -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Hello Ingvar - No I have never seen such a thing. This is because the end client device must start a session (usually PPP) *before* it can send TCP/UDP packets. regards Hugh On Monday, August 19, 2002, at 11:41 PM, Ingvar Berg (EAB) wrote: Does anyone know how to set up clients, NAS etc to make the client use a DHCP server at the ISP? Is it as simple as doing a normal DHCP configuration in the client, and then set up your DHCP server? Or do you have to configure the NAS as well? Because such a setup would allow the client to renew its own IP address according to the lease time configured in the DHCP server. /Ingvar -Original Message- From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Hi Hugh, One, I assume the checkattribute ( Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) implies always-on 24-7-365 access for the user? My aim is to allow clients with DSL access (alwayson-24-7-365) to remain on without radiatior reclaiming the IP address allocated to them while they are still connected. What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-up access so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaim the IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes? Would setting the Defaultleaseperiod to infinity ( :-) or say a year, and leaving the LeaseReclaimInterval set to (say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clients when they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clients that are still online. Regards, Tunde Itayemi. - Original Message - From: Hugh Irvine mailto:[EMAIL PROTECTED] To: Ayotunde Itayemi mailto:[EMAIL PROTECTED] Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Monday, August 19, 2002 12:31 PM Subject: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde - The IP address in the address pool is marked as available when the DefaultLeasePeriod expires. There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration. regards Hugh On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote: Hi Hugh, Hi All, What happens when the DefaultLeasePeriod (say 86400 = 1 day) expires? Does the user get disconnected and the IP allocated to him/her reclaimed? Or is the user (correctly) allowed to stay connected? Let's assume that the checkattribute of the clients specifies that he/she can stay on for the whole day (Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) Regards, Tunde I. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. _
Re: (RADIATOR) Malformed request packet: Attribute 25 with length 1: ignored
Hello William - Is there anything else I can help you with? regards Hugh On Tuesday, August 20, 2002, at 12:59 AM, William Hernandez wrote: Hugh, The class string is set in a PostAuthHook. We're now using Perl 5.6.1, Freetds 0.60 and DBD:Sybase 0.94. I was able to reproduce the problem outside of Radiator directly in Perl so I've concluded it's not a Radiator problem. When we were using Radiator 2.1.8.2, Perl 5.6.0, Freetds 0.52, DBD:Sybase 0.91 we weren't getting this error. As a work-around I modified the PostAuthHook to strip the null characters at the end of the strings. Perhaps you do this already in the Radiator 3.1 code. Thanks in advance, William -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Friday, August 16, 2002 10:02 PM To: William Hernandez Cc: Radiator (Radiator) Subject: Re: (RADIATOR) Malformed request packet: Attribute 25 with length 1: ignored Hello William - I will need to see a more complete trace 5 debug (including hex dumps) of the incoming request, the corresponding access accept and the subsequent accounting requests. I will also need a copy of the configuration file (no secrets) and a copy of the relevant user record. Just looking at what you have included, it looks like the Class attribute is being set incorrectly by your configuration. regards Hugh On Saturday, August 17, 2002, at 04:18 AM, William Hernandez wrote: Hello everyone, I've just installed Radiator 3.1 plus patches on RedHat 7.3. Our users are authenticating, but I'm getting the following on every request: Malformed request packet: Attribute 25 with length 1: ignored The trace 4 output has: Fri Aug 16 14:10:45 2002: DEBUG: User whr has content controls of xstop: A, R ALCO ALTER ANAR CHAT CRIMI CULTS DRUGS GAMB HATE OBSC PORN RRATED I, 1 Code: Access-Accept Identifier: 0 Authentic: 1234567890123456 Attributes: Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Netmask = 255.255.255.255 Framed-Compression = Van-Jacobson-TCP-IP Ascend-Idle-Limit = 900 Service-Type = Framed-User Framed-Protocol = MP Framed-IP-Netmask = 255.255.255.255 Framed-Compression = Van-Jacobson-TCP-IP Ascend-Maximum-Channels = 2 Ascend-Idle-Limit = 1200 Idle-Timeout = 1200 Session-Timeout = 31800 Class = xstop: A, R ALCO ALTER ANAR CHAT CRIMI CULTS DRUGS GAMB HATE OB SC PORN RRATED I, 1 0 000 000 0 000 000 0 00 0 000 000 0 000 000 Our dictionary file (a concatenation of dictionary and dictionary.ascend2) has: ATTRIBUTE Class 25 string What is causing the Malformed request packet? Thanks in advance, William === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Attribute Number 79
Hello William - These attributes are included in the latest Radiator 3.1 dictionary. regards Hugh On Tuesday, August 20, 2002, at 01:31 AM, William Hernandez wrote: Hello everyone, Found the following in the archive which solved the problem. # Some experimental attributes from RFC 2869: ATTRIBUTE Prompt 76 integer ATTRIBUTE Connect-Info77 string ATTRIBUTE Configuration-Token 78 binary ATTRIBUTE EAP-Message 79 binary ATTRIBUTE Signature 80 binary ATTRIBUTE Message-Authenticator 80 binary ATTRIBUTE Acct-Interim-Interval 85 integer ATTRIBUTE Ascend-Owner-IP-Addr86 ipaddr ATTRIBUTE NAS-Port-Id 87 string ATTRIBUTE Framed-Pool 88 string Thanks, William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of William Hernandez Sent: Monday, August 19, 2002 10:42 AM To: Radiator (Radiator) Subject: (RADIATOR) Attribute Number 79 Hello everyone, I'm testing our upgrade to 3.1 and I'm getting ERR: Attribute number 79 is not defined in your dictionary I get the error with the 'dictionary' file from the 3.1 release. At this point we're just testing with radpwtst so I didn't think it was a vendor specific attribute, but I also get the error with a concatenation of 'dictionary' and 'dictionary.usr' and 'dictionary.ascend2' (since we have both ascend and total control hardware). And I also get the error with the 'dictionary' file that we were using with Radiator 2.18.2. Thanks in advance, William === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Re: DefaultLeasePeriod
Hello Claudio, Hello Ingvar - As mentioned in my previous mail, DHCP as a protocol uses UDP, which assumes that you already have a properly configured and operating IP stack in place. This is obviously not the case in most cases when Radiator is handling an access request for PPP for example, because the result of the radius authentication will result in the link being set up. As Ingvar already knows, we have implemented the AuthBy DYNADDRESS/AddressAllocator DHCP combination to allow a DHCP server to be used for address allocation in response to a radius request. If as Claudio describes, you are wanting to do DHCP over an already established link, then you can use DHCP request forwarding using Cisco's selective forwarding configuration. regards Hugh On Tuesday, August 20, 2002, at 02:08 AM, Claudio Lapidus wrote: Hello Ingvar, I think perhaps it will depend heavily on the capabilities of the NAS itself to do such a thing. If you are talking Cisco here, the NAS has all the same capabilities as a standard router. At least I can recall a setup we did once in the past where we allowed DHCP broadcast queries to leak from one LAN across a serial link and on the other side, to the DHCP server. There was a command named 'ip helper address' I think, don't recall very well, though. Perhaps this is a starting point for your quest :) Now, if you are talking about other NAS brands here, I won't be able to help. regards, cl. From: Ingvar Berg (EAB) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: (RADIATOR) Re: DefaultLeasePeriod Date: Mon, 19 Aug 2002 16:18:26 +0200 Just thought that it would be A Nice Thing, if the NAS could act as a DHCP relay, and leave it to the client and the DHCP server to do this the standard way. (A Nice Thing usually exists already, and can be found, you just have to know where to search ;-). /Ingvar -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Hello Ingvar - No I have never seen such a thing. This is because the end client device must start a session (usually PPP) *before* it can send TCP/UDP packets. regards Hugh On Monday, August 19, 2002, at 11:41 PM, Ingvar Berg (EAB) wrote: Does anyone know how to set up clients, NAS etc to make the client use a DHCP server at the ISP? Is it as simple as doing a normal DHCP configuration in the client, and then set up your DHCP server? Or do you have to configure the NAS as well? Because such a setup would allow the client to renew its own IP address according to the lease time configured in the DHCP server. /Ingvar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Hi Hugh, One, I assume the checkattribute ( Service-Type = Framed-User,Time =Al-2400,Simultaneous-Use = 1) implies always-on 24-7-365 access for the user? My aim is to allow clients with DSL access (alwayson-24-7-365) to remain on without radiatior reclaiming the IP address allocated to them while they are still connected. What combination of attributes do you think can handle clients with DSL access (alwayson-24-7-365) and dial-up access so that the IP address is not reclaimed for the DSL clients while they are still connected - and still reclaim the IP addresses allocated to the dial-up/DSL clients when they disconnect by themselves from the NASes? Would setting the Defaultleaseperiod to infinity ( :-) or say a year, and leaving the LeaseReclaimInterval set to (say) a day handle the kind of configuration I mentioned above? That is, correctly reclaim the IPaddresses for clients when they are disconnected (by NAS, attributes, etc) and also not reclaim the IP addresses allocated to clients that are still online. Regards, Tunde Itayemi. - Original Message - From: Hugh Irvine mailto:[EMAIL PROTECTED] To: Ayotunde Itayemi mailto:[EMAIL PROTECTED] Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Monday, August 19, 2002 12:31 PM Subject: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde - The IP address in the address pool is marked as available when the DefaultLeasePeriod expires. There is no relationship between the Session-Timeout on the NAS and the DefaultLeasePeriod for the IP address allocation. You will have to manage any relationship that you wish to have with your configuration. regards Hugh On Monday, August 19, 2002, at 06:09 PM, Ayotunde Itayemi wrote: Hi Hugh, Hi All, What happens when the DefaultLeasePeriod (say 86400 = 1 day) expires? Does the user get disconnected and the IP allocated to him/her reclaimed? Or is the user (correctly) allowed to stay connected? Let's assume that the checkattribute of the clients specifies that he/she can stay on for the whole day (Service-Type
(RADIATOR) Simultaneous-use in 3.1
Hello everyone, I'm testing 3.1 using radpwtst. And I've noticed the message INFO: Access rejected for whr: Simultaneous-Use of 2 exceeded in the radius.log. The message is correct. The problem is that RADONLINE shows there are 3 logins. radpwtst -trace -s localhost -user whr -password x -auth_port 1812 -acct_port 1813 -secret x -dictionary /etc/raddb/dictionary.prw -nostop -nas_port=1234 radpwtst -trace -s localhost -user whr -password x -auth_port 1812 -acct_port 1813 -secret x -dictionary /etc/raddb/dictionary.prw -nostop -nas_port=1235 radpwtst -trace -s localhost -user whr -password x -auth_port 1812 -acct_port 1813 -secret x -dictionary /etc/raddb/dictionary.prw -nostop -nas_port=1236 Output of radwho.cgi whr 203.63.154.1 1234 1234 Mon Aug 19 15:37:18 2002 0 00:00:47 terminate session delete session whr 203.63.154.1 1236 1234 Mon Aug 19 15:37:38 2002 0 00:00:27 terminate session delete session whr 203.63.154.1 1235 1234 Mon Aug 19 15:37:30 2002 0 00:00:35 terminate session delete session Attached are the radius.cfg and the trace 4 log. Thanks in advance, William radius.log Description: Binary data radius.cfg Description: Binary data
(RADIATOR) Malformed Packet requests
Hello, Thanks for all your previous replies. Just another issue I need some help with. Im getting a Malformed request packet warning in my radiator logs. Any ideas why would this happen? I don't have an Attribute 0 defined in my dictionary. A sample packet trace is attached. Cheers. Achint. --- Mon Aug 19 15:50:54 2002: WARNING: Malformed request packet: Vendor 5586 Attribute 0 with length 1: ignored Mon Aug 19 15:50:54 2002: DEBUG: Packet dump: *** Received from 192.168.193.2 port 1812 Code: Accounting-Request Identifier: 241 Authentic: 151W182231/Ze176135130i204qD133o Attributes: Acct-Status-Type = Start Acct-Delay-Time = 0 Acct-Authentic = RADIUS Event-Timestamp = 1029736339 Acct-Interim-Interval = 60 NAS-IP-Address = 192.168.193.2 User-Name = new_user Acct-Session-Id =2949346 L2TP-Tunnel-If-Index = 73 L2TP-Tunnel-Local-Sid = 77 ISP-LNS-Name = r1.nwton Tier-Of-Service = Business Unknown = -- === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) NumHosts in SQLRadius
Hey Guys, Is there anyway to set NumHosts dynamically? Say perhaps via the first SQLRADIUS lookup, it returns the NumHosts variable? I'd prefer to not have to hard set this, as I'm trying to design the system around a dynamic number of destination RADIUS servers.. also.. What type of detail can I expect with trying to run StatsLogSQL with SQLRADIUS, as I would like to be able to scalably count the request/responses along with the number of downstream ISPs I am supporting. From what I read in the documentation, statistics are kept for each Identifier, the SQLRADIUS itself as an Identifier, but each downstream within the database, I would expect does not have it's own unique Identifier.. Thanks, Martin === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) socket queue length
Hi, Is there any OS parameter or radiator parameter which can be fine tune to increase the accounting packet received other than OS udp_max_buf and radius socket queue length? Ray === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) socket queue length
Hi, Is there any OS parameter or radiator parameter which can be fine tune to increase the accounting packet received other than OS udp_max_buf and radius socket queue length? Since the current cpu utilization of our server is 98% idle and the physical memory utilized is 386K of the current 512K. Ray === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Version 3.2 released
We are pleased to announce the release of Radiator version 3.2 This version provides some significant new features and some bug fixes. Among the most important new features is the support for EAP-TTLS 802.1x wireless authentication. Caution: users of MSCHAP authentication should note the need to install Digest::SHA1 prior to installing this new version for continued correct operation. As usual, the new version is available free of charge to current licensees from http://www.open.com.au/radiator/downloads/Radiator-3.2.tgz and http://www.open.com.au/radiator/downloads/Radiator-3.2-1.noarch.rpm and to current evaluators from http://www.open.com.au/radiator/demo-downloads/Radiator-Demo-3.2.tgz and http://www.open.com.au/radiator/demo-downloads/Radiator-Demo-3.2-1.noarch.rpm An extract from the history file is attached Revision 3.2 (20/8/02 New features and fixes) Caution: Updated AuthGeneric.pm and MSCHAP.pm to use more modern Digest::SHA1 instead of SHA. if you are using SHA passwords or MSCHAP authentication, you must install Digest::SHA1. Added new AuthBy URL module, contributed by Mauro Crovato ([EMAIL PROTECTED]). This module authenticates by sending the username and password (optionally encrypted) as tags to a URL by HTTP. A CGI or ASP program at the URL authenticates the password. Fixed some interoperability problems with EAP-TLS. Testing with Aironet AP and Client cards with OpenSSL and Xsupplicant on Linux and Windows XP. Beta support for EAP-TTLS as used by Funk Odyssey clients. Supports TTLS-PAP, TTLS-CHAP, TTLS-MSCHAP and TTLS-MSCHAPV2 for both local and proxy authentication. See example configuration files goodies/eap_ttls.cfg and goodies/eap_ttls_proxy.cfg. TTLS is Tunnelled TLS, as per draft-ietf-pppext-eap-ttls-01.txt., It is supported by Funk Odyssey wireless clients through a variety of wireless access points. It provides one-way TLS authentication (the client authenticates the radius server), and authentication requests are delivered securely to the radius server via the encrypted TLS tunnel. Unlike TLS, TTLS does not _require_ a certificate on each client. Tested EAP MD5-Challenge with Aironet AP and Client cards and Windows XP. Added example goodies/eap_md5.cfg config file. Added more Spring Tide VSAs to the dictionary.Contributed by [EMAIL PROTECTED] AuthBy SQL now runs AuthSQLStatement even if AuthSelect is empty. A debug print statement was accidentally left in AuthLog SQL AuthBy SQL AcctColumnDef now cannot insert the same column multiple times. If there are multiple AcctColumnDef definitions for the same column name and with non-null values, the last one will be the one inserted. This is most likely to improve the case where there are two NASIdentifier definitions, and the NAS reports both NAS-IP-Address and NAS-Identifier. A number of example config files were changed so that NASIdentifier is preferred if present. AuthBy SQL now supports HandleAcctStatusTypes parameter, which allows you to specify a comma separated list of AcctStatusTypes that will be processed. All other types will by acknowledged, but not inserted or processed with AcctSQLStatement. This is a more general mechanism than AccountingStartsOnly, AccountingStopsOnly and AccountingAlivesOnly, and these parameters are now officially deprecated and will not be supported in the future. An typo in Radius.pm prevented Ascend-Xmit-Rate working properly. Reported by Romain Vergniol ([EMAIL PROTECTED]). In the event of no reply from any hosts, AuthBy SQLRADIUS now runs the NoReplyHook before any FailurePolicy automatic reply. Previously it was run after the automatic reply. Added Roaring Penguin VSA's to dictionary. Contributed by Scott Helms . Thanks Scott. Added to Monitor support for Clients parameter, a comma or space separated list of IP addresses that Monitor will accept connections from. Default is to accept from any address. Added a number of new Altiga VSAs to dictionary, contributed by neil d. quiogue ([EMAIL PROTECTED]) Added /usr/local/etc/radiator to the dictionary search path for radpwtst. Suggested by Martin Edge ([EMAIL PROTECTED]) Added UseTLS parameter for forcing TLS encryption in AuthBy LDAP2. Contributed by Carl Litt ([EMAIL PROTECTED]). Thanks Carl. Added a new flags to AuthBy NT on Windows. IgnoreAccountExpiry causes AuthBy NT to ignore the NT account expiry flag when users attempt to log in. IgnorePasswordExpiry causes it to ignore the password expired flag. IgnorePasswordChange causes it to ignore the password change required flag. radpwtst -gui was not correctly showing packet dumps in the 'Detailed' trace level. Fixed a problem where an incorrect data length in an incoming radius packet could result in reports of a 'Malformed request packet:'. Reported by Thilo Wunderlich ([EMAIL PROTECTED]) New parameter AuthCheckDN in AuthLDAP2 alows you to specify an alternative DN to use to check a user's password, instead of the one returned by the search result. Patch
Re: (RADIATOR) Re: DefaultLeasePeriod
I think in the case of DSL clients though this is not quite correct. We have several 000's of DSL clients but only about 25% of them are online at any one time. Sure they CAN be permanent, but they usually are not. It is a waste of IP space to allocate a static IP to all of them. In some business cases it is even desirous not to allocate them a static IP - but rather make itan 'additional' purchase ;-) We have sometimes run into a problem where if the NAS fails, or the customers DSL router messes up and tries to login hundreds of times a minute we soon run out of available IP addresses in RADPOOL - upon inspection of RADPOOL it shows that the same user has dozens or more ip addresses allocated to them with a state of (1). It would be good if there was some method of clearing these up - currently, we run a script which sets the state of all but the most receint allocation to (0) for any user with more than one entry in RADPOOL. (We don't allow simultaneous logins on our DSL service) Has anyone else has similar problems and/or found a solution? Regards, Brian. - Original Message - From: Hugh Irvine To: Ayotunde Itayemi Cc: [EMAIL PROTECTED] Sent: Monday, August 19, 2002 11:48 PM Subject: Re: (RADIATOR) Re: DefaultLeasePeriod Hello Tunde -By definition a customer with a permanent connection would not use a dynamic address.You should allocate such users static addresses instead.regardsHugh
(RADIATOR) radiator dies w/sql
We have been running radiator for a long time now and have not had any problems, but have one issue I have the conf file such that if our AuthBy SQL ignores the request then it goes to AuthBy File. This way if the sql server dies users can still authenticate on the flat file We have never had problems with the sql server (MySql) but I was trying to test the authby file by stopping the sql server. Radiator looses its connection then dies w/o logging anything Here is conf: Trace 4 #Lower case RewriteUsername tr/A-Z/a-z/ #Remove Spaces RewriteUsername s/\s+//g ClientListSQL DBSource DBI:Sybase:database=DB;server=SRV DBUsername CUT DBAuth CUT GetClientQuery select NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOMMUNITY,LIVINGSTONOFFS,LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS,FRAMEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME,NOIGNOREDUPLICATES,PREHANDLERHOOK,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,FLAGS from NASClients #UseOldAscendPasswords /ClientListSQL SessionDatabase SQL DBSource dbi:mysql:radius:207.40.xxx.xx DBUsername CUT DBAuth CUT /SessionDatabase Log SQL DBSource dbi:mysql:radius:207.40.xxx.xx DBUsername CUT DBAuth CUT Table RADLOG /Log AuthLog SQL Identifier AuthLogMySql DBSource dbi:mysql:radius:207.40.xxx.xx DBUsername CUT DBAuth CUT Table AuthLog FailureQuery INSERT into AuthLog (SeverityLevel, Username, SubmitedPassword, Reason, Date) VALUES (%0, '%U','%P',%1, '%Y-%m-%d %H:%M:%S') LogFailure 1 /AuthLog Handler Request-Type=Access-Request RewriteUsername s/^([^@]+).*/$1/ AuthBy SQL Timeout 10 NoDefaultIfFound DefaultSimultaneousUse 1 CaseInsensitivePasswords RejectEmptyPassword Identifier GOCsql DefaultReply Ascend-Shared-Profile-Enable=0,Service-Type=Framed-User,Framed-Protocol=PPP,Framed-Routing=None,Ascend-Base-Channel-Count=1,Ascend-Minimum-Channels=1,Ascend-Maximum-Channels=1,Ascend-Assign-IP-Pool=1,Ascend-Multicast-Client=Multicast-Yes DBSource DBI:Sybase:database=bill2;server=GO19 DBUsername CUT DBAuth CUT AuthSelect AuthSelect '%n' AuthColumnDef 0, User-Password, check AuthColumnDef 1, Framed-IP-Address, reply AuthColumnDef 2, Framed-Netmask, reply AuthColumnDef 3, GENERIC, reply AuthColumnDef 4, GENERIC, check AddToReplyIfNotExist Framed-Routing=None,Service-Type=Framed-User,Framed-Protocol=PPP /AuthBy SQL AuthBy FILE NoDefaultIfFound DefaultSimultaneousUse 2 /AuthBy FILE AuthLog AuthLogMySql /Handler And The Error Log: Wed Aug 14 13:39:25 2002: ERR: do failed for 'delete from RADONLINE where NASIDENTIFIER='207.40.122.227' and NASPORT=020312': Lost connection to MySQL server during query #THIS IS WHERE I RESTARTED IT b/c IT DIED Wed Aug 14 13:40:44 2002: DEBUG: Adding Clients from SQL database Wed Aug 14 13:40:44 2002: DEBUG: Query is: select NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOM Wed Aug 14 13:40:44 2002: DEBUG: Reading users file /etc/radiator/users Wed Aug 14 13:40:44 2002: INFO: Server started: Radiator 3.0 on rad1.go-concepts.com Thanks for the help Thanks, Tony B, CCNA, Network+ Systems Administration GO Concepts, Inc. / www.go-concepts.com Are you on the GO yet? What about those you know, are they on the GO? 513.934.2800 1.888.ON.GO.YET
(RADIATOR) radiator dies w/sql
We have been running radiator for a long time now and have not had any problems, but have one issue I have the conf file such that if our AuthBy SQL ignores the request then it goes to AuthBy File. This way if the sql server dies users can still authenticate on the flat file We have never had problems with the sql server (MySql) but I was trying to test the authby file by stopping the sql server. Radiator looses it's connection then dies w/o logging anything Here is conf: #Foreground #LogStdout LogDir /var/log/radius DbDir /etc/radiator DictionaryFile %D/dictionary # it to 4 or 5 for debugging, or use the -trace flag to radiusd Trace 4 #AuthPort 2900 #AcctPort 2901 #Lower case RewriteUsername tr/A-Z/a-z/ #Remove Spaces RewriteUsername s/\s+//g #DateFormat '%Y-%M-%d %T' ClientListSQL DBSource DBI:Sybase:database=bill2;server=GO19 DBUsername CUT DBAuth CUT GetClientQuery select NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYPE,SNMPCOMMUNITY,LIVINGSTONOFFS,LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS,FRAMEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME,NOIGNOREDUPLICATES,PREHANDLERHOOK,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,FLAGS from NASClients #UseOldAscendPasswords /ClientListSQL SessionDatabase SQL DBSource dbi:mysql:radius:207.40.xxx.xx DBUsername CUT DBAuth CUT /SessionDatabase Log SQL DBSource dbi:mysql:radius:207.40.xxx.xx DBUsername CUT DBAuth CUT Table RADLOG /Log AuthLog SQL Identifier AuthLogMySql DBSource dbi:mysql:radius:207.40.xxx.xx DBUsername CUT DBAuth CUT Table AuthLog FailureQuery INSERT into AuthLog (SeverityLevel, Username, SubmitedPassword, Reason, Date) VALUES (%0, '%U','%P',%1, '%Y-%m-%d %H:%M:%S') LogFailure 1 /AuthLog Handler Request-Type=Access-Request RewriteUsername s/^([^@]+).*/$1/ #PasswordLogFileName %L/password.log AuthBy SQL Timeout 10 NoDefaultIfFound DefaultSimultaneousUse 1 CaseInsensitivePasswords RejectEmptyPassword Identifier GOCsql DefaultReply Ascend-Shared-Profile-Enable=0,Service-Type=Framed-User,Framed-Protocol=PPP,Framed-Routing=None,Ascend-Base-Channel-Count=1,Ascend-Minimum-Channels=1,Ascend-Maximum-Channels=1,Ascend-Assign-IP-Pool=1,Ascend-Multicast-Client=Multicast-Yes DBSource DBI:Sybase:database=bill2;server=GO19 DBUsername CUT DBAuth CUT AuthSelect AuthSelect '%n' AuthColumnDef 0, User-Password, check AuthColumnDef 1, Framed-IP-Address, reply AuthColumnDef 2, Framed-Netmask, reply #AuthColumnDef 3, Ascend-Maximum-Channels, reply AuthColumnDef 3, GENERIC, reply AuthColumnDef 4, GENERIC, check #AddToReplyIfNotExist User-Service=Framed-User,Framed-Protocol=PPP,Framed-Routing=None,Ascend-Base-Channel-Count=1,Ascend-Minimum-Channels=1,Ascend-Maximum-Channels=1,Ascend-Assign-IP-Pool=1,Ascend-Multicast-Client=Multicast-Yes AddToReplyIfNotExist Framed-Routing=None,Service-Type=Framed-User,Framed-Protocol=PPP /AuthBy SQL AuthBy FILE NoDefaultIfFound DefaultSimultaneousUse 2 /AuthBy FILE AuthLog AuthLogMySql /Handler Handler Request-Type=Accounting-Request AuthBy SQL DateFormat %Y-%m-%d %T Identifier MySQL DBSource dbi:mysql:radius:207.40.xxx.xx DBUsername CUT DBAuth CUT AuthSelect AccountingTable Accounting%{Acct-Status-Type} #AccountingTable Accounting AcctColumnDef Username,%U,formatted AcctColumnDef TIME_STAMP,Timestamp,integer AcctColumnDef AcctStatusType,Acct-Status-Type AcctColumnDef SessionID,Acct-Session-Id AcctColumnDef SessionTime,Acct-Session-Time,integer AcctColumnDef DisconnectCause,Ascend-Disconnect-Cause,integer AcctColumnDef ConnectProgress,Ascend-Connect-Progress,integer AcctColumnDef NASIdentifier,NAS-Identifier AcctColumnDef NASPort,NAS-Port,integer AcctColumnDef ModemPort,Ascend-Modem-PortNo,integer AcctColumnDef ModemSlot,Ascend-Modem-SlotNo,integer AcctColumnDef IPAddress,Framed-IP-Address AcctColumnDef XmitRate,Ascend-Xmit-Rate
(RADIATOR) proxy based on a prefix
Dear sirs, We have radius proxy server running Radiator-2.18.4 on Solaris. I would like to know whether this server supports proxy based on a prefix. (eg. TEST/username@domain ) Thanks in advance Anura === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Accounting Handled
Hi, Where can we put the accounting handled parameter is it on the authby clause? Can i have a sample config on how to implement it. Ray === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.