(RADIATOR) Duplicate detection doesn't use source port

[Jonathan Kinred]

Hi Hugh,

After reviewing what is needed, all we need Radiator to do is what the 
RFC defines. That is, look at the source port and identifier to identify 
duplicates. As i see it, (without disabling dupe detection) the maximum 
theoretical packets/sec that Radiator can handle from any NAS is 127.5 
packets/sec.

Perhaps the option could be called ComplyWithRFC2865?

Jonathan


Hugh Irvine wrote:
> 
> Hello Jonathon -
> 
> You will need to make the code changes and then do some testing.
> 
> As mentioned, we need to know what Cisco actually does when sending a  
> duplicate.
> 
> I have a vague recollection that we have been down this path  
> previously, but that every radius request sent by the Cisco used a  
> different source port which made it impossible to do duplicate  
> detection anyway. Please let us know the results of your testing and  
> we'll consider your modifications.
> 
> regards
> 
> Hugh
> 
> 
> On 6 Sep 2005, at 14:51, Jonathan Kinred wrote:
> 
>> Hi Hugh,
>>
>> I will see what i can do regarding the information from Cisco.
>>
>> In the meantime i have found that the number of source ports is  only 
>> 200, i had previously been informed that it was in the 10's of  
>> thousands :). So i think the potential memory usage per NAS would  be 
>> 200 ports x 255 identifiers x 2 request types x sizeof(RecvTime)  
>> which is ok for us.
>>
>> Saying that, we'd have to hack the Client.pm code to extend the  
>> RecentIdentifiers hash to include a source port:
>>
>> From:
>> $self->{RecentIdentifiers}->{$p->{RecvFromAddress}}->{$code.$p- 
>> >identifier}
>>
>> to:
>> $self->{RecentIdentifiers}->{$p->{RecvFromAddress}}->{$p-> 
>> {RecvFromPort}}->{$code.$p->identifier}
>> or:
>> $self->{RecentIdentifiers}->{$p->{RecvFromAddress}.$p-> 
>> {RecvFromPort}}->{$code.$p->identifier}
>>
>> We're not that keen on tracking this change through radiator  versions 
>> so ideally we'd like to see an option like  DupSourcePortCheck which 
>> turns this on.
>>
>> What do you think?
>>
>> Jonathan
>>
>>
>> Hugh Irvine wrote:
>>
>>> Hello Jonathon -
>>> If you can find out from Cisco how they indicate that a  particular  
>>> request is a duplicate when extended source ports are  turned on, we  
>>> will be only too happy to implement their  algorithm. Note that the  
>>> RFC does not cover the case of different  source ports for each  
>>> request. In the absence of any other  information, setting 
>>> DupInterval  0 is your only option in the  Radiator configuration 
>>> file (or  NoIgnoreDuplicates for finer  grained control).
>>> regards
>>> Hugh
>>> On 6 Sep 2005, at 11:43, Jonathan Kinred wrote:
>>>
>>>> Hi,
>>>>
>>>> During testing we discovered that the source port of a request  is  
>>>> not taken into account for duplicate detection. With the  default  
>>>> DupInterval of 2 seconds this means that Radiator will  start  
>>>> ignoring packets as dupes when a NAS sends more than ~128  requests  
>>>> per second. We are using a Cisco SSG and want to turn  on extended  
>>>> source ports, so we're definitely going to run into  the excessive  
>>>> memory problem below.
>>>>
>>>> I'm wondering if there is a more elegant way for Radiator to  
>>>> handle  this rather than breaking the RFC and not using the  source 
>>>> port. I  am thinking along the lines of having requests  purged from 
>>>> the  RecentIdentifiers hash when they exceed  DupInterval. It sounds 
>>>> like  an expensive operation but as i see  it our only option for 
>>>> these  NAS's is to enable  NoIgnoreDuplicates or live with the 128 
>>>> per  second limit.
>>>>
>>>> I'd also like to hear if someone has a better solution using the   
>>>> current Radiator versions.
>>>>
>>>> -- 
>>>> Jonathan Kinred
>>>> System Administrator
>>>> Dot Communications
>>>>
>>>>
>>>> Revision 3.6 (2003-04-14 Significant improvements to wireless  support)
>>>> Client duplicate detection now ignores the source port, due to  
>>>> some  clients (notably Cisco APs) using a different port for  every  
>>>> request, resulting in excessive memory usage.
>>>>
>>>> Revision 2.16.2 (21/8/00) Minor fixes
>>>> Duplicate checking now takes the client port into account, as   
>>>> required by RFC 2865.
>>>>
>>>> -- 
>>>> 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.
>>>>
>>>>
>>> NB:
>>> Have you read the reference manual ("doc/ref.html")?
>>> Have you searched the mailing list archive (www.open.com.au/ 
>>> archives/ radiator)?
>>> Have you had a quick look on Google (www.google.com)?
>>> Have you included a copy of your configuration file (no secrets),
>>> together with a trace 4 debug showing what is happening?
>>
>>
> 
> 
> NB:
> 
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/ 
> radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> 

--
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.