(RADIATOR) two accounting start two accounting stop
hugh at open.com.au
Tue Jun 17 06:12:57 CDT 2003
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.,
> to PEAP) while an AP is still trying to associate the client
> supplicant at
> the mean time.
> I also noticed that two additional challenges which I
> wonder occured in wired NAS. First, rebooting wireless APs or
> 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
> the actual useful one. This leads me to think about two questions:
Correct. Restarting the NAS and/or Radiator may result in duplicate
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
> 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
> 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
> Finally, how other folks managing (non-)wireless NAS handling the above
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.
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.
More information about the radiator