Re: (RADIATOR) problem with Radiator duplicate detection
Hi Mike, I'm trying to find the section in the RADIUS spec where is says don't respond if the Identifer is the same. Unfortunately Network Solutions have hidden the RFCs somewhere so I'm looking at the Lucent site (http://www.livingston.com/tech/technotes/500/510018.html). On page 13 it says: --- Identifier The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MUST remain unchanged. --- None of the Attributes have changed, so the NAS is definitely doing a resend. If it's a mis-implementation of RADIUS by Cisco I can beat them around the head with it. [EMAIL PROTECTED] On Fri, Apr 09, 1999 at 08:38:42AM +1000, Mike McCauley wrote: > > Actually, the RFC explicitly says that the server should not respond to > packets with a duplicate identifier. > > Cheers > > --- > Mike McCauley [EMAIL PROTECTED] > Open System Consultants +61 3 9598 0985 > > Mike is travelling right now, and there may be delays > in our correspondence. > -Original Message- > From: tom minchin <[EMAIL PROTECTED]> > To: Arnie Roberts <[EMAIL PROTECTED]> > Cc: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]> > Date: Thursday, April 08, 1999 7:40 PM > Subject: Re: (RADIATOR) problem with Radiator duplicate detection > > > >On Thu, Apr 08, 1999 at 10:09:28AM +0100, Arnie Roberts wrote: > >> On Wednesday, April 07, 1999 3:13 AM, tom minchin > [SMTP:[EMAIL PROTECTED]] wrote: > >> > >> > * yes it's bad the packet is being lost, but RADIUS should recover from > that. > >> > >> How?? > >> RADIUS runs over UDP. Surely this is a problem with RADIUS not Radiator. > >> > > > >Radiator is detecting the repeated Access-Request as a duplicate and > ignoring > >it. It should, according to RADIUS, resend the Access-Accept to the NAS not > >discard it as obviously the NAS didn't get the first one as it's stilling > >asking. > > > >[EMAIL PROTECTED] > > > >=== > >To unsubscribe, email '[EMAIL PROTECTED]' with > >'unsubscribe radiator' in the body of the message. > > > > === > To unsubscribe, email '[EMAIL PROTECTED]' with > 'unsubscribe radiator' in the body of the message. === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) problem with Radiator duplicate detection
Actually, the RFC explicitly says that the server should not respond to packets with a duplicate identifier. Cheers --- Mike McCauley [EMAIL PROTECTED] Open System Consultants +61 3 9598 0985 Mike is travelling right now, and there may be delays in our correspondence. -Original Message- From: tom minchin <[EMAIL PROTECTED]> To: Arnie Roberts <[EMAIL PROTECTED]> Cc: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]> Date: Thursday, April 08, 1999 7:40 PM Subject: Re: (RADIATOR) problem with Radiator duplicate detection >On Thu, Apr 08, 1999 at 10:09:28AM +0100, Arnie Roberts wrote: >> On Wednesday, April 07, 1999 3:13 AM, tom minchin [SMTP:[EMAIL PROTECTED]] wrote: >> >> > * yes it's bad the packet is being lost, but RADIUS should recover from that. >> >> How?? >> RADIUS runs over UDP. Surely this is a problem with RADIUS not Radiator. >> > >Radiator is detecting the repeated Access-Request as a duplicate and ignoring >it. It should, according to RADIUS, resend the Access-Accept to the NAS not >discard it as obviously the NAS didn't get the first one as it's stilling >asking. > >[EMAIL PROTECTED] > >=== >To unsubscribe, email '[EMAIL PROTECTED]' with >'unsubscribe radiator' in the body of the message. > === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) problem with Radiator duplicate detection
On Thu, Apr 08, 1999 at 11:14:29AM +0100, Arnie Roberts wrote:
>
> I see. Sounds like you need to set DupInterval to 0 or else fix the problem with
> the newtwork which causes it to lose packets.
> I still think this is essentially a problem caused by the limitations of the Radius
>spec.
> DupInterval is a Radiator "addition" to the spec which overcomes the limitation.
>
You can never guarantee there won't be an occasional network quirk,
the Radiator server getting busy or the NAS's are on full peak hour.
Radiator should stick to stopping Accounting duplicates (which is what
we want), not interfering with normal RADIUS operations.
I've complained to Cisco ("wishlist") but Mike is easier to convince :)
[EMAIL PROTECTED]
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) problem with Radiator duplicate detection
On Thursday, April 08, 1999 10:29 AM, tom minchin [SMTP:[EMAIL PROTECTED]] wrote: > On Thu, Apr 08, 1999 at 10:09:28AM +0100, Arnie Roberts wrote: > > On Wednesday, April 07, 1999 3:13 AM, tom minchin [SMTP:[EMAIL PROTECTED]] wrote: > > > > > * yes it's bad the packet is being lost, but RADIUS should recover from that. > > > > How?? > > RADIUS runs over UDP. Surely this is a problem with RADIUS not Radiator. > > > > Radiator is detecting the repeated Access-Request as a duplicate and ignoring > it. It should, according to RADIUS, resend the Access-Accept to the NAS not > discard it as obviously the NAS didn't get the first one as it's stilling > asking. > > [EMAIL PROTECTED] I see. Sounds like you need to set DupInterval to 0 or else fix the problem with the newtwork which causes it to lose packets. I still think this is essentially a problem caused by the limitations of the Radius spec. DupInterval is a Radiator "addition" to the spec which overcomes the limitation. Arnie === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) problem with Radiator duplicate detection
On Thu, Apr 08, 1999 at 10:09:28AM +0100, Arnie Roberts wrote: > On Wednesday, April 07, 1999 3:13 AM, tom minchin [SMTP:[EMAIL PROTECTED]] wrote: > > > * yes it's bad the packet is being lost, but RADIUS should recover from that. > > How?? > RADIUS runs over UDP. Surely this is a problem with RADIUS not Radiator. > Radiator is detecting the repeated Access-Request as a duplicate and ignoring it. It should, according to RADIUS, resend the Access-Accept to the NAS not discard it as obviously the NAS didn't get the first one as it's stilling asking. [EMAIL PROTECTED] === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) problem with Radiator duplicate detection
On Wednesday, April 07, 1999 3:13 AM, tom minchin [SMTP:[EMAIL PROTECTED]] wrote: > * yes it's bad the packet is being lost, but RADIUS should recover from that. How?? RADIUS runs over UDP. Surely this is a problem with RADIUS not Radiator. Arnie === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) problem with Radiator duplicate detection
Hi, I think I've found a problem with the duplicate detection in Radiator. Basic scenario looks like this: 1. Cisco NAS sends an Access-Request 2. Radiator sends an Access-Accept 3. Packet is lost* 4. Cisco NAS gets impatient and sends another Access-Request** 5. Radiator ignores the packet and logs it as a duplicate [..] repeat until Cisco gives up and drops the user * yes it's bad the packet is being lost, but RADIUS should recover from that. ** bloody Cisco would make the Access-Requests identifier unique, but NOT the Accounting-Requests. Would it be possible to tune the duplicate detection so that it only works on certain RADIUS bits? (and make it work with the non-unique Cisco Accounting-Requests). (Mike, I have a trace if you want). [EMAIL PROTECTED] === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
