(RADIATOR) two accounting start two accounting stop

[Hugh Irvine]

Hello Bon -

Answers to your questions below.

On Tuesday, Jun 17, 2003, at 20:12 Australia/Melbourne, Bon sy wrote:

> Hi Hugh, Mike, and Donald,
>
> 	I have a similar experience in the wireless case. Specifically,
> when I switched between two different authentication modes (e.g., 
> EAP-TLS
> to PEAP) while an AP is still trying to associate the client 
> supplicant at
> the mean time.
>

Understood.

> 	I also noticed that two additional challenges which I
> wonder occured in wired NAS. First, rebooting wireless APs or 
> restarting
> radiator may run into the problem of regenerating identical account
> session ids. Second, radiator will insert into database useless
> accounting record (such as blank userid, timestamp, etc) in additional 
> to
> the actual useful one. This leads me to think about two questions:
>

Correct. Restarting the NAS and/or Radiator may result in duplicate 
session id's.

This is just the nature of the radius protocol.

> 1. Can we get radiator to be the only source on generating accounting
> session id, and using format like 
> <calling-station><nas-identifer><time>
> as a session id (time means date and time). This should guarantee
> uniqueness of the session id. I find a way to do so in the DB
> level. But I will much prefer this to be taken care in the
> radius level. (If there is enough interest in the tedious get-around
> solution in the DB level, I will be happy to post it.)
>

Because radius is a stateless protocol, each request is treated 
independently of any other.

This is especially true of accounting requests due to the fact that 
there should be a different Acct-Delay-Time in every accounting 
retransmission.

> 2. Although zero out useless blank record is not a big deal in the
> database leve, it does cause additional maintainence work. Can this be
> taken care in the radius level so that it will not even happen in the
> first place?
>

This is quite difficult to do as Radiator has no way of knowing 
internally whether an accounting record has already been processed or 
not.

> Finally, how other folks managing (non-)wireless NAS handling the above
> challenges?
>

This is usually taken care of by post-processing the accounting records 
in a similar manner to what you describe - comparing the NAS, 
Session-Id, Timestamp, and Acct-Delay-Time to remove duplicates.

It has been our view that Radiator should try to process radius 
requests as quickly as possible and that post-processing the accounting 
data is best left to billing systems that are designed for this purpose.

Mike may have additional comments.

regards

Hugh


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