Interim Accounting updates question
Hi, I have just set up freeradius and trying to get the accountingdata to be stored in MySQL. Now I have a problem with interim accountion updates, my SQL database doesn't update. In a reqular acct-status-type = stop (2), everything works fine, looks like this: radius_xlat: 'UPDATE radacct SET AcctStopTime = '2001-08-23 10:28:46', AcctSessionTime = '100', AcctInputOctets = '', AcctOutputOctets = '600', AcctTerminateCause = '', AcctStopDelay = '', ConnectInfo_stop = '' WHERE AcctSessionId = '' AND UserName = 'sven' AND NASIPAddress = '192.168.1.25'' When sending the same attributes to the server except changing acct-status-type= 3, i get the following: radius_xlat: 'UPDATE radacct SET FramedIPAddress = '', AcctSessionTime = '100', AcctOutputOctets = '600' WHERE AcctSessionId = '' AND UserName = '' AND NASIPAddress= '192.168.1.25'' make note that there is no username?? why is that? I thing this is why the sql database doesn't change. I have been loking in to the sql.conf file and everything looks ok I think. I'm using freradius v 0.1, doesn't it support RFC 2869 Radius Extensions? Is it only v 0.2 that supports RFC 2869? /Daniel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dropping conflicting authentication packet
Spike Ilacqua [EMAIL PROTECTED] wrote: If it works in debug, has issues in regular, check the permissions needed to read the auth files. I'm seeing basically the same thing, but I don't believe it's a permision problem. The server does work in regular mode, it's only after about 20 minutes it starts reporting Dropping conflicting authentication packet. When it does this it seems to be for every possible ID 1 to 256, suggesting to me requests arn't getting freed for some reason. OK, that's a *serious* problem. Yet, I've run in debug mode for up to an hour and things are fine. Hmm... different code paths are Not Nice. I'll take a look at it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Interim Accounting updates question
daniel malmkvist [EMAIL PROTECTED] wrote: In a reqular acct-status-type = stop (2), everything works fine, looks like this: ... When sending the same attributes to the server except changing acct-status-type= 3, i get the following: radius_xlat: 'UPDATE radacct SET FramedIPAddress = '', AcctSessionTime = '100', AcctOutputOctets = '600' WHERE AcctSessionId = '' AND UserName = '' AND NASIPAddress= '192.168.1.25'' make note that there is no username?? why is that? Let me guess: The NAS is not sending the User-Name attribute in the radius packet. I'm using freradius v 0.1, doesn't it support RFC 2869 Radius Extensions? Is it only v 0.2 that supports RFC 2869? RFC2869 is supported, but not completely. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Conditional proxy
I would like to know if there is a way of proxying users only if certain conditions are met iow 'check items' for proxied requests. In my application I need to proxy certain realms only if for example NAS-Port-Type==Async. Any suggestions? Thanks, Eddie - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Conditional proxy
Eddie Stassen [EMAIL PROTECTED] wrote: I would like to know if there is a way of proxying users only if certain conditions are met iow 'check items' for proxied requests. In my application I need to proxy certain realms only if for example NAS-Port-Type==Async. Any suggestions? Yes... DEFAULT NAS-Port-Type == Async, Proxy-To-Realm := foo.com Fall-Through = 1 DEFAULT NAS-Port-Type != Async, Proxy-To-Realm := bar.com Fall-Through = 1 Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Dropping conflicting authentication packet
At 10:19 AM 8/23/2001 -0700, you wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Qinxue Chen [EMAIL PROTECTED] wrote: The problem seems to be that the new request has the same request ID, request code, source IP, source port, but different vectors (what's this?) It means that the request is a new one, and different from the first on. The RFC's specifically allow for this. as one of the old requests. From the problem I saw, it is not caused by the NAS end. The freeradius didn't clear some old requests properly in the buffer for whatever reasons. Some request IDs stayed for about several hours. I am not quiet sure about the whole process in the software. If Alan or Chris could explain a little bit, it will be greatly appreciated. There's not much to say. It looks like the server has a bug. But in the software, the new requests are dropped. Yesterday I modified the code (radiusd.c) a little. The whole else block for the error part was got rid of. That means the new request would be added and processed. I run it the whole night without problems. I only worried about possible memory leak. I believed that some old requests were still in the request data. From my tests with the change, memory usage was fine on the box. The way to solve the problem cleanly is to identify two cases: 1) old requests stayed for a long time in the request data. 2) server is not fast enough to handle a request and a new request with the same id/code/ip/port comes in. Case 1) can be caused by whatever reasons like threads die. For case 1), a new request can replace the old one in the request data. For my tests, all problems fall in case 1). For case 2), the possible solutions: a. drop the new request b. use new request to replace the old request. From the performance view, there is no difference between the two solutions. Then for both case 1) and 2), we can do the same thing: replace the old request with the new one. What do you think? No. Read the RFC. Understand how Authentication-Vector is used. Your case1 is correct, your case2 is handled. The reason there is a problem is old requests are for some reason not being cleared. That's all there is, don't try and make it more complex, it's a bug in the code, not a design flaw. -Chris -- \\\|||/// \ Chris Parker-Manager, Development Engineering \ ~ ~ / \ WX *is* Wireless!\ [EMAIL PROTECTED] | @ @ |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Without C we would have 'obol', 'basi', and 'pasal' - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Dropping conflicting authentication packet
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Qinxue Chen [EMAIL PROTECTED] wrote: The problem seems to be that the new request has the same request ID, request code, source IP, source port, but different vectors (what's this?) It means that the request is a new one, and different from the first on. The RFC's specifically allow for this. as one of the old requests. From the problem I saw, it is not caused by the NAS end. The freeradius didn't clear some old requests properly in the buffer for whatever reasons. Some request IDs stayed for about several hours. I am not quiet sure about the whole process in the software. If Alan or Chris could explain a little bit, it will be greatly appreciated. There's not much to say. It looks like the server has a bug. But in the software, the new requests are dropped. Yesterday I modified the code (radiusd.c) a little. The whole else block for the error part was got rid of. That means the new request would be added and processed. I run it the whole night without problems. I only worried about possible memory leak. I believed that some old requests were still in the request data. From my tests with the change, memory usage was fine on the box. The way to solve the problem cleanly is to identify two cases: 1) old requests stayed for a long time in the request data. 2) server is not fast enough to handle a request and a new request with the same id/code/ip/port comes in. Case 1) can be caused by whatever reasons like threads die. For case 1), a new request can replace the old one in the request data. For my tests, all problems fall in case 1). For case 2), the possible solutions: a. drop the new request b. use new request to replace the old request. From the performance view, there is no difference between the two solutions. Then for both case 1) and 2), we can do the same thing: replace the old request with the new one. What do you think? --Qinxue Chen __ NetZero Platinum Sign Up Today - Only $9.95 per month! http://www.netzero.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Dropping conflicting authentication packet
No. Read the RFC. Understand how Authentication-Vector is used. Your case1 is correct, your case2 is handled. The reason there is a problem is old requests are for some reason not being cleared. That's all there is, don't try and make it more complex, it's a bug in the code, not a design flaw. No matter how smoothly the code can run, case1 should be always considered from the design point of view. Then the two cases need to be identified. That's what I thought. --Qinxue Chen __ NetZero Platinum Sign Up Today - Only $9.95 per month! http://www.netzero.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dropping conflicting authentication packet
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Qinxue Chen [EMAIL PROTECTED] wrote: The problem seems to be that the new request has the same request ID, request code, source IP, source port, but different vectors (what's this?) It means that the request is a new one, and different from the first on. The RFC's specifically allow for this. They do? Where does it say that?. And at least for accounting packets the vector is _supposed_ to change since the packet itself changes - the value of the Acct-Delay-Time attribute increases for each packet. Mike. -- Answering above the the original message is called top posting. Sometimes also called the Jeopardy style. Usenet is Q A not A Q. -- Bob Gootee - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dropping conflicting authentication packet
[EMAIL PROTECTED] (Miquel van Smoorenburg) wrote: It means that the request is a new one, and different from the first on. The RFC's specifically allow for this. They do? Where does it say that?. And at least for accounting packets the vector is _supposed_ to change since the packet itself changes - the value of the Acct-Delay-Time attribute increases for each packet. When an authentication packet is sent, it MAY be sent from the same port as a previous one, and it MAY re-use the same ID. In that case, the authentication vectors MUST be different, if it is a different request. accounting packets the vector is _supposed_ to change since the packet itself changes - the value of the Acct-Delay-Time attribute increases for each packet. Yes. Re-sent authentication packets don't change, as their contents don't change. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radiusd and time limit for one day
I think I know what he means, because I'd like to do the same thing here. That is, limit someone's dialin time to 1 hour (or whatever) per day. So today he can log in for one hour. Once that hour's up, he has to wait until tomorrow. He'll get another hour tomorrow. And so on. Is that possible, and if so how? - Dan Perik Paul Foxton wrote: Hi, Not 100% surewhat you want to do, but if you mean you want to set the time a user can log in: yes it is possible, with Login-Time. You need to specify this in the first line of your entry for the user in the users file as follows: usernameAuth-Type := local, Password == password, Login-Time := Al0800-0900 etc... This would only allow access between 8 9 in the morning on any day of the week (Al). Have a look in the /doc/README file, it tells you your options for what you can set. cheers, Paul -Original Message- From: Ronald Warner [mailto:[EMAIL PROTECTED]] Sent: 23 August 2001 02:54 To: [EMAIL PROTECTED] Subject: radiusd and time limit for one day time limit is easy to set... However, is it possible to limit that time limit for a specific period of time. For example, the user can only dial-in for only one hour a day. Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - Dan Perik Computer Services Department Lapilo Center New Tribes Mission - PNG - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radiusd and time limit for one day
On Fri, 24 Aug 2001, Dan Perik wrote: I think I know what he means, because I'd like to do the same thing here. That is, limit someone's dialin time to 1 hour (or whatever) per day. So today he can log in for one hour. Once that hour's up, he has to wait until tomorrow. He'll get another hour tomorrow. And so on. Is that possible, and if so how? - Dan Perik Take a look at rlm_counter. -- kkalev - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
