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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
