(RADIATOR) Duplicate detection doesn't use source port

Hugh Irvine hugh at open.com.au
Mon Sep 5 23:02:41 CDT 2005


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?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


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