Hello Peter -
I haven't actually tested this myself (although I will a bit later), so you should try it as you show below to see if it works. If it doesn't, you should use the new HostColumnDef with a HostSelect in Radiator 3.1. regards Hugh On Fri, 24 May 2002 03:56, peter moody wrote: > Hugh, > Should this be done in conjunction with AccountingHandled (section > 6.16.10) ? > > Also, our setup is such that we have two AuthBy's per proxy realm > looking something like this: > > <authby group> > > AuthByPolicy ContinueAlways > > <authby sql> > IgnoreAuthentication > (blah, store accounting info locally, blah) > </authby> > > <authby sqlradius> > (boring sql stuff) > IgnoreAccountingResponse > (more boring definitions) > </authby> > > </authby> > > I just want to make sure that I've got the IgnoreAccountingResponse in > the correct AuthBy. Do I? > > Thanks for your help. > > -Peter > > On Tue, 2002-05-21 at 18:12, Hugh Irvine wrote: > > Hello Peter - > > > > The simplest way to do what you describe is this: > > > > # define Realm(s) or Handler(s) with AccountingHandled > > > > <Realm ...> > > AccountingHandled > > # define AuthBy RADIUS with IgnoreAccountingResponse > > <AuthBy RADIUS> > > IgnoreAccountingResponse > > ..... > > </AuthBy> > > ..... > > </Realm> > > > > This will cause the Realm (or Handler) to acknowledge the accounting > > request immediately, and any accounting response(s) received from the > > proxy target subsequently will be dropped. > > > > regards > > > > Hugh > > > > On Tue, 21 May 2002 04:03, peter moody wrote: > > > Poor form to reply to my own email, but there appears to be more > > > information. > > > > > > Qwest is actually sending the stop/start packets at 5 second intervals, > > > and radiator is forwarding them on the the proxy radius server. Qwest > > > is, I guess, waiting for some sort of acknowledgement and when one > > > isn't recieved, it sends another stop/start packet. radiator dutifully > > > forwards this packet on to the proxy server again, and logs the new > > > data in the accounting and radonline databases. > > > > > > So, I guess what I want to know now is, is there anyway that I can get > > > radiator to send the acknowledgement to qwest and then do it's own > > > timeout retransmit? Or is there anyway to get radiator to do a delete > > > on the accounting table before an insert (similar to what it does with > > > the radonline table) to avoid duplicate packats? And, is the problem > > > now actually with the proxied radius server and not with qwest? > > > > > > Again, I can send relevant trace4 debug info if needed. > > > > > > Thanks again. > > > > > > -Peter > > > > > > On Mon, 2002-05-20 at 09:57, peter moody wrote: > > > > Hello, > > > > > > > > I've got a radiator (2.19) running on a linux box with about 20 proxy > > > > realms. When one of our proxy users disconnects, Qwests seems to > > > > send about 6 Stop packets all at once. It's almost round-robin, > > > > except that radiator notes that all the packets arrive within a > > > > second or two. Radiator logs each of these packets in sequence and as > > > > a result our proxy users appear to have been online anywhere from 2 > > > > to 6 more than they really have. > > > > > > > > What I'm trying to figure out is, is radiator doing what it's > > > > supposed to do (ie. forwarding every stop packet it gets even if 6 in > > > > a row are for the same session id)? Or more specifically, is the > > > > problem with qwest's borked nas's sending 6 stop packets at once? > > > > > > > > I can send trace4 log exerpts as well as sql logs if you want. > > > > > > > > Thanks for your help. > > > > > > > > -Peter > > > > > > > > -- > > > > Peter Moody Systems Administrator > > > > [EMAIL PROTECTED] > > > > > > > > :wq > > > > > > > > === > > > > 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.
