(RADIATOR) Duplicate detection doesn't use source port

Jonathan Kinred jonathan.kinred at dot.com.au
Tue Sep 6 02:10:29 CDT 2005


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.


More information about the radiator mailing list