> eg: would I have to add the table.
> radcheck
> id - - - - - - - - 4567
> UserName - - user1
> Attribute - - - Calling-Session-Id
> op - - - - - - - :=
> Value - - - - - 000bcdfxxx
I think this example is OK, but the op which should be '==' (':='
always matches and sets a freeradius parameter, I
> Is there a way to dynamically attach the mac of the users pc to the
> username who has logged in?
> This way I can stop people sharing the same username/password
> combination on different pc's.
Using the post-auth requests, you can add a Calling-Session-Id for the
concerned user in the radcheck
> > wether setting
> > an Expiration attribute in radcheck normally implies a Session-Timeout
> > to be added to the access-accept messages, or not.
>
> Yes.
>
> If it doesn't work in SQL, try it in the "users" file.
Thank you for answer. I tried with the "users" file and got the same
behavi
Hi again,
I'm sorry to post twice but as I'm not an english person I was
wondering wether what I asked was really clear. I'm not looking for a
complicated solution of any kind, but I'd like to know wether setting
an Expiration attribute in radcheck normally implies a Session-Timeout
to be added t
> > When a user logs in 23 hours and 59 minutes after the first
> > connection, I expected freeradius to return the Session-Timeout
> > attribute in the access-accept (with value 60).
> >
> > Actually it does not, so the user can stay connected well after the 24
> > hours limit.
>
> So... what d
Hi,
We're using freeradius 1.0.1 with postgresql.
We create users which expire 24 hours after first login. Currently we
do this by setting the Expiration attribute to be login-time + 24
hours in the radcheck table.
When a user logs in 23 hours and 59 minutes after the first
connection, I expecte
6 matches
Mail list logo
