Re: acct_postgresql+auth_ldap
10/09/2009 04:05 PM, José Johnny RANDRIAMAMPIONONA:: Thank u guys! Please keep us in touch. and if you kept some history of what you've done, I am interested in. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 29 155 34 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: perl_rlm and differences FR 1 and 2
David Jones wrote:
> Thanks to some handy hints in here, I've had some success with rlm_perl. But
> (and there is always a but)
>
> I've been happily developing against 2.x but have just discovered I need to
> actually use 1.x because of RHEL.
You can install version 2.x on RHEL.
> The rlm_perl link of both version 1 and version 2 points to the same
> documentation page, so I made the assumption that although theres much
> different under the covers of FR, by the time you get to perl its all hidden,
> and I could just take a perl script that works on V2 and run it on V1.
>
> But it doesn't. There seems to be different handling of the module return
> values, and of $RAD_CHECK{'Response-Packet-Type'} = "Access-Challenge". FR
> V1 seems quite unkeen to send out responses.
>
> So, and finally the question; Are there supposed to be differences in
> behaviour for rlm_perl between V1 and V2?
Lots.
There are a huge number of changes between v1 and v2. We suggest
using v2 for almost everything.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Using another passwd file
Hello Freeradius users I have a challange about using passwd file in freeradius. I'm running Debian 4.0 Kernel 2.6.18-5-486 I have installed FreeRADIUS Version 1.1.3, for host i486-pc-linux-gnu I have activated the following in radiusd.conf file passwd = /etc/passwd shadow = /etc/shadow This works great :) But since all my users are registered on a HP-UX server, that are running in untrusted inviroment, meaning that username and password are stored in /etc/passwd file I'm copying the passwd from the HP-UX server to my Debian 4.0 server. So now I'm chancing the radiusd.conf file to the following passwd = /etc/freeradius/passwd #shadow = /etc/shadow Now I'm NOT able to authenticate on my radius server. The passwd file from HP-UX looks like this pse:VE74Bof8KAnxo:131:20::/home/pse:/sbin/sh I even tried to work with the passwd module but without mutch luck. Can anyone help me here or give me a tip about how to make it work. Best regards Jan Madsen - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: returning an arbitrary attribute from LDAP
Sam Hooker wrote: > I'm trying to ascertain how to have radiusd return an arbitrary attribute > with each successful authentication. My radiusds are doing PEAP/MS-CHAPv2 > against Kerberos for authn, and it seems like activating rlm_ldap for authz > will cause "Auth-Type = LDAP" to enter my world, which I'm betting will break > things. Also, I'm fuzzy as to where I'd do this sort of thing anyway; it > seems that post-auth would be the place to start, but am uncertain. Any > guidance you could offer (including pointers to existing mailing list threads > or other docs) would be much appreciated. See raddb/ldap.attrmap Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: over 30 radiusd processes
Craig Campbell wrote: > Up to 65 processes now > > Any ideas how to stop this from happening? Which version are you running? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
802.1x EAP
Hi Ivan I managed to install the certificates on XP machine and works filn. I had configured my AP IP addresss in radius Server and shared secret key.yesterday i can get an Ip address when i click on the SSID today i get limited network connectivity. I hse VLAN 3 on the SSID. It was working well yesterday morning. Please could you let me know if i need to configure anything on my AP. Thanks My radius and AP are on the same subnet 203.121.4.x -- Devinder - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
perl_rlm and differences FR 1 and 2
Thanks to some handy hints in here, I've had some success with rlm_perl. But
(and there is always a but)
I've been happily developing against 2.x but have just discovered I need to
actually use 1.x because of RHEL. The rlm_perl link of both version 1 and
version 2 points to the same documentation page, so I made the assumption that
although theres much different under the covers of FR, by the time you get to
perl its all hidden, and I could just take a perl script that works on V2 and
run it on V1.
But it doesn't. There seems to be different handling of the module return
values, and of $RAD_CHECK{'Response-Packet-Type'} = "Access-Challenge". FR V1
seems quite unkeen to send out responses.
So, and finally the question; Are there supposed to be differences in behaviour
for rlm_perl between V1 and V2?
Thanks, Davey.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
NAS ? What is the best option
I know that this list is not connected with any hardware vendor but I see that every couple days someone cries here NAS problems... I use Mikrotik and I'm not satisfied (duplicated packets, does not support POD correctly , etc) Also, yesterday I see that Cisco can be pain in the a*** too :) So, dear friends... What is the best solution for ISP (PPPoE)? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session resumption problem
Alan DeKok wrote: > David Mitchell wrote: >> I was searching back in the archives, and in September there was a user >> who reported a problem with session resumption. I'm seeing the exact >> same symptoms I believe, also on Debian 5.0 with OpenSSL 0.9.8g. I never >> saw any follow up? Is there a fix known for this? I am using a locally >> compiled version of FreeRadius 2.1.7. It's linked against the system >> OpenSSL libraries though. Building a local 0.9.8k or even 1.0.0 is >> certainly an option if there is a chance it will help. > > There isn't a lot we can do. It's not clear *why* OpenSSL resumes > sessions when session resumption is disabled. OK. I can't easily replicate it. At least, I don't know exactly what circumstances cause it. The clients doesn't always cause this error to pop up. Only sometimes. I was hoping their was a known fix. It sounds like I'll have to dig into it deeper if it turns out to be a big issue. Thanks, -David Mitchell > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: over 30 radiusd processes
Up to 65 processes now
Any ideas how to stop this from happening?
Anyone?
Thanks,
-craig
- Original Message -
From: "Alan DeKok"
To: "FreeRadius users mailing list"
Sent: Saturday, October 10, 2009 1:21 AM
Subject: Re: over 30 radiusd processes
Craig Campbell wrote:
Yes, two(2) binaries and one (1) shell script are called via exec as
follows from the file,
Could you NOT CC me on messages to the list? I subscribe, and I read
the messages.
And fix your mailer. I saw a *large* number of duplicates.
- user (an authentication binary program - Exec-Program-Wait
= "/usr/local/sbin/auth -- %{User-Name} %{User-Password}
%{%{Called-Station-Id}:-Missing} %{%{NAS-IP-Address}:-Missing}
%{%{Calling-Station-Id}:-Missing} %{%{NAS-Port-Type}:-Missing}
%{Vendor-Specific}" ,)
-acct_user (shell script - Exec-Program =
"%{exec:/usr/local/sbin/acctstop.sh}", )
and
-attr_rewrite module (a hex translation binary - replacewith =
"%{exec:/usr/local/sbin/hexconvert -lX %{User-Name} }")
Is this bad?
Is there a better alternative?
Thanks so much!
-craig
- Original Message - From: "Alan DeKok"
To: "FreeRadius users mailing list"
Sent: Friday, October 09, 2009 4:17 PM
Subject: Re: over 30 radiusd processes
Craig Campbell wrote:
radius-a seems to be getting the bulk of the radius records. Normally,
it has a single process.
Last night it spawned a bunch of children that seem to be loitering...
Are you forking shell scripts via "exec"?
radius-b and radius-c don't have more than a single radiusd process.
Any idea what is going on? Why all the children? Do I need to be
concerned? Is this normal?
It's not normal. They're likely zombies that need to go away. The
server normally cleans up any zombie children, but...
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
__ Information from ESET Smart Security, version of virus
signature database 4494 (20091009) __
The message was checked by ESET Smart Security.
http://www.eset.com
__ Information from ESET Smart Security, version of virus
signature database 4494 (20091009) __
The message was checked by ESET Smart Security.
http://www.eset.com
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
__ Information from ESET Smart Security, version of virus
signature database 4494 (20091009) __
The message was checked by ESET Smart Security.
http://www.eset.com
__ Information from ESET Smart Security, version of virus signature
database 4501 (20091012) __
The message was checked by ESET Smart Security.
http://www.eset.com
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
returning an arbitrary attribute from LDAP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, I'm trying to ascertain how to have radiusd return an arbitrary attribute with each successful authentication. My radiusds are doing PEAP/MS-CHAPv2 against Kerberos for authn, and it seems like activating rlm_ldap for authz will cause "Auth-Type = LDAP" to enter my world, which I'm betting will break things. Also, I'm fuzzy as to where I'd do this sort of thing anyway; it seems that post-auth would be the place to start, but am uncertain. Any guidance you could offer (including pointers to existing mailing list threads or other docs) would be much appreciated. Cheers, - -sth sam hooker|s...@noiseplant.com|http://www.noiseplant.com "I have not failed, I've just found 10,000 ways that won't work." Thomas Edison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.9) iEYEARECAAYFAkrTglwACgkQX8KByLv3aQ2jdgCgpmoEskDoJGeoN2+ySzKRUqK9 /RUAoMGhPZ651eOj3oXGBtSf8ihwcHWO =e5Qa -END PGP SIGNATURE- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session resumption problem
David Mitchell wrote: > I was searching back in the archives, and in September there was a user > who reported a problem with session resumption. I'm seeing the exact > same symptoms I believe, also on Debian 5.0 with OpenSSL 0.9.8g. I never > saw any follow up? Is there a fix known for this? I am using a locally > compiled version of FreeRadius 2.1.7. It's linked against the system > OpenSSL libraries though. Building a local 0.9.8k or even 1.0.0 is > certainly an option if there is a chance it will help. There isn't a lot we can do. It's not clear *why* OpenSSL resumes sessions when session resumption is disabled. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Session resumption problem
I was searching back in the archives, and in September there was a user who reported a problem with session resumption. I'm seeing the exact same symptoms I believe, also on Debian 5.0 with OpenSSL 0.9.8g. I never saw any follow up? Is there a fix known for this? I am using a locally compiled version of FreeRadius 2.1.7. It's linked against the system OpenSSL libraries though. Building a local 0.9.8k or even 1.0.0 is certainly an option if there is a chance it will help. Here's a snippet from the original thread. I think it was about Sept. 1st 2009. I get similar errors. Sometimes the client (an Ubuntu 9.04 Jaunty laptop) connects, but sometimes I get this resumption error. My other clients (XP, iPhone, etc.) don't seem to ever exhibit the problem. > [peap] Success > [peap] FAIL: Forcibly stopping session resumption as it is not allowed. > [eap] Freeing handler Arg. FreeRADIUS tells OpenSSL to *not* allow session resumption, and it still negotiates session resumption. Which OS are you using? Which version of OpenSSL? -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: current status of other client features via SQL?
Alan Buxey wrote: > what is the current status of support for 'require_message_authenticator', > 'virtual_server' and 'coa_server' options being fed in via rlm_sql - > I'm aware that theres ability to name virtual_server but what happens > if the field is entry - does it go to the default virtual_server? Yes. > what work is needed for these client options to be supported via > SQL feed into clients list? Update the schemas, queries and code in rlm_sql.c. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Error: Received conflicting packet
Rihad, > > Take your NAS, and throw it in the garbage. Buy a real NAS that > > implements RADIUS. > > > Oh yeah? Isn't Cisco 7260 good enough for you? Hmmm ... A few months ago I was working on a project with a Cisco 72XX terminating PPoE connections from DSL modems. I was using custom SQL code during the authentication process. When the PPoE sessions were reset on the Cisco 72XX to test a power failure, there was a problem authenticating the PPoE sessions. Once I cleaned up the SQL code to improve its performance, the authentication problems went away. FreeRADIUS, MySQL with custom SQL code and the Cisco 72XX were able to authenticate over 14,000 PPoE sessions in 30 seconds. We also had a problem with broken DSL modems that continuously resent authentication requests with bad credentials. Based on my experience with the above project and many other projects, FR can process 1,000s of authenticate requests per second and performance problems tend be fixed by improving the performance of custom code, optimizing a database schema and/or tuning the database. You are welcome to tweak the FR server but based on the experience of many people running really big networks, that will not solve the problem. If you provide more information about your network and what you are trying to accomplish, people on the list can help you. Provide the following: - Perl script - Description of your network and what you are trying to accomplish with the PERL script - Copy of your configuration file The more information the better. Tim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
Hi, > finishing a request in my auth/acct Perl scripts, meaning each request > would take at least 1 second to process, freeradius shouldn't care! It okay...you have a daemon listening on port 1812 ... how many threads or radiusd processes are you running - because , for example, if you have 20 then once you get 100 requests, only the first 20 can be answered.. because all threads are stuck with your 1 second delay... thats 80 requests lost on the wire. those will be sent again.then you need to deal with the ones already being dealt with. if you put anything into the way that will slow down the ability to answer queries, then it will mess things up for you. if your PERL is the problem, then increase number of threads/children so you can handle more we have 64 listeners on our system that uses live PERL for dealing with requests...otherwise there were not enough listeners. ...if its accounting thats getting in the way (slow DB insert/updates) then move accounting out of the way - use the buffered-sql virtual server to deal with them 'out of band'. my systems can deal with hundreds of access requests per second...and are literally flooded by that many accounting-requests per second all day long. we are a cisco shop (and plenty of people on this list have had to deal with cisco wierdnesses in the world of RADIUS - there are workarounds all over the place for things they do wrong) and our solution didnt 'just work' overnight - because of loading issues, because of tweaks needed - we have FreeRADIUS because we could do these things to get around NAS limitations, NAS bugs and people NOT respecting the RFCs I'd rather have a server that DID follow the RFCs than one made by the vendor who chose to break the RFCs in their products int he first place. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
rihad wrote: > Ivan Kalik wrote: >> Exactly. The only problem being your inability to comprehend that >> freeradius is not faulty but it is your perl script that can't cope. > Why do you not understand that even if I put "sleep 1" right before > finishing a request in my auth/acct Perl scripts, meaning each request > would take at least 1 second to process, freeradius shouldn't care! Everyone understands that. No one *cares*. It's not *relevant*. > It > shouldn't be canceling the current request if another packet arrives a > couple of seconds later! Yes, it should. You've been told why. If you don't understand the explanation, go read the messages again. > Being swamped by requests it SHOULD be able to > make progress, ... working on requests that it will send to the NAS, and which the NAS will ignore. It's like asking a web server to continue processing a client request after the client has closed the TCP connection. After all, the web server is still making progress! Let's waste more CPU time rendering content that will *NEVER* make it to the client! That's a dumb idea. > and not be stomping on its toes canceling current > requests without any progress. And for that when.tv_sec = 1 should be a > bit higher, so it SHOULD be configurable, because some poor soul might > still prefer 2-5 second NAS timeout. If your NAS is transmitting a two packets with the same source IP, port, RADIUS code, and ID within 1 second... it's broken. No amount of "fixing" FreeRADIUS will change that. No amount of outright denial will change that. No amount of ignoring our explanations will change that. Now stop arguing on this list. It is impossible to convince us that wasting CPU time is a good idea. (And ignoring our explanations makes it clear that you have no interest in educating yourself) You have the source code to the server: butcher it to do whatever you want. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
Ivan Kalik wrote: Being 100% correct protocol-wise means nothing, if the software can't fit well into an environment. Exactly. The only problem being your inability to comprehend that freeradius is not faulty but it is your perl script that can't cope. Why do you not understand that even if I put "sleep 1" right before finishing a request in my auth/acct Perl scripts, meaning each request would take at least 1 second to process, freeradius shouldn't care! It shouldn't be canceling the current request if another packet arrives a couple of seconds later! Being swamped by requests it SHOULD be able to make progress, and not be stomping on its toes canceling current requests without any progress. And for that when.tv_sec = 1 should be a bit higher, so it SHOULD be configurable, because some poor soul might still prefer 2-5 second NAS timeout. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
> Being 100% correct protocol-wise means nothing, if the software can't > fit well into an environment. Exactly. The only problem being your inability to comprehend that freeradius is not faulty but it is your perl script that can't cope. If you are unwilling to alter it in order to speed things up you can separate authentication and accounting using buffered-sql virtual server. On high loads that arrangement will favour authentication while accounting will lag behind and catch up when load goes down. You shouldn't have any conflicting packets then because router will just be re-sending accounting packets. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Using SQL instead of radutmp - WAS Re: Problems with radutmp
gt;>>>> >>>>> When a user logs in, a corresponding entry is added to radutmp, and >>>>> indeed, nobody can log in with this user account (if I activate >>>>> Simultaneous-use). But if another users logs in, the entry for the >>>>> previous user gets deleted from radutmp, and a new one is added for >>>>> this new user. Then, a user with the account from the first user >>>>> can log in indeed. In other words, only the last logged in user >>>>> gets to the radutmp file. >>>>> >>>>> On both boxes, using freeradius 2.1.0. >>>>> >>>>> Any idea? >>>>> >>>>> -- >>>>> Gerardo Contreras >>>>> NetX >>>>> http://netx.com.mx/ >>>>> T: +52 (614) 2010101 x 121 >>>>> M: +52 (614) 2479727 >>>>> Sin costo: 01800 GO2NETX >>>>> >>>>> - >>>>> List info/subscribe/unsubscribe? See >>>>> http://www.freeradius.org/list/users.html >>>>> >>>>> __ Information from ESET Smart Security, version of virus >>>>> signature database 4493 (20091009) __ >>>>> >>>>> The message was checked by ESET Smart Security. >>>>> >>>>> http://www.eset.com >>>>> >>>>> >>>>> >>>> >>>> >>>> __ Information from ESET Smart Security, version of virus >>>> signature database 4493 (20091009) __ >>>> >>>> The message was checked by ESET Smart Security. >>>> >>>> http://www.eset.com >>>> >>>> >>>> >>>> - >>>> List info/subscribe/unsubscribe? See >>>> http://www.freeradius.org/list/users.html >>> >>> >>> -- >>> Gerardo Contreras >>> NetX >>> http://netx.com.mx/ >>> T: +52 (614) 2010101 x 121 >>> M: +52 (614) 2479727 >>> Sin costo: 01800 GO2NETX >>> >>> >>> __ Information from ESET Smart Security, version of virus >>> signature database 4494 (20091009) __ >>> >>> The message was checked by ESET Smart Security. >>> >>> http://www.eset.com >>> >>> >>> >> >> >> __ Information from ESET Smart Security, version of virus >> signature database 4494 (20091009) __ >> >> The message was checked by ESET Smart Security. >> >> http://www.eset.com >> >> >> > > > > __ Information from ESET Smart Security, version of virus signature > database 4494 (20091009) __ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > __ Information from ESET Smart Security, version of virus signature database 4500 (20091012) __ The message was checked by ESET Smart Security. http://www.eset.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
> accounting {
>if (Acct-Status-Type == Start) {
>update reply {
> Tmp-String-0 =
> "%{exec:/etc/freeradius/SCRIPT/userlogin.py %{User-Name}}"
> }
> }
> if (Acct-Status-Type == Stop) {
> update reply {
> Tmp-String-0 =
> "%{exec:/etc/freeradius/SCRIPT/userlogout.py %{User-Name}}"
> }
>}
You can replace call to exec module by call to sql:
Tmp-String-0 = "%{sql:UPDATE whatever}"
Current server versions should support UPDATEs and INSERTs as well as
SELECTs which vere only ones supported in early 2.x versions.
> I need to launch a script with after login and logout.
>
> Maybe this script cause some problems? It's a simple python script that
> update a field in db (online/offiline flag).
Do you need that at all? Instead of calling the database to see if the
flag (wherever you are using it) is set you can make a query that checks
if user is online.
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
rihad wrote: > Being 100% correct protocol-wise means nothing, if the software can't > fit well into an environment. So you agree that the NAS is broken. > Just a recent example off the top of my > head: dnscache. Its security and DNS protocol support are astonishing. > But due to it being unable to work reasonably under certain > circumstances, and due to its author preferring to stick with the > arguable RFC specification which is outright buggy, I was forced to go > back to BIND. In reply to my post Jeremy Kister was kind enough to > describe the problem very well: > http://marc.info/?l=djbdns&m=125265930702615&w=2 > and linked from above: > http://securepoint.com/lists/html/djbdns/2007-01/msg00033.html Why do you insist that FreeRADIUS is at fault, when you have already been told that the NAS is broken? Why are you not calling Cisco, and asking them to fix their broken NAS? Do you hate FreeRADIUS? Are you interested in blaming it for every problem in the network? And your argument about RFC compliance is made to the wrong person. There's a RADIUS RFC called "issues and fixes", which points out problems with older RFC's, and says how they should be fixed. Guess who's co-author? There's another RFC that's up and coming, called "guidelines", about how to write RADIUS RFC's so that they can easily be implemented. Guess who's co-author? And have you looked at the FreeRADIUS source code? There are things in the RFC's that it *doesn't* do, because they're stupid. There are other things that are *now* in RFC's, because FreeRADIUS did them first. Sorry... your debug messages show two things: slow Perls scripts, and a buggy NAS. Nothing else. You have *not* identified bad behavior in FreeRADIUS, unlike others recently on this list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
Alan DeKok wrote: rihad wrote: Oh yeah? Isn't Cisco 7260 good enough for you? Q: Hi, I have a RADIUS server that is slower than a 386, and a NAS that violates the RADIUS protocol. What should I do? A: Fix the server and the NAS. Q: You bastards! How dare you tell me my equipment is broken! While this is entertaining, it only proves one thing. Being 100% correct protocol-wise means nothing, if the software can't fit well into an environment. Just a recent example off the top of my head: dnscache. Its security and DNS protocol support are astonishing. But due to it being unable to work reasonably under certain circumstances, and due to its author preferring to stick with the arguable RFC specification which is outright buggy, I was forced to go back to BIND. In reply to my post Jeremy Kister was kind enough to describe the problem very well: http://marc.info/?l=djbdns&m=125265930702615&w=2 and linked from above: http://securepoint.com/lists/html/djbdns/2007-01/msg00033.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
current status of other client features via SQL?
hi, just a quick catch-up on using SQL for client configuration... what is the current status of support for 'require_message_authenticator', 'virtual_server' and 'coa_server' options being fed in via rlm_sql - I'm aware that theres ability to name virtual_server but what happens if the field is entry - does it go to the default virtual_server? what work is needed for these client options to be supported via SQL feed into clients list? thanks alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: getting disconnected.
> I changed the listen IP as you has told me last time. Now I am able to > connect to the free radius, I get the vrf properly configured on the LNS > as expected by the radius and get the proper IP also. But now the problem > is that once I am connected, after 5 secs i get disconnected. According to the debug session lasted only one second and host (NAS) then kicked the user off. Debug PPP on the NAS and see why. > I saw in the > LNS logs, in which I noted that the request is send to 172.31.6.158, but I > am getting reply from radius on the other IP which is 202.54.6.101, > basicaly I have 2 IP`s on radius server. The later one I used for > downloading the packages from internet. > > Please let me know what and where I should do the change so that Radius > replies with the IP that it is listening from. You have changed the IP in authentication listen section but not in accounting one as well. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
rihad wrote: > Oh yeah? Isn't Cisco 7260 good enough for you? Q: Hi, I have a RADIUS server that is slower than a 386, and a NAS that violates the RADIUS protocol. What should I do? A: Fix the server and the NAS. Q: You bastards! How dare you tell me my equipment is broken! While this is entertaining, it only proves one thing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
getting disconnected.
Hi, I changed the listen IP as you has told me last time. Now I am able to connect to the free radius, I get the vrf properly configured on the LNS as expected by the radius and get the proper IP also. But now the problem is that once I am connected, after 5 secs i get disconnected. I saw in the LNS logs, in which I noted that the request is send to 172.31.6.158, but I am getting reply from radius on the other IP which is 202.54.6.101, basicaly I have 2 IP`s on radius server. The later one I used for downloading the packages from internet. Please let me know what and where I should do the change so that Radius replies with the IP that it is listening from. I am attaching the debug logs on the LNS for your ref; _ 031415: Oct 12 17:23:05.705 IST: RADIUS/ENCODE(06A8):Orig. component type = VPDN 031416: Oct 12 17:23:05.705 IST: RADIUS(06A8): Config NAS IP: 192.168.243.250 031417: Oct 12 17:23:05.705 IST: RADIUS(06A8): sending 031418: Oct 12 17:23:05.705 IST: RADIUS(06A8): Send Accounting-Request to 172.31.6.158:1646 id 1646/185, len 266 031419: Oct 12 17:23:05.705 IST: RADIUS: authenticator A7 A6 49 D5 CF 5B A2 CE - 45 8E 68 4C 71 51 F6 17 031420: Oct 12 17:23:05.705 IST: RADIUS: Acct-Session-Id [44] 10 "0A27" 031421: Oct 12 17:23:05.705 IST: RADIUS: Tunnel-Type [64] 6 00:L2TP [3] 031422: Oct 12 17:23:05.705 IST: RADIUS: Tunnel-Medium-Type [65] 6 00:IPv4 [1] 031423: Oct 12 17:23:05.705 IST: RADIUS: Tunnel-Server-Endpoi[67] 17 "192.168.243.250" 031424: Oct 12 17:23:05.705 IST: RADIUS: Tunnel-Client-Endpoi[66] 15 "172.23.119.14" 031425: Oct 12 17:23:05.705 IST: RADIUS: Tunnel-Assignment-Id[82] 3 "1" 031426: Oct 12 17:23:05.705 IST: RADIUS: Tunnel-Client-Auth-I[90] 15 "l2tp-tata-lac" 031427: Oct 12 17:23:05.705 IST: RADIUS: Tunnel-Server-Auth-I[91] 16 "hb-vsb-t1-rw01" 031428: Oct 12 17:23:05.705 IST: RADIUS: Acct-Tunnel-Connecti[68] 11 "126111449" 031429: Oct 12 17:23:05.705 IST: RADIUS: Framed-Protocol [7] 6 PPP [1] 031430: Oct 12 17:23:05.705 IST: RADIUS: User-Name [1] 16 "t...@cisco1.com" 031431: Oct 12 17:23:05.705 IST: RADIUS: Acct-Authentic [45] 6 RADIUS [1] 031432: Oct 12 17:23:05.705 IST: RADIUS: Acct-Session-Time [46] 6 1 031433: Oct 12 17:23:05.709 IST: RADIUS: Acct-Input-Octets [42] 6 84 031434: Oct 12 17:23:05.709 IST: RADIUS: Acct-Output-Octets [43] 6 90 031435: Oct 12 17:23:05.709 IST: RADIUS: Acct-Input-Packets [47] 6 5 031436: Oct 12 17:23:05.709 IST: RADIUS: Acct-Output-Packets [48] 6 6 031437: Oct 12 17:23:05.709 IST: RADIUS: Acct-Terminate-Cause[49] 6 host-request [18] 031438: Oct 12 17:23:05.709 IST: RADIUS: Acct-Status-Type[40] 6 Stop [2] 031439: Oct 12 17:23:05.709 IST: RADIUS: NAS-Port-Type [61] 6 Virtual [5] 031440: Oct 12 17:23:05.709 IST: RADIUS: NAS-Port[5] 6 751 031441: Oct 12 17:23:05.709 IST: RADIUS: NAS-Port-Id [87] 17 "Uniq-Sess-ID751" 031442: Oct 12 17:23:05.709 IST: RADIUS: Calling-Station-Id [31] 17 "404001629241466" 031443: Oct 12 17:23:05.709 IST: RADIUS: Connect-Info[77] 13 "64000/57600" 031444: Oct 12 17:23:05.709 IST: RADIUS: Service-Type[6] 6 Framed [2] 031445: Oct 12 17:23:05.709 IST: RADIUS: NAS-IP-Address [4] 6 192.168.243.250 031446: Oct 12 17:23:05.709 IST: RADIUS: Acct-Delay-Time [41] 6 0 031447: Oct 12 17:23:05.725 IST: RADIUS: Received from id 1646/185 202.54.6.101:1646, Accounting-response, len 20 031448: Oct 12 17:23:05.725 IST: RADIUS: Response for non-existent request ident 031449: Oct 12 17:23:06.389 IST: %LINK-3-UPDOWN: Interface Virtual-Access4, changed state to down 031450: Oct 12 17:23:10.581 IST: RADIUS: no sg in radius-timers: ctx 0x654F7FC4 sg 0x 031451: Oct 12 17:23:10.581 IST: RADIUS: Retransmit to (172.31.6.158:1645,1646) for id 1646/184 031452: Oct 12 17:23:10.581 IST: RADIUS: acct-delay-time for C0040B4 (at C004194) now 5 031453: Oct 12 17:23:10.597 IST: RADIUS: Received from id 1646/186 202.54.6.101:1646, Accounting-response, len 20 031454: Oct 12 17:23:10.597 IST: RADIUS: Response for non-existent request ident 031455: Oct 12 17:23:11.413 IST: RADIUS: no sg in radius-timers: ctx 0x50802954 sg 0x 031456: Oct 12 17:23:11.413 IST: RADIUS: Retransmit to (172.31.6.158:1645,1646) for id 1646/185 031457: Oct 12 17:23:11.413 IST: RADIUS: acct-delay-time for C3A1DF4 (at C3A1EF8) now 5 031458: Oct 12 17:23:11.429 IST: RADIUS: Received from id 1646/187 202.54.6.101:1646, Accounting-response, len 20 031459: Oct 12 17:23:11.429 IST: RADIUS: Response for non-existent request ident 031460: Oct 12 17:23:15.893 IST: RADIUS: no sg in radius-timers: ctx 0x654F7FC4 sg 0x 031461: Oct 12
Re: Error: Received conflicting packet
Alan DeKok wrote: rihad wrote: Trying for the third time: Do you have any intention of reading the messages here? there are many, many requests of the "Discarding conflicting packet" kind, which for one reason or another are dupped by our Cisco NASes in under one second (see the code). And there are many, many lines of the "Received conflicting packet" fame (see the code). If (as you say) the NAS is sending a conflicting packet within 1 second of the first one, then the NAS is broken. It SHOULD wait 5 seconds for the old request to time out, before sending a new one that re-uses the same IP/port/Id. Take your NAS, and throw it in the garbage. Buy a real NAS that implements RADIUS. Oh yeah? Isn't Cisco 7260 good enough for you? Now, it can be logically deduced that a big part of the latter are indeed of the former type (because none of the NASes have timeouts as low as 2-5 seconds). What I'd really love is for freeradius to stop killing the current request after receiving a dup 2-5 seconds apart. That won't solve anything. This has been explained to you. Did you understand the explanation, or are you simply ignoring it? Explained what? What good is an explanation without testing it? True, I still haven't tested increasing the 1 second wait either. It's no problem for me to patch and rebuild freeradius myself, I just thought it wouldn't be fair not to share that idea with others. Thanks. And we shared our opinions... and you told us we were wrong. Stop hacking the server and start looking at your perl code. Do you really need to use it for authentication? Can you get all the data in authorize script and let freeradius default modules do the authentication (that can speed things up quite a bit)? Can you get (some of) the data using freeradius sql/ldap/whatever modules instead? The rlm_perl authorization/accounting is dealing with traffic shaping, so I'd rather fix this freeradius' shortcoming. That response completely ignores the question. Did you understand it? Didn't I say the Perl code might not be fast enough to handle hundreds of requests per second? Probably up to several thousand. What good will some sql/ldap/whatever tests do if I'm not going to be using them? That said, I've increased cleanup_delay from 5 to 120, and max_requests from 1 to 10. Let's wait... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
rihad wrote: > Trying for the third time: Do you have any intention of reading the messages here? > there are many, many requests of the > "Discarding conflicting packet" kind, which for one reason or another > are dupped by our Cisco NASes in under one second (see the code). And > there are many, many lines of the "Received conflicting packet" fame > (see the code). If (as you say) the NAS is sending a conflicting packet within 1 second of the first one, then the NAS is broken. It SHOULD wait 5 seconds for the old request to time out, before sending a new one that re-uses the same IP/port/Id. Take your NAS, and throw it in the garbage. Buy a real NAS that implements RADIUS. > Now, it can be logically deduced that a big part of the > latter are indeed of the former type (because none of the NASes have > timeouts as low as 2-5 seconds). What I'd really love is for freeradius > to stop killing the current request after receiving a dup 2-5 seconds > apart. That won't solve anything. This has been explained to you. Did you understand the explanation, or are you simply ignoring it? > It's no problem for me to patch and rebuild freeradius myself, I > just thought it wouldn't be fair not to share that idea with others. Thanks. And we shared our opinions... and you told us we were wrong. >> Stop hacking the server and start looking at your perl code. Do you >> really >> need to use it for authentication? Can you get all the data in authorize >> script and let freeradius default modules do the authentication (that can >> speed things up quite a bit)? Can you get (some of) the data using >> freeradius sql/ldap/whatever modules instead? >> > > The rlm_perl authorization/accounting is dealing with traffic shaping, > so I'd rather fix this freeradius' shortcoming. That response completely ignores the question. Did you understand it? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
Ivan Kalik wrote: Our radius-server timeout is high enough: 4 minutes. Once again: I suppose that what freeradius thinks of as "Received conflicting packet ..." are rather a bit delayed packets normally treated as "Discarding conflicting packet ...", i.e. they arrive at freeradius in maybe 1.01+ second after the first request, but freeradius drops the current request instead of the new one. Soon I'm gonna rebuild freeradius with changed tv_sec and check that. huh? do you not understand the basic context of this issue? if the NAS has sent a repeat RADIUS packet then it means that the original packet has already been timed out and the NAS should NOT accept an 'accept' response on that original packet. Please see the comment from the code snippet in src/main/event.c in my original posting. Some duplicate packets might arrive after 1 sec. by a slight margin, even though they logically are whatever that special-cased conditional was designed to handle. 1 second? Freeradius keeps track of duplicates for 5 minutes by default. That is if processing has been completed. But in your case requests are still being processed 4 minutes after NAS sent them (if that is your retry interval on the NAS as you claim - default is usually 2 minutes). That is why it gave up on them and sent a new request. How do you think that adjusting that 1 second interval is going to help *your* case??? Trying for the third time: there are many, many requests of the "Discarding conflicting packet" kind, which for one reason or another are dupped by our Cisco NASes in under one second (see the code). And there are many, many lines of the "Received conflicting packet" fame (see the code). Now, it can be logically deduced that a big part of the latter are indeed of the former type (because none of the NASes have timeouts as low as 2-5 seconds). What I'd really love is for freeradius to stop killing the current request after receiving a dup 2-5 seconds apart. It's no problem for me to patch and rebuild freeradius myself, I just thought it wouldn't be fair not to share that idea with others. Stop hacking the server and start looking at your perl code. Do you really need to use it for authentication? Can you get all the data in authorize script and let freeradius default modules do the authentication (that can speed things up quite a bit)? Can you get (some of) the data using freeradius sql/ldap/whatever modules instead? The rlm_perl authorization/accounting is dealing with traffic shaping, so I'd rather fix this freeradius' shortcoming. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
>>> Our radius-server timeout is high enough: 4 minutes. Once again: I >>> suppose that what freeradius thinks of as "Received conflicting packet >>> ..." are rather a bit delayed packets normally treated as "Discarding >>> conflicting packet ...", i.e. they arrive at freeradius in maybe 1.01+ >>> second after the first request, but freeradius drops the current >>> request >>> instead of the new one. Soon I'm gonna rebuild freeradius with changed >>> tv_sec and check that. >> >> huh? do you not understand the basic context of this issue? if the NAS >> has sent a repeat RADIUS packet then it means that the original packet >> has already been timed out and the NAS should NOT accept an 'accept' >> response >> on that original packet. > Please see the comment from the code snippet in src/main/event.c in my > original posting. Some duplicate packets might arrive after 1 sec. by a > slight margin, even though they logically are whatever that > special-cased conditional was designed to handle. 1 second? Freeradius keeps track of duplicates for 5 minutes by default. That is if processing has been completed. But in your case requests are still being processed 4 minutes after NAS sent them (if that is your retry interval on the NAS as you claim - default is usually 2 minutes). That is why it gave up on them and sent a new request. How do you think that adjusting that 1 second interval is going to help *your* case??? Stop hacking the server and start looking at your perl code. Do you really need to use it for authentication? Can you get all the data in authorize script and let freeradius default modules do the authentication (that can speed things up quite a bit)? Can you get (some of) the data using freeradius sql/ldap/whatever modules instead? Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 1.Troubleshooting MySQL Connections , 2. troubleshooting possible memory leak
Stefan A. wrote: > I still see the memory consumption rising over the time > Output from top every 5 Minutes: > SIZE/RES > 16M/13M > 34M/32M > 53M/51M > 71M/69M > ...it rises about 3-4 MB per Minutes. Ugh. > I read about some issues and tried 2.1.7... still the same. Because the code in rlm_sql.c hasn't changed. > My Setup: > SUN X4100, 8GB, Solaris 10 5/09 > Configured and installed incl. MySQL, but even if I disabled it for runtime, > the memory rises. > > What would be a good start to debug this? > Is there a possibility, to see, which part of the running radiusd consumes > what amount of memory? $ ./configure --disable-shared That will cause all of the libraries to be linked into the server. You'll also need to edit src/main/Makefile, and delete: LINK_MODE = -static -all-static That will let the modules be linked into the server, but will keep the server in a form that valgrind can use. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
Alan Buxey wrote: Hi, Our radius-server timeout is high enough: 4 minutes. Once again: I suppose that what freeradius thinks of as "Received conflicting packet ..." are rather a bit delayed packets normally treated as "Discarding conflicting packet ...", i.e. they arrive at freeradius in maybe 1.01+ second after the first request, but freeradius drops the current request instead of the new one. Soon I'm gonna rebuild freeradius with changed tv_sec and check that. huh? do you not understand the basic context of this issue? if the NAS has sent a repeat RADIUS packet then it means that the original packet has already been timed out and the NAS should NOT accept an 'accept' response on that original packet. Please see the comment from the code snippet in src/main/event.c in my original posting. Some duplicate packets might arrive after 1 sec. by a slight margin, even though they logically are whatever that special-cased conditional was designed to handle. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Hi to all,
I've installad freeradius on a Debian box with Mysql DB.
After the upgrade from freeradius version 1.7 and freeradius 2.x I
notice that sometimes, but everyday, the freeradius doesn't respond. I
must do a /etc/init.d/freeradius restart
In my log:
Mon Oct 12 10:24:45 2009 : Info: rlm_sql (sql): There are no DB handles
to use! skipped 0, tried to connect 0
The only modification that I have made to conf is:
with Freeradius 1.7
radius:/etc/freeradius# cat ../freeradius.orig/acct_users
DEFAULT Acct-Status-Type == "Start"
Exec-Program = "/etc/freeradius/SCRIPT/userlogin.py
%{User-Name}"
DEFAULT Acct-Status-Type == "Stop"
Exec-Program = "/etc/freeradius/SCRIPT/userlogout.py
%{User-Name"
on Freeradius 2.x I've modified the accounting conf file:
#
# Accounting. Log the accounting data
#
accounting {
if (Acct-Status-Type == Start) {
update reply {
Tmp-String-0 =
"%{exec:/etc/freeradius/SCRIPT/userlogin.py %{User-Name}}"
}
}
if (Acct-Status-Type == Stop) {
update reply {
Tmp-String-0 =
"%{exec:/etc/freeradius/SCRIPT/userlogout.py %{User-Name}}"
}
}
I need to launch a script with after login and logout.
Maybe this script cause some problems? It's a simple python script that
update a field in db (online/offiline flag).
Can I substitute this external script with a query inside freeradius?
How can I create a custom (new) query and lunch it from the accounting
section?
#
# Accounting. Log the accounting data
#
accounting {
if (Acct-Status-Type == Start) {
update reply {
LAUNCH MYQUERY HERE FOR A SPECIFIC
USER
}
}
if (Acct-Status-Type == Stop) {
update reply {
LAUNCH MYQUERY HERE FOR A SPECIFIC USER
}
}
OR... may the problem is some slow query... but... how can I debug this?
can someone suggest me a method?
Best regards.
--
Gianni Olivieri
SICE Telecomunicazioni
Via Tazio Nuvolari, 53
55061 - Carraia (LU) - ITALY
Tel. +39 0583 980787
Fax +39 0583 981495
www.sicetelecom.it
gianni.olivi...@sicetelecom.it
---
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Error: Received conflicting packet
Hi, > Our radius-server timeout is high enough: 4 minutes. Once again: I > suppose that what freeradius thinks of as "Received conflicting packet > ..." are rather a bit delayed packets normally treated as "Discarding > conflicting packet ...", i.e. they arrive at freeradius in maybe 1.01+ > second after the first request, but freeradius drops the current request > instead of the new one. Soon I'm gonna rebuild freeradius with changed > tv_sec and check that. huh? do you not understand the basic context of this issue? if the NAS has sent a repeat RADIUS packet then it means that the original packet has already been timed out and the NAS should NOT accept an 'accept' response on that original packet. your RADIUS timeout is 4 minutes??? the highest sorts of values that you should ever expect a RADIUS request to be 'on the wire' is around 12 seconds - and thats for proxied packets that have travelled around the world. what OS are you running on that Dell? The only thing I can think of is one of the dodgy RedHat buggy releases where there was a MASSIVE Perl startup penalty - thats been fixed in all recent distros (unless its come back again). we have single and dual core Dell system (manufacturer really doesnt matter - we're still talking about basic PC hardware - that can do several thousand auths per second...and thats with Perl involved too. i wonder if you are killing your RADIUS via some others task - eg its the accounting thats blocking the threads because you are accounting to eg SQL rather than to disk and using buffered-sql (very very common issue) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
