Hello Mariano -
The best way to deal with this problem is with the "Class" attribute
(designed for this purpose). You would put the profile into the Class
attribute that is returned to the NAS by the access accept, and the NAS will
send the Class attribute in all subsequent accounting packets for that
session. Therefore you can deal with your simultaneous use issues directly
with no problem.
In your authentication AuthBy clause, you would do something like this:
<AuthBY .....>
.......
AddToReply Class = **your profile**
</AuthBy>
And then your session database queries would include the Class attribute as
well as the other normal attributes (you will have to alter the session
database schema to suit).
This topic has been discussed on the list several times, so have a look at
the archive site:
http://www.starport.net/~radiator
hth
Hugh
On Wednesday 07 March 2001 05:46, Mariano Absatz wrote:
> Now,
>
> this I have to do it now (can't wait for Radiator 9.3 :-).
>
> As I mentioned in my last cited message, I intend to forward (proxy) a
> request to another radius and this one will tell me which profile it
> wants in a Configuration-Token attribute.
>
> As I am limiting simultaneous use per profile, I can't do this until I
> have this info (this is no problem).
>
> The point is that, obviously, the record in the SessionDatabase MUST have
> the profile info. I insert this record when I receive the Acct-Start
> packet, but this packet DOESN'T have info about the profile (and the NAS
> can't send it).
>
> So, what do I do? The only idea I have is to use the Acct-Session-ID that
> is present in all the packets (Access-Request, Start & Stop), but it
> seems I would need to use an auxiliary table where I insert a record with
> (Session-ID,profile) when I get back the Configuration-Token (in an
> Access-Accept from the final radius), and then, when I get the Start, I
> should check the Session-ID against this auxiliary table, get the
> apropriate profile, insert the record in the SessionDatabase and delete
> the record from the aux.table.
>
> This I don't like, 'cause it implies lots of inserts/queries/deletes in
> this aux.table and eventually, I should do some garbage collection 'cause
> there could be stale records there... probably, any record in the
> aux.table older than 5 minutes should be discarded? when/how do I do this?
>
> Do you have another idea?
>
>
>
> ===
> Archive at http://www.starport.net/~radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
--
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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
