> > Also, anyone have a solution to preventing multiple logins?
>
> Here are some pointers on how to modify radiusd 1.16 to only allow each
> user to log in once.
I just finished doing much of this before reading Brian's message.
> This simple version doesn't handle power losses
> or having your UNIX server crash, dealing with those situations would
> be more complex.
Just reset all the PMs when you bring back up the UNIX server and
everything is in sync. :)
> Next, if PW_ACCT_STATUS_TYPE equals
> PW_STATUS_START and you don't have a stop entry for
> this user, add a start entry for this user, recording the
> client and port as well.
>
> OR If PW_ACCT_STATUS_TYPE equals
> PW_STATUS_START and you do have a stop entry for this user
> on the same client and port, remove the stop entry.
I don't understand the reason for tracking the client and port here. I
simply took each START record as a logon, and STOP as a logoff for the
username specified in the packet. Is this to handle START and STOP
arriving out of sequence? How likely/common is this?
> If he does already have a start
> entry, that means he's logged in somewhere else, and you should set
> user_msg to be some string up to 127 characters long including a \r\n
I've made some changes to RADIUS that result in a wide variety of
user_msg values being delivered to the client. I strongly suspect
there's a bug in 3.1.4 in dealing with this. I have seen instances of
users seeing login failure messages that were delivered from RADIUS,
yet the user logged in anyway. I logged every RADIUS transaction with
the user_msg it delivered, and never found a discrepancy coming from RADIUS.
I suspect they're seeing "stale" messages that were delivered to previous
users, but weren't flushed from the PM.
-- John W. Temples, III || Providing the first public access Internet Gulfnet Kuwait || site in the Arabian Gulf region