(RADIATOR) qwest and stop packets

[Hugh Irvine]

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
> > > > peter at enabledsites.com
> > > >
> > > > :wq
> > > >
> > > > ===
> > > > Archive at http://www.open.com.au/archives/radiator/
> > > > Announcements on radiator-announce at open.com.au
> > > > To unsubscribe, email 'majordomo at open.com.au' 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 radiator-announce at open.com.au
> > To unsubscribe, email 'majordomo at open.com.au' 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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.